This video presentation is the first installment of the Essentials of MQX RTOS Application Development training course. In this session, you will be introduced to multi-tasking, blocking calls, and switching.
This training was created by Embedded Access Inc., a Freescale sponsored training provider and proven partner.
| Session 2 Course Line | Lab Topic |
|---|---|
|
|
First, watch the video for Session 2: Designing for a Multi-Tasking Environment.
Then, follow through with the interactive lab assignment below.
SESSION 2: LAB ASSIGNMENT
INTRODUCTION
Now that we have our application outlined it's time to organize the code into a structure that is appropriate for a multi-tasking environment. For one thing we'll need the application to run indefinitely instead of doing a small task and terminating. As well, having multiple tasks running in parallel requires a degree of cooperation and synchronization between the tasks. This is a topic that will be visited at several points in the course but for starters we'll look at a couple of options and see the impact they have on performance.
OBJECTIVE
The objective of this lab is to understand the interaction of multiple tasks running indefinitely.This objective will be accomplished by:
- Converting each task into the proper format
- Exploring ways for tasks to share the CPU
ASSIGNMENT
UPDATING THE STRUCTURE OF EACH TASK
- You can either continue on with where you left off after the session 1 assignment or replace you files with the provided solution for lab 1. If you decide to use the provided solution it is suggested that you compile and run this code first to make sure that it is operational on your machine.
- Since in a real system tasks typically run indefinitely the code for each task should be modified so they print their unique message continuously.
- Once these changes have been made compile and run the application. Observe the print out. Is this what you expected? Why do you think this happened?
COOPERATIVE SHARING OF THE CPU TIME
- Change the Health Task such that it does a 1 second time delay after it's printf. Compile and run the application.
- What impact did you observe? Put a breakpoint on the printf in the Display Tasks and pull up the Task List in Task Aware Debugging (TAD). Does this explain the results?
- Since the use of a time delay allowed the next task to run, putting a 1 second time delay after the print statement in all tasks should allow for better cooperation. Try this and re-run the application.
- Did you get all print messages? If so, what is the downside to this method ensuring shared use of the CPU?
- Try replacing all of the time delays with the schedule yield function (_sched_yield() ). Run your code and compare the results.
Need more help? The full source code for this lab can be found in the 'Lab Source Code' folder here.
