CS452 - Real-Time Programming - Spring 2012

Lecture 16 - Serial I/O Implementation

Public Service Annoucements

  1. Assignment 4
  2. Exam: 9.00, August 8
  3. Performance measurements
    1. Send First - Receive First: off,0--100,4,0,0 -- on,2--0,10,6,3
    2. usec/byte -- off,0--4,4,8,1.4 -- on,2--0.1,0.1,0.2,0.0,0.0
    3. off/on -- 16,9,9,10,30
    4. 0/2 -- 10%,10%,6%,3%
    5. best -- 7,20,16,15,12

Debugging Real-time Programs


The memory contents are not wiped by reset. Some of the most difficult errors can be detected only by using the contents of memory after a reset. Produce more useful results by inserting

    str   pc, <magic location>

and the like into your code and, with the assistance of a load map, finding out where you were in whose code when the problem occurred.

Stack Trace

In single-threaded programs this is often the most useful tool.

What is the equivalent of a stack trace in a real-time multi-tasking environment?


What does it do?

How do you get it started?

Breakpoint is a special case of a particular sort of tool that is very common.

Breakpoint operating on the corpse of an execution terminated by reset or an ASSERT is called Autopsy.

Getting information closer to real-time.

Symptoms of bugs often occur a while after the bug itself. Thus we often want to know what happened in the time immediately previous to the observation of bug symptoms. (Most often 'bug symptom' is no more than a fancy way of saying 'crash'.)

Use bits

Set aside a block of memory and assign each bit to an event that occurs during execution of the program. Set the bit when the event occurs. Then you can see what has, or has not occurred prior to the bug becoming visible.


A special task maintains a circular buffer. Any task can send a message to the task with a string that will be inserted in the circular buffer.

Execution Visualization

Most important is the necessity of accommodating the fast time scale of the computer to the slow time scale of the human.

Train Properties

A locomotive travels on the track at a given speed following the path created by directions of turn outs.

How do you know where the locomotive is?

Velocity is controlled by changing the train's speed, BUT, the mapping between speed and velocity is complex.

Important. Some of these effects matter; some don't. It's part of your task to find out which is which.

Furthermore, things can go wrong, such as

Avoiding such failures, or responding sensibly to them, is possible only if you have a `good enough' velocity calibration. (You get a perfect calibration only in the limit t->infinity, and train you are calibrating is dead long before that.) Failures like these also pollute your attempt to acquire reliable data for your calibration.

Factors that might effect a calibration.

In general the velocity of a locomotive may be a function of many variables

  1. which locomotive it is
  2. which speed is set
  3. time since the last speed change
  4. the velocity at which it was travelling before the last speed change
  5. where it is on the track
  6. how long since the track was cleaned
  7. how long since the locomotive was lubricated

Important. Some of these effects are matter; some don't. It's part of your task to find out which is which.

Return to: