Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[Moved] Traffic Light System on FPGA with MicroBlaze Softcore

Status
Not open for further replies.

BiscuitDuke

Newbie level 6
Joined
Sep 4, 2014
Messages
13
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
112
I am taking an Embedded Computing class and as a final project I must design a traffic light system. I am using a XC5VLX110T and so far this is my code.

Code:
int main()
{

xil_printf("orange");
XromLCDPrintString(" GO!! ");
//==================================================================================
//
//    PUSH BUTTON
//
//==================================================================================



XGpio dip, push;
int i, dip_current, push_current, dip_old, push_old;




//XGpio_Initialize(&dip, XPAR_DIP_DEVICE_ID);
XGpio_Initialize(&dip, XPAR_DIP_DEVICE_ID);
XGpio_SetDataDirection(&dip, 1, 0xffffffff);

//XGpio_Initialize(&push, XPAR_PUSH_DEVICE_ID);
XGpio_Initialize(&push, XPAR_PUSH_DEVICE_ID);
XGpio_SetDataDirection(&push, 1, 0xffffffff);

dip_old = 0xFF;
push_old = 0xFF;

   while(1) {
 push_current = XGpio_DiscreteRead(&push, 1);
 dip_current = XGpio_DiscreteRead(&dip, 1);

 if(push_current != push_old) //|| (dip_current != dip_old))
 {

    push_old = push_current;
pedestrian_walk = 1;
   //dip_old = dip_current;

 }
 





  
  // Enable MicroBlaze Interrupts
  // microblaze_enable_interrupts();
  
  /* Register the Timer interrupt handler in the vector table */
  XIntc_RegisterHandler(XPAR_XPS_INTC_0_BASEADDR,
                             XPAR_XPS_INTC_0_DELAY_INTERRUPT_INTR,
                             (XInterruptHandler) timer_int_handler,
                             (void *)XPAR_DELAY_BASEADDR);

  /* Initialize and set the direction of the GPIO connected to LEDs */
  XGpio_Initialize(&gpio, XPAR_LEDS_8BIT_DEVICE_ID);
  XGpio_SetDataDirection(&gpio,LEDChan, 0);

  /* Start the interrupt controller */
  XIntc_MasterEnable(XPAR_XPS_INTC_0_BASEADDR);
  XIntc_EnableIntr(XPAR_XPS_INTC_0_BASEADDR, 0x1);

  /* Set the gpio as output on high 8 bits (LEDs)*/
  XGpio_WriteReg(XPAR_LEDS_8BIT_DEVICE_ID,LEDChan, ~count);
  //xil_printf("The value of count = %d\n\r", count);

  /* Set the number of cycles the timer counts before interrupting */
  XTmrCtr_SetLoadReg(XPAR_DELAY_BASEADDR, 0, (timer_count*timer_count+1) * 80000000); 
   
  /* Reset the timers, and clear interrupts */
  XTmrCtr_SetControlStatusReg(XPAR_DELAY_BASEADDR, 0, XTC_CSR_INT_OCCURED_MASK | XTC_CSR_LOAD_MASK );
  /* Enable timer interrupts in the interrupt controller */
  XIntc_EnableIntr(XPAR_DELAY_BASEADDR, XPAR_DELAY_INTERRUPT_MASK);
  
  /* Start the timers */
  XTmrCtr_SetControlStatusReg(XPAR_DELAY_BASEADDR, 0, XTC_CSR_ENABLE_TMR_MASK | XTC_CSR_ENABLE_INT_MASK | 
XTC_CSR_AUTO_RELOAD_MASK | XTC_CSR_DOWN_COUNT_MASK);  
  /* Enable MB interrupts */
  microblaze_enable_interrupts();

 /*Wait for interrupts to occur 
while(1) {
 push_current = XGpio_DiscreteRead(&push, 1);
      dip_current = XGpio_DiscreteRead(&dip, 1);
if( pedestrian_walk) {

count=0;
push_old = push_current;
XromLCDClear();
while (count< 31)
{

XromLCDPrintString(" PEDESTRIAN WALK ");
xil_printf("PED");
XromLCDSetLine(2);
XromLCDPrintString(" STOP!! ");
count ++;
}
one_second_flag=0;
pedestrian_walk=0;
count=0;
}
}*/




XromLCDInit();
XromLCDOn();

while(count>0 && count<6)
{
     XromLCDClear();
      xil_printf("Green");
XromLCDPrintString(" GREEN  ");
XromLCDSetLine(2);
XromLCDPrintString(" GO!! ");
    }


while(count>5 && count<16)
{
XromLCDClear();
xil_printf("Yellow");
XromLCDPrintString(" YELLOW  ");
XromLCDSetLine(2);
XromLCDPrintString(" SLOW ");
}


while(count>15 && count<26)
{
XromLCDClear();
xil_printf("Red");
XromLCDPrintString(" RED ");
XromLCDSetLine(2);
XromLCDPrintString(" STOP!! ");
}

if(count >= 26)
{
count = 0;
}
   }
 //exit(0);
}

