ECEn 425

Lab #4: Design and Implementation of Kernel Essentials
Part D


In this lab you will use a more sophisticated application program to better stress test your kernel. Due to the increased complexity, new bugs may reveal themselves and your assignment will be to track down the bugs and fix them. You are expected to complete this lab with a partner.


To fully exercise your kernel's functions, your kernel will use the application code lab4d_app.c. You must support the reset, tick, and keyboard interrupts as in previous labs. Make sure you look at the application code so that you understand what it is supposed to do.

Unlike lab 4c, the application for this lab supports multiple tasks. Your kernel must be able to properly switch between them as YKDelayTask is called and interrupts occur. It must be able to run this application correctly with the default tick frequency and without crashing with a tick frequency of every 750 instructions. (At a high tick rate, there may not be enough time for all tasks to run to their next delay point as they otherwise would, so your output may differ from that shown below, but your code should not malfunction or otherwise fail to make progress.)

Below is a sample of what the application's output should look like:

Creating tasks...
Starting kernel...
Task A started.
Task A, delaying 2.
Task B started.
Task B, delaying 3.
Task C started.
Task C, delaying 5.
Task D started.
Task D, delaying 10.


Task A, delaying 2.

Task B, delaying 3.

Task A, delaying 2.

Task C, delaying 5.

Task A, delaying 2.
Task B, delaying 3.


Task A, delaying 2.

Task B, delaying 3.

Task A, delaying 2.
Task C, delaying 5.
Task D, delaying 10.

Notice how the output shows that each task is delayed for the expected number of ticks. Also, note how task priority is enforced, even when multiple tasks become ready after the same tick interrupt. Your kernel's output should match this example unless your kernel cannot dispatch and run the four tasks before the first tick occurs.


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 should send email to the Lab TA with a written summary of problems you encountered, if any, and the total number of hours you spent on this lab. A realistic estimate is sufficient. 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 cut your debugging time. You will not receive full credit for the lab unless you send a report.

Debugging Help

Here is a statistical summary of the total time spent on part D in Fall 2010, according to the reports submitted by each group: Make sure you change your #define for the maximum number of tasks, since the application code for part D has more tasks than the previous applications. You will need to adjust this #define for all future labs.

Once again, you may want to look at the problems students had in past semesters. The link below points to the list of comments from student reports for lab 4.

Student Problem List

Last updated 29 August 2016