Stack Implementation

Layer Hierarchy

Each layer has message headers associated with frames - these structures form the backbone of the data structures.

As per the IrDA specifications, for each layer, there is at least one associated finite state machine (FSM) for each layer.

For the Microlite-IrDA stack, for simplicity, the approach taken is to use one FSM for all layers with implied sub-states. This is contained in the 'driver/wrapper' layer, which does all the layer interaction and exposes a minimal API to the application layer.

As for any layered architecture, it is important that there is minimal coupling between each layer to reduce the effects of change.

For the Microlite-IrDA stack, apart from the driver/wrapper, each layer only uses the services of the layer immediately below.

Primary Stack States

There are ten definite, identifiable states for a primary IrDA lite stack:

Disconnected 0, NDM, initial power-up and idle/standby mode
IrLAP discovering 1, NDM, XID sent, expecting XID
IrLAP negotiating 2, NDM, final XID and SNRM sent, expecting UA
IrLAP confirming 3, NDM, first RR sent after link configuration, expecting RR
IrLMP connecting 4, NRM, connect to IAS sent, expecting connected
IrLMP querying 5, NRM, IAS get-value-by-class sent, expecting IAS data
IrLMP disconnecting 6, NRM, disconnect to IAS sent, expecting RR
IrTTP connecting 7, NRM, connect to IrCOMM sent, expecting connected
IrCOMM connecting 8, NRM, IrCOMM control info sent, expecting control
IrCOMM connected 9, NRM, IrCOMM serial link established

A typical sequence for the establishment of a link is 0, 1, 2, 3, 4, 5, 6, 7, 8, 9.

States 0...3 are essentially sub-states of NDM and states 4...9 are essentially sub-states of NRM.

Secondary Stack States

There are six definite, identifiable states for a secondary IrDA lite stack:

Disconnected 0, NDM, initial power-up and idle/standby mode
IrLAP discovering 1, NDM, XID received, XID sent, expecting final XID
IrLAP connected 2, NRM, first RR frame exchange after link configuration
IrLMP connected 3, NRM, connect to IAS received
IrTTP connected 4, NRM, connect to IrCOMM received
IrCOMM connected 5, NRM, IrCOMM serial link established

A typical sequence for the establishment of a link is 0, 1, 2, 3, [2, 3, 2, 3,] 2, 4, 5.

States 0...1 are essentially sub-states of NDM and states 2...5 are essentially sub-states of NRM.

Blocking on Receive

For an embedded system, there should not be any blocking on receiving characters.

For the Microlite-IrDA stack, there is no wait for receiving frame with the use of interrupts & FIFO queues.

Frame RAM Allocation

There must be a mechanism for the allocation of the relatively large IrDA frames which are a minimum of 64 bytes.

Using the call stack for large data structures means that stack usage is both large and un-predictable - both not ideal for an embedded system. Also, use of stack-based frames may cause stack overflows, ie a crash.

Dynamically allocated frames, eg via C malloc/free etc, tend to fragment the available free space and may result in memory leaks.

Because of these issues, the Microlite-IrDA stack uses pre-allocated, static IrLAP frames.

Keep-Alive of Secondary

For a primary stack, a major decision is whether to keep the secondary alive or to establish a new connection each time a command(s) is required to be issued.

This issue is influenced by:

Power consumption
Whether or not there is any un-solicited data transfer from the secondary to the primary
Frequency of commands from primary to secondary
Maximum response time to issued commands

There is considerable overhead and delay in establishing an IrCOMM connection, usually ~10 frame turnarounds - if the secondary is not keep-alive, this dictates the minimum response time for a command.

This is further complicated and the latency is increased by a possible change in baud rate etc from the initial discovery to the accepted SNRM negotiation parameters.

No Keep-Alive

A new connection is initiated each time by the requesting of an IrCOMM command. Once connected, the link only stays connected until the initial command has been processed, then connection is disconnected or allowed to timeout.

If the secondary is not kept alive, the secondary cannot send an un-solicited response back to the primary unless, in the rare case, a connection happens to be established when a response needs to be sent.

Using mobile phones and AT commands, the ring indicator, ie RING +CLIP, is un-solicited. Thus, if the secondary is not kept-alive, this indication could not be used.

Keep-Alive

A connection is initiated at the start of the application. Once connected, the secondary is continually kept alive by RR frame exchanges.

For simplicity, the Microlite-IrDA primary stack keeps the secondary alive using RR frames and maintains the baud rate at 9600 bps on parameter negotiation.

Flushing of Responses

Depending on the secondary stack, partial responses may received, particularly when the response is split over several I frames.

The complete response may have to be flushed from the secondary with an appropriate I frame. Generally, as RR frames are not sufficient, as these are not seen by the higher level layers.

Typically, for mobile phones and AT commands, the full response may have to be flushed from the secondary with a '\r'.

Errors and Recovery

Errors may occur at any time due to temporary conditions, eg blocking of the infrared path etc or semi-permanent conditions, eg power supply un-plugged etc.

For simplicity, the Microlite-IrDA primary stack uses coarse reattempts where on a frame timeout, the same frame is retried three times. If after retrying, the expected response is not seen, the link state reverts back to discovery irrespective of where the failure occurs.