What I want this code to do is to display "green", "yellow", "red", repeat as long as a pedestrian button is not pushed. If a pedestrian pushes a button, then it should display "pedestrian walking, stop." Right now I'm having the problem of it not repeating, as well as the button not working. I'm more concerned about the button right now? Is the code for the button in the right place? Am I using while loops correctly? Anything you may find wrong with the code please let me know. Thanks in advance!
 

re: Traffic Light System on FPGA with MicroBlaze Softcore

Anything you may find wrong with the code please let me know. Thanks in advance!

I´m not sure if this is an acceptable usage of the increment operator
In general there is no space between both operand and operator:
Code:
count ++;
 

Re: Traffic Light System on FPGA with MicroBlaze Softcore

First remark. I don't think that soft processor C problems should go to the FPGA section. It's just embedded C, using some specific libraries. Maybe you got the homework assignment in your FPGA course, but that's no sufficient reason to post it here.

The overall main() layout looks confused. We would expect an initialization part, e.g. setting up GPIOs, interrupts, timers, setting a meaningful initial variable state if not already done in the declarations. Then a repated while (1) block. Instead you have an over-all repeated block including all initializations.

I think that your work should start on pencil and paper with a flow or state diagram describing the intended operation.

As presented, the code doesn't "work", you are e.g. waiting for a counter value that is nowhere incremented, at least after commenting part of the code.
 

Re: Traffic Light System on FPGA with MicroBlaze Softcore

I think that your work should start on pencil and paper with a flow or state diagram describing the intended operation.

Seems to be some truly inept teachers "out there". Giving students "state" problems without any introduction to state programming. Or maybe students who missed classes!

To the OP - do as FvM suggests, and learn state programming.
 

Re: Traffic Light System on FPGA with MicroBlaze Softcore

I think that your work should start on pencil and paper with a flow or state diagram describing the intended operation.

Yes.

But more interesting, just why is the OP implementing a traffic lights controller in a softcore in an FPGA? That's not an appropriate use of technology. It would be better to either implement the controller in software running in a single chip microcontroller (e.g. an arduino-class machine), or directly in hardware (e.g. in an FPGA).

If the answer is "because I was told to", then you ought to get extra credit for pointing out the better alternative implementation techniques!
 

Re: Traffic Light System on FPGA with MicroBlaze Softcore

But more interesting, just why is the OP implementing a traffic lights controller in a softcore in an FPGA? That's not an appropriate use of technology. It would be better to either implement the controller in software running in a single chip microcontroller (e.g. an arduino-class machine), or directly in hardware (e.g. in an FPGA).

I agree about "not appropriate" at first sight, but the traffic light controller can be nevertheless a useful excercise problem. I think that's what we see here.
 

Re: Traffic Light System on FPGA with MicroBlaze Softcore

I agree about "not appropriate" at first sight, but the traffic light controller can be nevertheless a useful excercise problem. I think that's what we see here.

I know why you say that, but if you are going to do it in software, just do that on a conventional processor. I see no virtue whatsoever, either in "the real world" or as a teaching exercise, in having an unnecessarily complex solution. All it can achieve, as far as I can see, is forcing students to battle through and discover which buttons to push on a specific tool at a particular point in time. IMNSHO university courses should teach students to determine the core essentials, and not the temporary fluff. The core essentials will last a lifetime[1]; the fluff will be outdated next year.

A famous electrical engineering professor used to set 3 types of final year question. One could be done if you had turned up at the lectures, one could be done if you had some imagination and drive, and the final one could not be answered within the time available. He expected his students to be able to spot which questions to avoid, since that is a vital engineering skill.

OTOH, if part of the exercise is a compare-and-contrast different approaches, then it is more justifyable.

[1] returning to electronics after a couple of decades away, I was surprised pleased and upset to see how little had changed. The major changes were that stuff was cheaper and smaller, and - in some areas - faster. Yes, I was doing micro and FPGA work in the 70s, 80s and 90s, and the only real difference is that I could afford the devkit and hardware from "petty cash".
 
  • Like
Reactions: FvM

    FvM

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top