Assignment 3

UBC | EECE 494 | Spring 2011

Released on February 22 Due on March 28 (9:00 a.m.)

In this assignment you will extend a small real-time operating system kernel (Nano-RK) and you will also work with (and learn) a tool chain for embedded systems development. You can use a Windows-based system and Cygwin for this mini-project/assignment. There are several goals to this assignment: Understand the architecture and design choices behind a real-time operating system kernel; Extend the capabilities of the RTOS kernel; Develop an understanding of the tool chain for embedded systems development; Gain an appreciation for the challenges of embedded software development; Improve upon work of others by examining prior engineering choices; Design and implement techniques for testing your modications to the kernel.

Tasks

T0a: Install the WinAVR emulator and Nano-RK. Obtain Nano-RK from the Nano-RK website. Follow the steps outlined on the Nano-RK support page for WinAVR Studio. You may also want to follow these additional instructions (courtesy Bader Al Ahmad) concerning the installation of Nano-RK and WinAVR (in particular, Step 3 of the instructions on the Nano-RK support page): 1. Download and Install Cygwin with the following modules: make svn (subversion) open-ssl gcc-core bison (required to compile avrdude) flex (required to compile avrdude)

2. Download and install WinAVR-20071221rc1. 3. In the Cygwin shell, execute the following commands: cd mkdir temp TMPDIR = /temp export TMPDIR svn checkout svn://nanork.org/srv/svn/repos/nano-RK 1

The source code for Nano-RK is accompanied by several examples that will help you develop your own application easily. You should read the code for the example applications because they represent many of the features of the sensor node platform and Nano-RK. Read the code for Nano-RK itself. For this mini-project/assignment, you can initially restrict your attentions to a few les in the kernel directory of the source tree. The main source les that you will need to become familiar with, and modify, are nrk.c, nrk_task.c and nrk_scheduler.c, but you will also need to examine, and probably alter, some other functionality. T0b: Develop a project plan. Divide the tasks/milestones among your group and establish due dates for the milestones. If multiple group members are going to participate in the same task then indicate the share of the responsibility each group member will take on. The project plan is due on Feb 25 via email to the instructor and the teaching assistant. If there are concerns about the distribution of work and the deadlines set, you will receive a response regarding the concerns. T1: EDF support. Nano-RK has been designed to support static priority scheduling. Extend the scheduler to support EDF. You may assume that tasks have relative deadlines that are equal to their periods. How will you test your implementation? Develop suitable tests to demonstrate that you have, indeed, implemented EDF. Modify the task structure in Nano-RK appropriately. T2: Stack-based resource access protocol. To support resource sharing with the EDF scheduler, extend the semaphore implementation of Nano-RK to use SRP. (By default Nano-RK supports the Priority Ceiling Protocol.) Again, develop suitable tests to demonstrate that your implementation of SRP is correct. T3: Implement constant bandwidth servers. The default Nano-RK system supports periodic tasks and provides a CPU reserve for each task. When a task exceeds its reserve, an error is registered. An alternative model that is useful in multiple cases (e.g., soft realtime systems where each task merely needs a guaranteed fraction of processing time and when dealing with aperiodic tasks) is the constant bandwidth server that works with earliest deadline rst scheduling. Read the chapter on Dynamic Priority Servers in the book Hard Real-Time Computing Systems by Buttazzo; the discussion of the constant bandwidth server begins on Page 179. In essence, CBS allows tasks that exceed their nominal CPU reserve to continue execution - or stay in the ready queue - by postponing the deadline of the task. Nano-RK provides methods for creating and managing periodic tasks. A sample fragment of code for adding a task looks like this: nrk_task_set_entry_function( &TaskOne, Task1); nrk_task_set_stk( &TaskOne, Stack1, NRK_APP_STACKSIZE); TaskOne.prio = 1; TaskOne.FirstActivation = TRUE; TaskOne.Type = BASIC_TASK; TaskOne.SchType = PREEMPTIVE; TaskOne.period.secs = 0; TaskOne.period.nano_secs = 250*NANOS_PER_MS; TaskOne.cpu_reserve.secs = 0; TaskOne.cpu_reserve.nano_secs = 50*NANOS_PER_MS; TaskOne.offset.secs = 0; TaskOne.offset.nano_secs= 0; nrk_activate_task (&TaskOne); For this assignment, add a new type of task that would be managed by a constant bandwidth server. Creating a task that is managed by a CBS would be similar to creating a regular periodic task and would like this:

