CS452 - Real-Time Programming - Spring 2011

Lecture 16 - Anthropomorphic Programming

Pubilic Service Announcement

1. Possible bottlenecks in Terminal/ARM/Train system
   • train controller
   • ARM train controller communication
   • user

Serial I/O

Interrupts

Implementation

Task Structure

We are supposed to support

int Get( int port )

and

int Put( int port, char c )

These are wrappers for sends to one or more serial servers.

• On Get the server blocks the client until data is available
  • Does a non-blocking TryGet give you anything you cannot do with task structure?
• Put is non-blocking. The only guarantee is that the character has been added to a buffer of characters to be transmitted

How many servers and notifiers?

How should we handle a terminal?

Issues

1. Line editing
   • undefined intermediate states
   • well-defined trigger
2. Echo

   Either

   • one server per channel,
   • passing characters from one notifier to the other

   Or

   • courier connecting receive server to transmit server
   • What characteristics does the terminal have? termcap follies
   • Many other issues come up below as we consider possible task structures.

Anthropomorphic Programming

We all, even most programmers (!), have effective intuitions about human relations

• We use them to `understand' pets, which means attributing to them
  • goals
  • knowledge
  • capability
  • emotions
• Why not programs?
  • apply them to intertask relationships

Tasks are independent entities

• Understand them by thinking about them as if they have capabilities and goals.
• When you are developing something like the train application you are defining roles and relationships

Servers and Attendant Tasks

Why do servers need attendant tasks?

• What happens if a server calls AwaitEvent?

1. Proprietor with a Notifier

Proprietor `owns' a service, which usually means a resource.

• Think of the owner at the counter of an old-fashioned store
  • `store' means where things are stored;
  • it's in the back and only the proprietor can access it.
  • Many clients come to the front and are processed one by one.
  • Comment. The modern `store' is considered by many to be the most important innovation of the 20th century. (Yes, including the transistor, the computer, quantum mechanics, antibiotics, etc.) A whole lot of work that was previously done by store personnel is now done by the client. This is possible only because extensive codes of conduct have been internalized by clients. (That is, a large collection of new behaviour norms have been created and propagated.)
• Somebody has to sit out back waiting for the truck and bringing it to the proprietor

Kernel is handling hardware in this example

Notifier Code for a UART

• Initialize

  Receive( &serverTid, eventId );
  Reply( serverTid, ... );
      

• Work

  FOREVER {
    data = AwaitEvent( eventid );  // data includes event type and volatile data
    switch( data.event-type ) {
    case RCV_INT:
      Send( serverTid, {NOT_RCV, data.byte}, ... );
      break;
    case XMT_INT:
      // test transmitter, turn interrupt off and on?
      Send( serverTid, {NOT_XMIT}, byte );  // byte is to be transmitted
      store( UART..., byte )
      break;
    default:
      ASSERT( "This never happens because our kernel is bug-free." );
  }

Proprietor/Notifier Code for a UART

• Initialize

  // queues & fifos
  notifierPid = Create( notifier );     //Should notifier code name be hard coded?
  Send( notifierTid, MyTid( ), ... );   //On return notifier is known to be okay
  RegisterAs( );                        //On return requests can begin.
          

• Work

  FOREVER {
    requesterTid = Receive( request, {request-type, data} );
    switch ( request-type ) {
    case NOT_RCV:
      Reply( requesterTid, ... );
      enqueue( rcvfifo, data );
      if ( ! empty( rcvQ ) ) Reply( dequeue( rcvQ ), dequeue( rcvfifo ) );
      break;
    case NOT_XMIT:
      enqueue( xmitQ, requesterTid );
      if ( ! empty( xmitfifo ) ) Reply( dequeue( xmitQ ), dequeue( xmitfifo ) );
      break;
    case CLIENT_RCV:
      enqueue( rcvQ, requesterTid );
      if ( !empty( rcvfifo ) Reply( dequeue( rcvQ ), dequeue( rcvfifo ) );
      break;
    case CLIENT_XMIT:
      Reply( requesterTid, ... );
      enqueue ( xmitfifo, data );
      if ( ! empty( xmitQ ) ) Reply( dequeue( xmitQ ), dequeue( xmitfifo ) );
      break;
    default:
      ASSERT( "Never executed because notifiers and clients are bug-free." )
    }
  }

Notes

1. Notifier is usually of higher priority than server
   • Notice the early reply in the proprietor
2. When, and how, do interrupts get turned on and/or cleared?
3. Who coordinates hardware ownership?
4. We have made the code
   • exhibit duality explicitly
   • easy to break into parts
   • easy to extend

2. Using a Courier

Simplest is best

Transmit Notifier Code

• Initialize

  Receive( &courierTid, ... );
  Reply( courierTid, ... );
      

• Work

  FOREVER {
    Receive( &courierTid, byte );
    load( UART..., byte )
    data = AwaitEvent( eventid );
    Reply( courierTid, NOT_XMIT,  );
  }

Transmit Courier Code

• Initialize

  Receive( &serverTid, notifierTid );
  Send( notifierTid, ... );
  Reply( serverTid );

• Work

  FOREVER {
    Send( notifierTid, {data} );
    Send( serverTid, {req}, {data} );
  }

Transmit Proprietor Code

• Initialize

  // queues & fifos
  notifierTid = Create( notifier );
  courierTid = Create( courier );
  Send( courierTid, notifierTid, ... ); // On return courier & notifier are known to be okay
  RegisterAs( );                        //On return client requests will begin.
          

• Work

  FOREVER {
    requesterTid = Receive( request, {request-type, data} );
    switch ( request-type ) {
    case NOT_XMIT:
      enqueue( requesterTid, xmitQ )
      if ( ! empty( xmitFifo ) ) Reply( dequeue( xmitQ ), dequeue( xmitFifo ) );
      break;
    case CLIENT_XMIT:
      Reply( requesterTid, ... );
      enqueue ( xmitFifo, data );
      if ( ! empty( xmitQ ) ) Reply( dequeue( xmitQ ), dequeue( xmitFifo ) );
      break;
    default:
      ASSERT( "..." );
    }
  }

Notes

This gets you through a bottleneck where no more than two events come too fast.

Remember that all the calls provide error returns. You can/should use them for error recovery

• static error recovery: debugging
• dynamic error recovery: at run time

Another possible arrangement for task creation

• Server creates the courier
• Couier creates the notifier

Another possible arrangement for initialization

• Server Receives
• Courier sends to its parentTid
• Notifier sends to its parentTid

Distributed gating

I am showing you collections of tasks implemented together because sets of related tasks is a level of organization above the individual task.

• E.g., the decision to add a courier requires revision of code within the group, but not outside it.

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 useful results by inserting

    str   pc, <magic location>

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' = `on the time scale of the user')
  • it can stop the system completely. How?
  • but it has limited ability to stop the real world
    • i.e., it hides some bugs

Getting information closer to real-time.

Return to:

• Bill Cowan's lecture notes for CS452 in s11
• Bill Cowan's Spring 2011 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page