This video presentation is the seventh installment of the Essentials of MQX RTOS Application Development training course. In this session, you will be introduced to various features of light weight events and full featured events.
This training was created by Embedded Access Inc., a Freescale sponsored training provider and proven partner.
|Session 7 Course Line||Lab Outline|
First, watch the video for Session 7: Light Weight Events.
Then, follow through with the interactive lab assignment below.
SESSION 7: LAB ASSIGNMENT
As mentioned in the videos we want to keep interrupt service routines (ISRs) as short as possible. Currently the ISRs associated with switch presses send messages directly to the health task and it would reduce the over head of these ISRs to just post an event to indicate that a switch was pressed and let the Input Task deal with the sending of messages. This lab will walk you through the changes required to use light weight events to make this update and you'll see events in action with both auto clearing bits and non-auto clearing bits.
The objective of this lab is to learn about lwevents by having the switch ISRs signal the input task using lwevents.This objective will be accomplished by:
- Creating a lwevent in the input task
- Setting the lwevent in the switch ISRs
- Having the input task wait on the lw event and send a message to the health task
- Experimenting with using autoclear events vs. non- autoclear events
New functions/ structures you will use:
LWEVENT_STRUCT, _lwevent_create, _lwevent_wait_ticks, _lwevent_get_signalled, _lwevent_set, _lwevent_clear
CREATING THE EVENT GROUP
- Light weight events (LW Events) is an optional component so prior to being able to use them you need to include lwevent.h. Add this to main.h since all of our files include this header file.
- The code in the Input Task will need access to the LW Event structure so in InputTask.c add a global variable of type LWEVENT_STRUCT.
- The LW Event will have to be created so in the initialization section of the Input Task you need to call _lwevent_create(). In this case we do not want the flags to auto clear.
- Since we are using events to indicate the pressing of the switches we need to specify the specific bit being used for each switch. At the top of InputTask.c create a define that specifies that bit 0 of the event group will indicate the status of switch 1 (ie a define set to 0x0000001) as well as a define that specifies that bit 1 of the event group will indicate the status of switch 2 (ie a define set to 0x00000002).
UPDATING THE ISRS
- To reduce the overhead of the two ISRs they will set the corresponding event bit in lieu of sending a message to the Health Task. The body of the Input Task will do send the messages to the Health Task - we'll get to this part in a moment. For now you can remove the message sending code from the ISRs and replace it with the _lwevent_set() function. The ISR for switch 1 will set bit 0 (using the define we created in the previous step) and the ISR for switch 2 will set bit 1 using the respective define.
UPDATING THE INPUT TASK
- Since the input task is only responding to a press of one of the switches there isn't anything for it to do until this happens. The most efficient way to handle this is to have the Input Task wait indefinitely until one of the event bits of interest have been set. This can be done using the _lwevent_wait_ticks() function. Both event bits will need to be specified with the call waiting on either of the bits to be set, not both, and in order for the call to wait indefinitely specify a timeout of 0.
- Once a switch has been pressed the Input Task will need to know which switch was pressed in order to know how to respond. It can determine this by using the _lwevent_get_signalled() function. This function returns a 32 bit number that indicates which bit in the event group caused this task to become unblocked. You should save this returned value in order to process it later.
- In response to a switch press the Input Task will simple send a message to the Health Task that either switch 1 or switch 2 was pressed. The returned value from the _lwevent_get_signalled() function can be tested if bit 0 or bit 1 has been set to determine which switch was pressed and the corresponding message can be sent. The code for sending a message should still be available as we commented it out in the lab for session 6. When a switch is pressed the read value is 0 so we don't need to get the input level on the GPIO pin and we don't need the code to monitor the switches for changes of state, simply send a message with the appropriate message type and a data value of 0.
- Since the event group was not set up to be auto clearing the bit that unblocked the Input Task will still be set and it should be cleared using the _lwevent_clear() function.
TESTING YOUR CHANGES
- Compile and run your code. Verify that the operation of the system is the same as it was at the end of the lab for session 6, meaning that the green LED(LED ) flashes and that is switch 1 is pressed the orange LED (LED) will go on and if switch 2 is pressed the orange LED will go off. You should also see appropriate messages being printed out on the console.
- Put a break point in the Input Task code on a line just after the _lwevent_wait_ticks() call. Press switch 1 on the tower board and when the break point is hit use task aware debugging to view the lightweight events status window. Bit 0 should be set in the event group.
- Run the code and press the other switch on the tower card. The task aware debugging window should show only bit 1 is set.
- Remove your break point and update the creation of the lwevent group so the bits are auto clearing by using the LWEVENT_AUTO_CLEAR flag in the _lwevent_create() function. Then remove the _lwevent_clear() function calls and confirm that the system behaves in the same way that it did before.
- Put a break point back in the same location that you did previously and confirm that despite a switch being pressed the bits are auto clearing and that neither bit 0 or bit 1 are set in the lightweight events status window.
Need more help? The full source code for this lab can be found in the 'Lab Source Code' folder here.