CS452 - Real-Time Programming - Winter 2013

Lecture 20 - Task Structure (Anthropomorphic Programming)

Pubilc Service Annoucements

1. First train control demo: 7 March.
2. Your routing should be able to find routes that require reversing.
3. Exam: 16.00, 11 April to 18.30 12 April.

Calibration

1. Calibrating Stopping Distance

2. Calibrating Constant Velocity

3. Calibrating Acceleration and Deceleration: Minimal

4. Calibrating Acceleration and Deceleration: Doing Better

Back to real trains. When you drive a train there are four things you care about, all of which are functions of time. Particularly you care about the effects of discontinuities in them.

1. Location on the track, specified by x(t), usually anchored at the previous sensor.
   • A discontinuity is teleportation, which requires infinite velocity.
2. Velocity along the track, specified by v(t) = x'(t).
   • A discontinuity is an instantaneous change in velocity, which requires an infinte force.
3. Acceleration, specified as a(t) = v'(t) = x''(t).
   • A discontinuity in acceleration, which feels like a jerk. Think of what it feels like when you are tied to a rope that is being pulled. First the rope exerts no force on you, then suddenly there is a jerk and you feel a force. Not nice.
4. Jerk, specified as j(t) = a'(t) = v''(t) = x'''(t)
   • We can avoid discontinuities in acceleration by having jerk constant, possibly with discontinuities.
   • Thus, j'(t) = x''''(t) = 0.

Modelling Velocity

When we model there are two distinct, but easy to confuse, things we care about:

1. where the train is on the track, and
2. where the train is in your model.

Ideally these two quantities would be exactly equal. So our goal is to minimize something like the absolute value of the difference, or the squared difference between them.

Lemma. Whoever programmed the micro controller in the train knows a lot about trains, not much about computer science, and is lazy.

How does the location change over time if the velocity is constant.

Allow there to be an infinite acceleration (= force)

Then at the right time, whenever that is, change the velocity in your model of the train

1. From the initial velocity to the final velocity.
   • When do you change it?
   • What error do you have in the train position when you change it at the right time.
   • Draw pictures of velocity and position on the board.
2. From the initial velocity to an intermediate velocity to the final velocity.
   • When do you make the changes?
   • What should the intermediate values be.
   • Draw pictures of velocity and position on the board

Allow there to be an infinite jerk

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.

Return to:

• Bill Cowan's lecture notes for CS452 in w13
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's homely page