Training: real-time, embedded and concurrent programming

This site contains the material for the ST training in January 2014. Goals are to understand the issues of real-time and how application requirements translate to solutions consisting of tasks that must meet deadlines. In addition, through simulation and measurements, understand that computer actions take time, and that this is non-trivial to understand.

The topics addressed are:

First part (Jan 15-Jan 20)

1. Days 1-2: Introduction. Real-time tasks. Programming based on a simple task execution model. Implementation and extension of a task oriented kernel. Performance measurements.
2. Day 3-4: timing and scheduling. Further performance measurements. Understanding how to realize predictability.

Second part (three more days):

3. A summary of part 1, lessons learned.

4. Leftover of ‘Day 4’ above.

5. Timer queue management (improving over the downcounting, and generalizing)

6. Resource sharing, resource access protocols.

In the ‘First part’ we start from the concept of repetitive real-time tasks and show how a simple kernel can be built around the timer interrupt. We also visit ‘traditional’ RTOS concepts. In the ‘Second part’ (not in January) we examine a real-time kernel that is used in existing products, we see how it works and can be used.

People involved

• prof. dr. Johan Lukkien (MF-6.070)
• dr. Richard Verhoeven (MF-6.079b) [Hardware and system software support, questioning]

Specific goals

1. Study and experience a modern embedded microprocessor.
2. Understand various implementations and correspondent programming models for real-time task-based systems.
3. Understand the timing issues involved.
4. Obtain experience with programming such system.
5. Obtain experience in performance evaluation.
6. Understand effects of programming on timing, code size, energy use and memory use.
7. Obtain experience with tools for such systems.

Organization

This course reflects research work we are currently involved in and has some rough edges. The predominant way of learning we see is by doing: designing, programming, measuring. There are many - probably too many -- exercises in the slides.

We have lectures, questions and discussion in the morning (2-3h, somewhat more the first day). The remainder of the time is for practicing. There will always be someone available for questions and feedback.

Students work in pairs on the exercises. We have exercises of varying level and complexity to account for differences in background. Besides the topics mentioned, the training involves working with Linux in a virtual machine, using Linux compile tools and using a hardware simulator.

Write a report in the form of a logbook while you work. It will be judged on two independent metrics: quality and quantity. Indicate in that report what you plan and what the result is. Add explanations, diagrams, photographs, videos and measurements where needed. Hand in a (partial) report at the end of each day on a website or dropbox (i.e., I want to receive a link); grow the report while the course proceeds.

Slides

• Real-time software, introduction
• Real-time software, reference model
• Real-time software, software structure and task scheduling
• Real-time software, schedulability analysis
• Real-time software, summary, multi threading

Material

We provide a TI MSP430 microprocessor, as part of the Sensixa BSN.v3 platform (a wireless sensor) or as part of the Crosbow TELOSB platform. We provide a programming environment in the form of a Linux virtual machine with a special C compiler and loader tools. You can either load a binary onto a physical node and use an oscilloscope to perform measurements or use the provided simulator.

The material is found on https://www.win.tue.nl/san/education/OOTI/. Source codes for the programs discussed in the course are in principle located in the virtual machine as explained on the above site. They can also be downloaded from below (to ensure a fresh copy). This and further material is listed below.

• MSP430 description. See also Web sources for extensive references on this microprocessor.
• MSP430 UART description.
• ErrorCodes.h
• Led.h, Led.c
• Clock.h, Clock.c In the Clock startup routine the timer divide is set (CCR0 = ACLOCK/TicksPS-1); however, the simulator and the hardware disagree on this. In the simulator the '-1' should be removed to obtain the same timing as in the hardware.
• Scheduler.h,
• SchedulerNPBasic.c, SchedulerNP.c, SchedulerPre.c
• Uart.h, Uart.c
• SchedTest.c. Use the macros to select particular test behavior.
• Scheduler.MultiTask.c, multi-threaded scheduler
• Semaphore.h, Semaphore.c
• Makefile

Rules for the report

• Make a single file or site. Include any pictures or handwritten notes in that file, not in separate files. Remember, I want an extending report.
• Name your work such that subsequent versions of your report can be logically stored together. So, report.doc is not very good. ReportX.Y.Date.doc where X and Y are names is a lot better. If you use one document, indicate clearly where the entry of a new day starts.
• Make it readable and coherent, something you or one of your colleagues can read as well.
• Anwer the questions asked with a concise explanation. Use code (probably copied from your work) to explain your solution. An example of how such a thing might look is as follows.
• “We solved the problem of maintaining a real time clock. We maintained a simple counter as a clock register. In order to address the 32 second wrap around we .... ; our clock now has a period of .... For the programmer API we have the following functions: .... Using the function ... we can now specify a task to be scheduled at a certain absolute time (relative to the initial value). The implementation is as follows ... (piece of C text).” etc. etc.
• Include results, expectation, findings, methods. Another example: “in order to measure the overhead of the interrupt routine we instrument the code as follows.... From the simulator/oscilloscope (picture) we found that the overhead for a system without tasks is ... and ...”