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:
The only thing that might differ when run with your kernel is the value of YKIdleCount.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...
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:
and then upload the resulting compressed tar file (submission.tar.gz)
to Learning Suite.
tar -cvzf submission.tar.gz labx
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.
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.