18-348 Lab #9

Spring 2015

This lab is based on Lecture 15 - Cooperative and Preemptive Context Switching and Lecture 16 - Concurrency.

Links to all files referenced in the lab and prelab can be found in the Files section at the end of this document.

Note: DIP switch lettering on the CPU module has confused students in the past because the switches are active low and have weird markings. The switch being down on the side with the arrow head means the switch is OFF (GetSwitches() returns 0), and the switch being down on the side with the numbers (where it says "Off") means the switch is ON (GetSwitches() returns 1)

Important Notes:

Purpose:  Several employers have told us the one thing students don't do enough of as undergrads is look at someone else's code and fix it.  As it turns out, engineers in industry spend more time maintaining existing code than in writing new code.  So, this lab is designed to both (a) help you understand how multi-taskers work, and (b) give you some experience understanding and modifying existing code representative of what you might see in a reasonably good code base out in industry.

Lab depends on correct pre-lab: You need a working multi-tasker to complete the main lab (note that you only need one, so only one partner needs to have one). If neither partner has a working multi-tasker after the prelab due date be sure to come to office hours and get help completing it so you can do the lab.

"Spreadsheet math": When we say "spreadsheet math" we mean math based on calculations that can be reported via a spreadsheet-format part of your Acrobat file writeup. We specifically intend this to mean you don't have to show us a generalized mathematical formula; you just need to show your work in justifying a particular numerical answer.  ONLY the acrobat file will be considered in determining your grade.

Code: The code has several different variants all in the same file.  This technique helps ensure that bugs found in one variant are fixed in other variants, which is easy to get wrong if each variant is a different copy of the code.  We'll admit that usually there are fewer variants, but this approach does have its place.  If you are confused by all the #ifdefs it is OK to simply delete all the ignored chunks of code for a variant when trying to understand it.  But the answers you turn in must have all variants in a single .c file as this one does.

You may find it easier to check your answers visually by slowing down tasks so you can see the light patterns more easily (e.g., by increasing compute time for every task and also increasing the period of every task correspondingly). But, be sure to restore periods and task lengths before handing in your results.

Pre-Lab:

Goal:

• Understand cooperative and preemptive multi-tasking.
• Understand and modify existing code bases.
  

Discussion:

In this pre-lab, you will work individually to understand and implement various types of multi-taskers.  Refer to the appropriate lecture for more details about cooperative and preemptive multi-tasking and concurrency. 

The point of the pre-lab questions is to get you to closely study the provided code and understand it.  Most questions request you make a change to the source code and sometimes answer a question based on doing that. Changes to the source code should be handed in as part of your single program hand-in except where noted.  Do NOT make changes to the code EXCEPT where you are told to do so.  In some cases you will merely need to copy existing code from a different compilation case in the provided code and perhaps change it a little.  That's OK -- the point is for you to understand similarities and differences between approaches.  Note that this is a pre-lab and you should NOT be exchanging solution information with anyone else, including your lab partner until after you have both turned in your pre-labs.

Procedure:

Create a new C project in Code Warrior.  Download the lab_9_skeleton.c, rename it to prelab_9_andrewID.c and replace the default main.c.  Make sure you include the modclock library in your project.

This program runs on the stand-alone course module and does not require the project board at all.  When compiling and running your code on the module, make sure you select the TBDML option and plug the USB cable directly into the module.  Also, double check that your module jumpers are set to enable both BDM jumpers and power the module via the TBMDL port.

Part 1: UNTIMED_CYCLIC_EXEC

1. Enable #define UNTIMED_CYCLIC_EXEC
2. Comment out all other #defines
3. This should produce code that runs an untimed round-robin ordering of all enabled tasks
4. Compile and run this version. Play with the DIP switches to see what they do individually and in combination.

1. Enable #define CYCLIC_EXEC
2. Comment out all other #defines
3. This should run an untimed round-robin ordering of all enabled tasks, BUT that has a fixed period for running that loop

