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

RedBoot

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.

• Anything that terminates execution abnormally prints the set of active stack frames
• Minimal version
  • name of calling function
  • line number of call
• Extreme version
  • values of arguments
  • values of local variables

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

• How would you implement it?

  Two basic questions to answer.

  1. When is it produced?
  2. What should be in it?
• How would you make it readable?

Breakpoint

What does it do?

• snapshot of the system
  • This means that computation, including respose to interrupts, must stop, or it isn't a snapshot.
• provides interactive tools for examining kernel data structures, such as
  • task descriptors
  • lists and queues
  • stacks, including the program counter and local variables, of individual tasks
• restart system immediately afterwards
  • If you want to continue where processing stopped you must make certain that all state is saved when you enter Beakpoint and restored when you leave it. What about pending interrupts? You can't stop the entire universe!
  • Otherwise you can re-enter RedBoot.

How do you get it started?

• function call, which you insert in your code when compiling.
  • The easiest and fastest form to implement.
  • Having the call as part of ASSERT is common.
  • Has to exit to RedBoot. (Jump to x00.)
• system call instead of function call, which respects the kernel/user distinction.
• an exception triggered externally
  • at initialization
    1. Set up the system so that the external event will generate an exception
    2. E.g. attach a button to PDIO on the third connector, set up ICU.
  • at run-time
    1. Trigger the interrupt
    2. Switch to Breakpoint in the event handler
    3. Either exit to RedBoot,
    4. Or clean up pending interrupts and resume execution.

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

• condition occurs => information is made available
• breakpoint provides the information interactively (`interactively' means `on the time scale of the user')
  • Breakpoint can stop the system completely. How?
  • but it has limited ability to stop the real world
    • i.e., it hides some bugs

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.

Gossip

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.

• As it travels it triggers sensors that give you feedback as to where it is.
• Actually, not quite where it is. There is a time lag.
  • Train triggers sensor at t: x(t) = Sn + 0 cm
  • Report of sensor is recorded (time-stamped) at t + dt. dt includes
    • interval between time of triggering and next sensor query
    • time for train controller to process query and return the result
    • time in your application between receiving bytes from train controller and packaging bytes into a time stamped event

    You should be able to estimate each of these time intervals

  • At t + dt: x(t + dt) = Sn + dx
  • dx = \int_t^(t+dt) v(t') dt' ~= v(t) dt
  • In the event time-stamped at t + dt the train appears to be at Sn, but it is actually at Sn + v(t) dt
  • Does this matter?
    • How fast do trains go? Estimate 20 cm/sec.
    • If dt is 100 msec you are off by 2 cm.

How do you know where the locomotive is?

• intermittently, at a sensor
• between sensors, dead reckoning, which means you need to know the train's velocity

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

• Velocity changes are not instantaneous.
  • After the speed is changed the train speeds up and slows down gradually.
  • `Tricks' that make the train stop instantly are not acceptable because they wear out the trains.
• The velocity decreases when travelling over turn outs or around curves.
  • The smaller the radius of curvature the slower the velocity.
• Different locomotives travel at different velocities when set to the same speed.
• Velocity of a given locomotive decreases over time
  • As the track gets dirty.
  • As the time since the locomotive's last lubrication increases
  • As the locomotive gradually wears out

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

• A turn-out switches while a locomotive is on top of it.
  • You need to estimate where the train will be when the turn-out switches in order to know if it is safe to execute a switch command
• Locomotives run off the ends of sidings.
  • You need to know how far a train will travel between when you give the stop command and when the train stops.
• Locomotives stall because they pass over difficult parts of the track too slowly.
  • Why? Friction increases when a train is on curved track.
• Sensors fail to trigger, or trigger in the absence of a locomotive
  • You need to know when you expect the sensor to be triggered if you are to know that it has not been triggered.

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
   • possibly on what type of track it is on
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:

• Bill Cowan's lecture notes for CS452 in s12
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page