Session 7: Light Weight Events

Document created by Gabriela Godinez Employee on Jun 29, 2016Last modified by Gabriela Godinez Employee on Jun 29, 2016
Version 2Show Document
  • View in full screen mode

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 LineLab Outline
  • Reasons for using synchronization
  • Overview of events
  • Working with light weight events
  • Working with full featured events
  • Ways to wait on an event
  • Various synchronization traits and comparison between events, LW events, message passing, and LW message passing
  • Creating an Event Group
  • Controlling event bits from an ISR
  • Updating a task to wait indefinitely for an event

 

First, watch the video for Session 7: Light Weight Events.

Then, follow through with the interactive lab assignment below.

SESSION 7: LAB ASSIGNMENT

INTRODUCTION

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.

OBJECTIVE

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

ASSIGNMENT

CREATING THE EVENT GROUP

    1. 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.
    2. 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.
      whiteboard.png
      Whiteboard 7-1.jpg
    3. 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.
      cheat.png
      Cheat 7-1.png
    4. 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).
      cheat.png
      Cheat 7-2.png

UPDATING THE ISRS

    1. 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.
      whiteboard.png
      Whiteboard 7-2.jpg

UPDATING THE INPUT TASK

    1. 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.
      cheat.png
      Cheat 7-3.png
    2. 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.
    3. 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.
      cheat.png
      Cheat 7-4.png
    4. 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

  1. 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 [2]) flashes and that is switch 1 is pressed the orange LED (LED[0]) 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.
  2. 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.
    results.png
    Results 7-1.png
  3. Run the code and press the other switch on the tower card. The task aware debugging window should show only bit 1 is set.
  4. 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.
  5. 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.
    results.png
    Results 7-2.png

Need more help? The full source code for this lab can be found in the 'Lab Source Code' folder here.

Attachments

    Outcomes