ECEn 425

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


In this lab you will extend your kernel's functionality by adding several more key functions. With these extensions your kernel will be able to delay and switch between tasks. However, to ensure you have sufficient testing and debugging time, the application code for this lab will not fully exercise these capabilities. Lab 4d will further test your kernel. You are expected to complete this lab with a partner.


In this lab you will add the following features to your kernel, based on the YAK specification.

Once again, in addition to these required functions, you must have ISRs and interrupt handlers to support the reset, tick, and keypress interrupts, exactly as in lab 3. However, YKEnterISR and YKExitISR must be called by the ISRs, as described in the YAK Specification document. This will allow your kernel to switch tasks at the end of an ISR, thus supporting preemption of tasks and allowing another task to deal with the results of the interrupt.

Once you have implemented these functions, your kernel should be able to run the application code lab4c_app.c correctly without crashing. Make sure you look at the application code so that you understand what it is supposed to do. As before, your code must function with a tick frequency of every 750 instructions, no matter what key sequence is pressed. (At a high tick rate, there may not be enough time for the task to generate all its output in one tick interval, 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 task...
Starting kernel...
Task started.
Delaying task...


Task running after 3 context switches! YKIdleCount is 2330.
Delaying task...


Task running after 5 context switches! YKIdleCount is 2328.
Delaying task...


Task running after 7 context switches! YKIdleCount is 2328.
Delaying task...
The only thing that might differ when run with your kernel is the value of YKIdleCount.


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

Now would be a good time to review how ISRs should be written when used with an RTOS. Take another look at the document The 8086 Interrupt Mechanism if you are not completely sure how the ISRs should be written. Pay particular attention to where YKEnterISR() and YKExitISR() should be called.

It is quite possible that the new application code will uncover bugs that existed in your lab4b code. The addition of the new functions can also introduce new bugs into your code. Be aware of both possibilities as you debug.

Keep in mind that YKDelayTask and YKExitISR can both call the scheduler, allowing your kernel to break in new and interesting ways. Make sure that your kernel properly saves and restores context for all the cases outlined in lab 4a. Also, make sure that interrupts are disabled when they should be.

Debugging Help

Here is a statistical summary of the total time spent on part C in Fall 2017, according to the reports submitted by each group:

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

Student Problem List

Last updated 26 August 2019