1. Enable #define MULTI_RATE_COOPERATIVE
2. Comment out all other #defines
3. This code should run as-is.  You do not have to add code for this to work.
4. This should produce code that runs an multi-rate cooperative tasker. The execution order will be round-robin of all active tasks.  Each active task will be run at its defined period.  Each tasks' period starts whenever it is activated, but flipping the switches quickly will not cause tasks to re-run any sooner than their defined periods.
5. Compile and run this version. Play with the DIP switches to see what they do individually and in combination. 
   

1. Enable #define PRIORITIZED_COOPERATIVE
2. Comment out all other #defines
3. This should produce code that runs a prioritized cooperative multi-tasker

1. Enable #define PREEMPTIVE
2. Comment out all other #defines
3. This runs a round-robin preemptive multitasker, which means that every active task gets an equal amount of time if it is active.
4. The compiler will generate a couple warnings about the inline assembly making the debugger's life hard; it is OK to ignore those warning (but not others!)

Lab 11 Brain Storming

This part of the pre-lab should be performed with your partner (both partners must include the lab 11 idea in their pre-lab).  You and your partner should come up with an idea for the final project. We're looking for simple projects that encompasses approximately two weeks worth of lab work.  Feel free to ask the instructor or TA's for suggestions or feedback on ideas.

This is not a full design proposal, we just want a brief idea of your project.

The final project must incorporate three or more of the following items in List 1:

• D/A
• A/D
• PWM
• CAN
• SPI
• Serial Communications
• Counter / timer
• Fixed point multiply
• Mutex
• Priority inheritance or priority ceiling

• One or more interrupts
• Watchdog / COP (does not count towards ISR requirement)
• Well defined scheduling
• Worst case timing analysis, state-chart design, and a test plan
• Use parts in the lab or inexpensive parts (< $5 total) we can get via Tech (requires staff approval)

• IRB approval for use of human subjects
• Use of hazardous or controlled chemicals

Note about RTOS projects:An example of an RTOS project would be to implement a mutex with priority ceiling protocol and use the counter/timer to initiate periodic tasks. Note that all other requirements for the project still hold (correct watchdog usage, interrupt, etc). An example of an interrupt includes: using SWI to implement yield. There are other possibilities (such as serial) but we point these out because to show that they are OK to count

Hand-in Checklist: (170 + 10 points)

All non-code submissions shall be in a single PDF document.

1. (160 points - 10 points per question) Complete questions Q1 - Q16 and include your answers in the following two files. 
   

• Turn in your final code listing as prelab_9_andrewID.c (Q3, Q4, Q9, Q10, Q13, and Q14).  You must follow the Coding style sheet to receive full credit. 
• Turn in your answers for all short answer and spreadsheet calculation questions in a single PDF file named prelab_9_andrewID.pdf (Q1, Q2, Q5, Q6, Q7, Q8, Q11, Q12, Q13, Q15, Q16).  (Note: No other files will be graded)

• (Bonus: 10 points) Answer Q17 in your lab write-up and include your code listing as prelab_9_bonus_andrewID.c. Your sleep call must use an SWI and you must follow the Coding style sheet to receive full credit.
• (4 points) Include a brief description of your idea for lab 11 (50 words or less) in your prelab_9_andrewID.pdf.  You will receive full credit for any idea that fits the above criteria. 
  NOTE:  We will ONLY look at the first 50 words.  Keep it short.
  
• (2 points) Include at least three items from List 1 you expect to include in your lab 11.
• (2 points) List at least two interrupts that would be useful for your project for lab 11.
• (2 points) State whether your idea would require additional components not found in lab.  If so, mention these extra components in your brief project description.  Remember, any additional components must be approved by staff.

Refer to the LAB FAQ for more information on lab handin procedures and file type requirements.  You MUST follow these procedures or we will not accept your submissions.

Lab:

Goal:

• Implement a prioritized preemptived scheduler.
  

Discussion:

The pre-lab skeleton you were given has a working multi-tasker (after you fill in the missing pieces). The primary design criterion for the multi-tasker was to be something you could understand as an extension of the cooperative tasking ideas.  That is why it uses the same data structures and a reasonably similar design approach.  But, this design approach is also the source of some fundamental limitations.  Some of these limitations can be fixed by redesigning it, and a redesign of that nature is the main focus of this lab assignment.

