Session 2: Designing for a Multi-Tasking Environment

[#1]

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
Overview of a Multi-Tasking Environment Super Loop Programming Limitations Task Coding Structure Task States What is a blocking call? Task Content Switching	Updating the structure of each task Cooperative sharing of the CPU time Working with time delays Working with schedule yield

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

1. 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.
2. Since in a real system tasks typically run indefinitely the code for each task should be modified so they print their unique message continuously.
   
   
3. 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

1. Change the Health Task such that it does a 1 second time delay after it's printf. Compile and run the application.
2. 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?
   
   
   
   
   
3. 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.
4. Did you get all print messages? If so, what is the downside to this method ensuring shared use of the CPU?
   
   
   
5. 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​.