nrk_cbs_set_entry_function( &CBS1, Task1 ); nrk_cbs_set_stk( &CBS1, Stack1, NRK_APP_STACKSIZE ); CBS1.prio = 1; CBS1.FirstActivation = TRUE; CBS1.Type = CBS_TASK; CBS1.SchType = PREEMPTIVE; CBS1.period.secs = 0; CBS1.CBS1.period.nano_secs = 250*NANOS_PER_MS; CBS1.cpu_reserve.secs = 0; CBS1.cpu_reserve.nano_secs = 50*NANOS_PER_MS; CBS1.offset.secs = 0; CBS1.offset.nano_secs= 0; nrk_activate_cbs ( &CBS1 ); Add the primitives needed to manage constant bandwidth servers at the programming interface and within the kernel/scheduler. A software developer should be able to build an application that uses a combination of regular periodic tasks and constant bandwidth servers. Tasks are scheduled using EDF therefore the priority eld is used only to break ties when two jobs have the same absolute deadline. You may assume that a job of a task is not released until the previous job of the same task is complete. T4: Implement the CASH approach for capacity sharing. CBS has a limitation in that when tasks do not fully use their budget other tasks cannot exploit this extra processing capacity, i.e., all tasks use only their own budget and cannot leverage extra capacity that may result from jobs completing early. CASH is an approach that addresses this limitation. Read the article titled Capacity Sharing for Overrun Control that appeared in the IEEE Real-Time Systems Symposium in 2000 and implement the CASH method described by Caccamo, et al. Several real-time operating systems do implement schemes that are rather similar to CASH when they co-schedule hard real-time and soft real-time tasks. T5: Explore simple tradeoffs for improving the performance of embedded applications. Implement an algorithm for Discrete Cosine Transforms (see the attached baseline.c) and execute it on the NanoRK+WinAVR Studio platform. (You may rst want to complete this on some other platform before moving to Nano-RK.) Such transforms are used in image processing and thus this code could well be part of a video camera application (which would presumably be a real-time application) running on a mobile device. The provide code is for determining the discrete cosine transform of a 8 8 pixel block. The original block is the img array (which is hardcoded into the program) and the output is the f array, which is then printed out to the screen. You can eliminate the output segment of the program for this task. You will likely need to compile the program with the -l option to use the math library. Sometimes it is necessary to rewrite modules of a real-time system to reduce the execution time and make the system schedulable. One of the slowest portions of the DCT algorithm is the cosine function. To reduce this inefciency, replace the call to cos( ) with a table lookup: static const int COS_TABLE[8][8] = { { 32768, 32138, 30273, 27245, 23170, 18204, 12539, 6392 }, { 32768, 27245, 12539, -6392, -23170, -32138, -30273, -18204 }, { 32768, 18204, -12539, -32138, -23170, 6392, 30273, 27245 }, { 32768, 6392, -30273, -18204, 23170, 27245, -12539, -32138 }, { 32768, -6392, -30273, 18204, 23170, -27245, -12539, 32138 }, { 32768, -18204, -12539, 32138, -23170, -6392, 30273, -27245 }, { 32768, -27245, 12539, 6392, -23170, 32138, -30273, 18204 }, { 32768, -32138, 30273, -27245, 23170, -18204, 12539, -6392 } }; 3

The value of cos((2a + 1)b/16) can then be approximated by COS_TABLE[a][b]/32768.0. Use the above table, and replace all the calls to cos( ) with an access to the table as described above. You need to measure two quantities: 1. The impact on run-time. Hopefully, the modication described above will reduce the runtime of the algorithm. I would expect that most people would see a signicant speed-up here. 2. The impact on accuracy. This modication will also have an impact on accuracy, since fewer bits are used to represent the value of the cosine function. One way to quantify the accuracy is by using the following metric: 1 N1 (xi yi )2 , N i=0 where N refers to the number of samples the program calculates (64 in this case). The quantity xi refers to the ith sample calculated by the original program, and the quantity yi refers to the ith sample calculated by the program as modied in this task. Clearly, if there was no impact on accuracy, this quantity would be 0, however, I will expect that you will obtain a non-zero value.

Documentation and submission

Write a clear report for Tasks 1-4. Describe your implementation for the tasks. The report should be submitted as a PDF le and should include the names of the group members. Notice that we do not provide any tests for correctness. In engineering practice, you should consider testing mechanisms in conjunction with the design. You should describe clearly the methods you used to verify the correctness of your implementation. Use handin to submit your work. For your implementation effort, you will (and should) only submit the les from the NanoRK source code that were changed. Invoke handin from ssh.ece.ubc.ca as follows after making sure that all the necessary les are in a directory named a3: handin eece494 a3

Grading
T0b: 5% T1: 20% T2: 20% T3: 15% T4: 20% T5: 10% Report: 10%

The mark distribution for the different tasks in this assignment is as follows: