ECEn 425

Lab #6: Message Queues


In this lab you are to add functions that create, pend on, and post to message queues so that you can correctly execute the application program lab6app.c without modification. You are expected to complete this lab with a partner.


You must add these kernel functions to your kernel. You should implement each function exactly according to the prototype given on the YAK Kernel webpage. Refer to that web page for additional details about these functions.

For this lab, you should modify your interrupt handlers in the following ways:

An example of the code required for your keypress and tick handlers can be found in the file lab6inth.c. You will also need the file lab6defs.h, which is used by the sample file lab6inth.c and the application code. The mytick() handler code in lab6inth.c should be called by your tick ISR in addition to your kernel's YKTickHandler code. Note that the sample tick handler code assumes the existence of the global variable YKTickNum, which should already be defined in your kernel code and is assumed to also be declared as extern in yakk.h.

The tick handler code in the sample file initializes objects of type "struct msg". This struct type is defined in lab6defs.h. The tick field in this struct is set to the current tick count and the data field is set to a pseudo-random number. A pointer to the object is then posted to the message queue. A task in the application code removes the pointers from the queue (i.e., pends on the queue) and reads the object pointed to by the pointer. The task then displays the tick field read from the object followed by the minimum data field value read so far and the maximum data field value read so far. A sample of what the program's output should look like is shown below.


Implement the required functions and make sure that the application program runs correctly. For full credit on this lab, the system should not crash when key presses occur in rapid succession, even with the timer tick frequency increased to 750 instructions. While your code should not crash at higher tick rates, it may not give exactly the same output because there may not be enough time between ticks for all tasks to finish what they would normally do for that tick. For full credit, your kernel must be efficient enough to avoid dropping any messages at the default tick rate (1 tick every 10,000 instructions). At the default tick rate, the application's output should match the following (other than the CPU usage):
Welcome to the YAK kernel
Determining CPU capacity
Ticks: 1        Min: 89 Max: 89
Ticks: 2        Min: 78 Max: 89
Ticks: 3        Min: 67 Max: 89
Ticks: 4        Min: 56 Max: 89
Ticks: 5        Min: 45 Max: 89
Ticks: 6        Min: 34 Max: 89
Ticks: 7        Min: 23 Max: 89
Ticks: 8        Min: 12 Max: 89
Ticks: 9        Min: 1  Max: 89
Ticks: 10       Min: 1  Max: 90
Ticks: 11       Min: 1  Max: 90
Ticks: 12       Min: 1  Max: 90
Ticks: 13       Min: 1  Max: 90
Ticks: 14       Min: 1  Max: 90
Ticks: 15       Min: 1  Max: 90
Ticks: 16       Min: 1  Max: 90
Ticks: 17       Min: 1  Max: 90
Ticks: 18       Min: 1  Max: 90
Ticks: 19       Min: 1  Max: 91
Ticks: 20       Min: 1  Max: 91
Ticks: 21       Min: 1  Max: 91
Ticks: 22       Min: 1  Max: 91
Ticks: 23       Min: 1  Max: 91
Ticks: 24       Min: 1  Max: 91
Ticks: 25       Min: 1  Max: 91
Ticks: 26       Min: 1  Max: 91
Ticks: 27       Min: 1  Max: 91
<<<<< Context switches: 62, CPU usage: 11% >>>>>
Ticks: 28       Min: 1  Max: 92
Ticks: 29       Min: 1  Max: 92
Ticks: 30       Min: 1  Max: 92
Note that the Ticks column lists the tick numbers in sequential order, without skipping any numbers. The Min column gets smaller, eventually reaching 0, and the Max column gets larger, eventually reaching 99.

Eventually, as the tick frequency increases, messages will be dropped because the task that removes messages from the queue won't be able to keep up with all the entries posted to the queue by the tick handler. When this happens, you will see tick numbers being skipped and error messages indicating that messages have been dropped. For full credit, at 750 instructions/tick, the task should still be able to occasionally remove an object from the queue and display the "Ticks: # Min: # Max: #" text, even if you are holding down a key and causing the CPU hog to run.

Pressing a key sets a global flag that causes a task to run. This task saturates the CPU for five clock ticks and causes a series of periods ('.') to be displayed. This output must be generated when a key is pressed.


When you are confident that your kernel runs the application program correctly, demonstrate its execution to a TA. Be prepared to show the TA your source code and to discuss it and your design decisions. Since you must demonstrate working code to a TA on or before the due date, please consider their lab schedule well in advance.

In addition to the demonstration, you should submit via Learning Suite a .txt or .pdf document with a written summary of problems you encountered, if any, and a realistic estimate of the total number of hours you spent on this lab. You are also invited to include suggestions on additional information that could have been included on the web pages, or additional simulator features that would have reduced your debugging time.

Important Notes

Debugging help

Here are comments from student reports (edited only for length) describing their problems on this lab and how they tracked them down. As always, take them with a grain of salt.

Last updated 31 August 2018