ECEn 425

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

Overview

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.

Requirements

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.

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

Creating task...
Starting kernel...
Task started.
Delaying task...

TICK 1

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

TICK 3

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

TICK 5

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

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 send email to the 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.

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 2007, 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 17 December 2007