View page as slide show

Communication software and architecture

To be implemented

  • Communicating protocol objects (CPO)
    • Entity and connection CPO's (connectionless and connection oriented)
    • behaviour (state machines)
  • Messages
  • Communication between CPO's and layers

State machine implementation

  • In a proper state machine design you should be able to identify from the code one to one equivalents to the following FSM components.
    • Events
    • States
    • Current state
    • Event handler functions for each state
  • State machines with nested case statements
    • Switch on state first then switch on event type
    • behaviour code inside case statements
    • Hard to upkeep and handle
  • State Jump Table
    • State Jump Table contain array of states, events and pointers to functions to be called in each states.
    • When event is raised, common FSM code will search the table to find a function that has to be called depending on the current state.
    • No behaviour code inside FSM

C Implementation

  • Extract the message from input device.
  • Find what transition function has to be called based on the current state and input type
  • In transition function perform required tasks, message output etc in the transition function
  • Change the state if required
  • Events such as Timer expiries which don’t map to messages should be modelled using the same structure as messages
  • Events can be modeled with enumeration
    • messages, timers etc.
 enum EventType {ConReq, ConRsp, Ack,  TimerExp...} 
  • States can be enumerated too
 enum states {idle, WaitForAck, connected...} 
  • switch case state machine
 switch (current_state)
        case (idle): /* or case (1) */
          switch (event):
             case (1): TransitionFunction (event,state)
        case (WaitForAck):
           switch (event):
  • table FSM
    • structure
    int (*ptr2transition)(msg, event) = NULL; 
    fsmTable[event][state]=ptr2transition function 
  • Initialisation of table
    fsmTable[idle,ConReq] = ConnectionRequest
    fsmTable[idle,Ack] = defaultFunc

State pattern


* Messages can be implemented as 
struct Message {
    enum MessageType message_type;
    char  contents[MSGLEN];
  • class
    • contains at least type and contents
    • possible additional functions to handle the message and its contents
      • encoding and decoding rules may be implemented, although in many case it is better to have implement them where the encoding is used.

Message passing

  • Inter Layer Communication
    • All OSI and ITU protocols are layered protocols
    • In OSI the communication between layers is modelled as primitives
    • Primitives are like messages in that they are input events to state machines
  • When a message is extracted from an input buffer and passed through code, the message shouldn’t be copied as this is resource intensive. Instead references to the message should be passed.

Event Driven Programming

  • There are two ways to write code that responds to events
  • Event driven programming
  • Polling


  • Polling is when you sit in an endless loop, constantly checking an input queue
  • For example:
void EventDispatcher::loop()
    while(1) {
	    pause(10MS); // Pause the thread 10 milliseconds	
        Event* event = getevent();
        if(event) {

Disadvantages of Polling

  • Task has to pause between polls to allow time for other tasks to be scheduled in
  • Response time - between event occurring and action being performed depends on duration of the pause
  • If fast response time is required this method consumes significant processor time (power)
  • Polling should be avoided in most cases. Instead of polling an event driven (for example interrupt driven) approach should be used.

Valid excuses for using Polling

  • Operating System limitations
  • Hardware limitations - no interrupts available
  • Writing low level device drivers and hardware interrupts are not available

Event Driven Programming

  • The alternative is to use a blocking routines that waits for one of several events you have signified
  • The way in which this is done and the API to do this is operating system specific
  • We will consider the case of Unix which is a very common OS for telecommunications applications.

What is an Event ?

  • An event is anything that needs the attention of the system.
  • Real Time (or Embedded) Systems exist to service events
  • When an event occurs in the real world, an embedded system must recognize the event and take some action in a timely fashion.
  • Embedded systems are often called “event-driven” systems.

Is a signal the same thing as an event?

  • The words event, interrupt, signal, and exception all refer to the same thing: something important happened and we have to take care of it.
  • UNIX software signal is the same thing as a Motorola 68040 hardware interrupt: something happened “out there” and our system needs to respond to that time-critical event.

How do Interrupts Get Generated and Serviced?

  • Microprocessors have a special input pin or pins which are used by external hardware to signal the microprocessor that some external event needs attention. These are the interrupt pins.
  • For example: when a message arrives on a network device such as an Ethernet chip, it applies a signal to an interrupt pin on the microprocessor to interrupt whatever software is currently running.
  • The microprocessor then saves whatever program thread was running and vectors to the interrupt handler which is associated with the interrupt.
  • The Ethernet interrupt service routine (ISR) runs to completion, doing whatever work needs to be done to take care of the arrival of the packet from the network.
  • When the ISR is finished, the control returns to the program thread.

Typical Interrupts

  • External (pin) Interrupts
  • Timer Interrupts
  • SW Interrupts
  • Power Down (Dying Gasp) Interrupt
  • Processor Exception Interrupt


  • In communicating system events happen at same time
  • Priorities are needed to decide which event is handled when
    • The priority of event determines whether it should have precedence over other task
    • High priority tasks usually
      • require little processing time to run
      • cannot tolerate long delays
    • Low priority events usually
      • take longer time to execute
      • there is no impacts if they are delayed
    • Tasks may have same priority and they are then usually served in round robin fashion
Last modified: 2013/07/01 14:42