ECEn 425

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


In this lab, you begin writing the actual code for your implementation of the YAK kernel. You will be required to implement a small number of the kernel functions in order to run a very basic application program. You are expected to complete this lab with a partner.


Start by creating a directory with all the source files necessary for your kernel, including the makefile. Suggested filenames and their purposes are given in the YAK Specification document. Make sure you backup often so that you never accidentally lose any of your source files! It is also recommended that you make a new copy of your code in a new folder for each lab. Once you have your files set up, you can begin writing your kernel according to the implementation decisions you made in the last lab.


For this lab you only need to implement a small subset of YAK's overall specification. The kernel features you must implement are listed below: In addition to these required functions, you must have ISRs and interrupt handlers that function exactly as in lab 3. Keep in mind all the other YAK functions that will be added to your code in later labs. If you are not careful or if you take shortcuts then you may need to rewrite and re-debug parts of your code in later labs. In particular, think about what functions must be reentrant in your kernel, and be sure to recognize and address critical sections in the code you write. This can save you many hours of added work down the road.

The application code you will use for this lab, lab4b_app.c, creates a total of three tasks. The first task, task A, is created in main() before YKRun() is called. Task B is then created within task A, but has a lower priority than task A, and therefore should not run. Next, task C is created within task A and task C has a higher priority than task A, and should therefore run immediately. This will help verify that your kernel can properly create, schedule, and dispatch tasks.

Once you have implemented these functions, your kernel must be able to run the application code correctly without crashing. As before, your code must work correctly even when a key is held down or when any key sequence is typed in rapid succession. It must also support a tick frequency of every 750 instructions. When your kernel runs correctly, the application program's output should closely resemble the following after it starts running:

Creating task A...
Starting kernel...
Task A started!
Creating low priority task B...
Creating task C...
Task C started after 2 context switches!
Executing in task C.

Executing in task C.


Executing in task C.

Executing in task C.
The only thing that may differ when run with your kernel is the position of the "TICK n" lines relative to the other lines of output.


When your kernel runs the given application code correctly, show and demonstrate your code to a TA. Since you must demonstrate working code to a TA, please consider their lab schedule well in advance. If you complete the lab after the last TA hours on the due date, you can still get full credit based on the time stamps on the relevant files.

In addition to the demonstration, you must send email to the Lab TA with a written summary of problems you encountered, if any. Be sure to identify both partners in the email. We are compiling a database of bugs encountered to help future students, so describe the symptoms and the solution you devised. Your email should also include a report of the number of hours you spent on the lab, including coding and debugging. A realistic estimate is sufficient. If you felt that you spent an excessive amount of time, please describe what additional information or preparation would have made the lab more straightforward for you. For example, you might feel that the lab or YAK web pages are missing some useful information that would have cleared up a misunderstanding you had, or you might attribute it to a misunderstanding about C. Send email 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.

Important Notes and Recommendations

Debugging Help

The link below points to a list of comments from student reports for lab 4 (parts B, C, and D) describing specific problems they encountered. You are strongly encouraged to read the list. However, take all these with a grain of salt; the submitters may have made very different design decisions than you have. However, you can glean a great deal of useful information by reading them carefully.

Student Problem List

Last updated 29 August 2016