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 the kernel runs the application code correctly, show and demonstrate your code to a TA. 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 must a written summary of problems you encountered, if any, in completing this lab. You should also include a report of the number of hours you spent on the lab, including coding and debugging. A realistic estimate is sufficient. Send a submission even if you didn't encounter any noteworthy bugs along the way. You will not receive full credit for the lab unless you send a report.

New for Fall 2019: we want both your report and your source code for the lab. The easiest way to do this is to create a report file (for consistency call it report.txt or report.pdf), to add it to the working directory for the lab, to create a compressed tar file (with all the files in your directory), and then to upload that file to Learning Suite.

To review, if 425/labx is your working directory for this lab, type the following in the 425 directory:

 tar -cvzf submission.tar.gz labx
and then upload the resulting compressed tar file (submission.tar.gz) to Learning Suite.

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 26 August 2019