Reminder:  If neither partner was able to successfully complete the Part 5 Preemptive Multi-tasker, the TAs will help you get the tasker working. If this happens be sure to get help as early as possible

Procedure:

For the lab assignment, start by deleting all code that is ignored when the PREEEMPTIVE compilation profile is used (this is just to clean up the clutter).

Additionally, change the #define entries for periods so that PERIOD0 is 50 and PERIOD1 is 250 (instead of 5 and 20 as they were previously). (If you are curious, you can leave them at 5 and 20 and ask yourself why the lights never go on for Q2 below even though things worked fine for the pre-lab schedulers, but that is not a required part of this lab.)

Part 1:

Change the timer tick ISR so that the PREEMPTIVE scheduler implements a prioritized preemptive scheduler rather than a round-robin preemptive scheduler.  This means that on every timer tick, the task with the highest priority runs for the next time slice.  We suggest that you define any temporary variables such as loop variables as being static to avoid problems with stack usage in task switching.  You should NOT have to add any assembly language.

Q1. Hand in your code for the prioritized preemptive multi-tasker.  Save this version of your code as lab_9_q1_gXX.c (where XX is your group number).

Q2. Run the prioritized preemptive multi-tasker on the CPU module. How can you tell from the lights that it is prioritized rather than round-robin?

Q3. The multi-tasker in the skeleton runs the scheduler (Task 0) as a task.  This makes it simpler to understand the code compared to the cooperative multi-tasking examples we've shown you, but it is a source of performance problems, because Task #0 wastes a whole clock tick each time it runs as a task.  Rewrite the prioritized preemptive tasker so that Task #0 is called directly from the ISR rather than executed as a task.  Make sure that interrupts stay disabled until the end of the timer ISR.  Save this version of your code as lab_9_q3_gXX.c (where XX is your group number).

Q4. What is blocking time for the system you have created as a result of Q3?  Let's assume it is caused by the timer ISR.  Measure it using the simulator with breakpoints.  Take at least 10 measurements and report the longest blocking time you observe.  Why does the blocking time vary?

Bonus: Ensure your prelab bonus yield function works in the prioritized preemptive tasker (update it if needed).

Demo Checklist: (50 + 5 points)

1. (25 points) Demonstrate your lab_9_q1_gXX.c to the TA.  Show why it is prioritized now rather than round-robin.
2. (25 points) Demonstrate your lab_9_q3_gXX.c to the TA.  Show how you measured your blocking time and what the results were.
3. (Bonus 5 points) Optional.  Demonstrate your lab_9_bonus_gXX.c works and explain your implementation.
   

Hand-in Checklist: (105 + 10 points)

All non-code submissions shall be in a single PDF document.

1. (5 points) List any problems you encountered in the lab and pre-lab, and suggestions for future improvement of this lab. If none, then state so to get these points.
2. (40 points) Submit your code listing for Q1 as lab_9_q1_gXX.c.  You must follow the Coding style sheet to receive full credit.
3. (10 points) Answer Q2 in your lab write-up.
4. (30 points) Submit your code listing for Q3 as lab_9_q3_gXX.c.  You must follow the Coding style sheet to receive full credit.
5. (20 points) Answer Q4 in your lab write-up.
6. (Bonus 10 points) Optional. Include your code listing as lab_9_bonus_gXX.c. Your sleep call must use an SWI and you must follow the Coding style sheet to receive full credit.

Refer to the LAB FAQ for more information on lab handin procedures and file type requirements.  You MUST follow these procedures or we will not accept your submissions. 

Hints and Suggestions:

• When creating a task's launch stack, be careful about what value ends up in the CCR when you execute an RTI. Most of the CCR bits are arbitrary, but some aren't. Think about what each bit does, and ask yourself which of those bits could break the multitasking environment.

FILES for this lab:

• lab_9_skeleton.c
• modclock
• example spreadsheet

Relevant reading:

• Coding style sheet

Also, see the course materials repository page.

Change notes for 2015:

• 3/28/15: Added a hint about which values are safe and unsafe for the launch stack. --John