Description

The qp_pelican example program demonstrates design and implementation of a modern hierarchical state machine (UML statechart) to control a PEdestrian LIght CONtrolled (PELICAN) crossing.

Running the qp_pelican Example

You compile and download the qp_pelican program to the mbed board in the usual way. The program uses the on board LEDs to show the signals for the cars and pedestrians in the following way (LEDs are counted from the left):

• LED1 - red light for cars
• LED2 - yellow light for cars
• LED3 - green light for cars
• LED4 - "Don't Walk" signal for pedestrians.

When qp_pelican starts executing, you should see the LED3 and LED4 light up (green light for cars, "Don't Walk" signal for pedestrians). After a short while, the lights change to LED2-on (yellow light for cars) and then LED1 on (red light for cars). At this point LED4 is switched off (pedestrians are allowed into the crossing). After this LED4 starts to blink and after that the cycle repeats. Additionally, from time to time the PELICAN crossing goes into "offline" state, in which the "Don't Walk" signal for pedestrians (LED4) and red light for cars (LED1) blink.

Software Tracing Demonstration

The qp_pelican program also produces software tracing output, similar to the qp_dpp example. Please read the QL Notebook page about software tracing to learn how to receive the serial data with the QSPY host application.

The command line to invoke QSPY for receiving data from the qp_pelican program on Windows looks as follows:

qspy -b115200 -cCOM7

Most likely you need to adjust the -c parameter to the virtual COM port number of the mbed board. On Windows, you can discover this by running Device Manager.

Please remember that to obtain the readable output, you need to launch the host application before resetting the mbed board, to capture the initialization information. The following screen shot of QSPY output shows the tracing information produced by qp_pelican:

Please note that the tracing output comes much slower from qp_pelican than from the qp_dpp# program, because PELICAN crossing operates quite slowly.

Preemptive Multitasking Demonstration

Just like the qp_dpp program, qp_pelican demonstrates the preemptive QK multitasking kernel on mbed. As any preemptive kernel, QK must be informed about entering and exiting every interrupt service routine (ISR), but QK perfectly accepts ISRs written in C, while most other kernels require writing ISRs (or at least ISR "wrappers") in assembly.

The one thing you should remember when writing ISRs is to call the macro QK_ISR_ENTRY() at the beginning of every ISR, and the macro QK_ISR_EXIT() at the end of every ISR. The following code snipped illustrates the use of these macro in the SysTick_Handler():

extern "C" void SysTick_Handler(void) {
    QK_ISR_ENTRY();                // inform the QK kernel of entering the ISR

#ifdef Q_SPY
    uint32_t volatile dummy = SysTick->CTRL; // clear the COUNTFLAG in SysTick
    l_tickTime += l_tickPeriod;              // account for the clock rollover
#endif

    QF::tick();                               // process all armed time events

    QK_ISR_EXIT();                  // inform the QK kernel of exiting the ISR
}

More Information

Please visit state-machine.com for more information.