ECEn 425

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

Overview

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.

Requirements

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.

TICK 1

TICK 2
Task A, delaying 2.

TICK 3
Task B, delaying 3.

TICK 4
Task A, delaying 2.

TICK 5
Task C, delaying 5.

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

TICK 7

TICK 8
Task A, delaying 2.

TICK 9
Task B, delaying 3.

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

TICK 11
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.

Pass-off

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.

Debugging Help

Here is a statistical summary of the total time spent on part D in Fall 2017, 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 26 August 2019