Complex Arbritration Example

Consider a complex mote based on the telosb mote that includes the following:

• serial communication for direct connection.
• serial communication for gps.
• serial communication disabled.
• radio communication (SPI based)
• mass storage using a Secure Digital card (SPI based)

• Serial communication utilizes UART1/USART1 with an external multiplexer for switching between the three choices.
  
• Radio communication uses a CC2420 ChipCom radio that uses the SPI bus (SPI1/USART1).
  
• SD Mass Storage uses the SPI (SPI1/USART1).

Off mote serial communications can be in one of three modes, NONE, SERIAL, or RADIO. This determines how the mote will communicate with the outside world. This is different from DefaultOwner of the underlying hardware although they are related. NONE being selected allows USART1 and associated h/w to be powered down. SERIAL being selected configures the serial hardware (including connecting clocks and timers which prevent the CPU from going into a lower power mode). SERIAL will own the h/w unless another module requests it. This ownership allows the serial port to receive packets. The SERIAL driver manages incoming bytes on a packet level and will only release the h/w at a packet boundary.

Impact of GPS

The addition of GPS creates the potential for multiple serial stacks to be concurrent. Assume that SERIAL is selected when the GPS is turned on. The GPS driver will request the UART1 h/w and will need to keep it while receiving packets from the GPS. But while the GPS is functioning it is desirable to be able to receive control packets from the SERIAL port. The SERIAL module is a default owner so the GPS module obtains the port for some amount of time, releases (at a message boundary), and then requests again after an interval (allowing the SERIAL port to potentially start receiving a packet), the SERIAL port won't release if a packet has started to be received. The SERIAL driver will release when it gets to a packet boundary.

In addition to interacting with the SERIAL driver, the GPS module should be prepared to release (at a message boundary) if another module (such as the SD driver) requests the hardware. If too much time passes other modules can be starved. Serious problems can develop (current code will panic). This argues for the GPS releasing either on request or via timing (kept small enough).

At one point, we toyed with the idea of the GPS being a transient user of the serial hardware. However, the GPS stack functions in a similar fashion to the SERIAL AM stack. Namely, the CPU must be listening to serial hardware in order to receive packets. This argues for the GPS being another DefaultOwner.

Other Considerations

• Forcing the GPS to release/request at message boundaries is expensive due to overhead from the unconfigure/configure at each release/request/grant. It is advantagous to minimize how often the release/request/grant occurs.

• Basing module release purely on time seems rigid. Policy based on requests seems to be more flexible. The race conditions need to be explored. If the policy is to honor ResourceRequested.requested

events then a mechanism is needed for dealing with requests that are "simultaneous" (a request will be granted but hasn't occurred yet, so the current owner is NO_RES, and any new requested events won't be seen by the grantee. This breaks the policy of wait for a request. This only impacts modules that sit on a resource so should only effect DefaultOwners. The behaviour of the code implementing this needs to be examined.

• During normal operation, the GPS module and SERIAL (direct connect) are mutually exclusive. When the mote is plugged in we know where it is and there is no need for the GPS to tell us. When the radio is active, it can receive while being disconnected from the CPU. A h/w event is generated which signals the RADIO driver. In this sense, the RADIO and GPS do not compete with each other. The RADIO driver when presented with the receive event will request, when granted it obtains the SPI bus and handles the receive packet.
  
  This argues for the normal access mechanism being based on request rather than special casing using timers. The GPS releasing/requesting at every message boundary would be expensive and is counter-indicated. An efficient mechanism for switching between different modules could use the ResourceRequested.requested interface. Another possibility is to make GPS a DefaultOwner. Basically any module that needs to sit on the hardware would be a DefaultOwner.

• Implementing GPS and SERIAL coincident is useful for two reasons. For debugging, the mote can be plugged into a base station while the GPS is running. The second reason is to flesh out the implementation and structure for this level of complex arbitration.

• Two types of modules:

1. Default owners. Require relatively long ownership of underlying hardware to perform function. CPU involved byte by byte receive for example. Multiple default owners must be multiplexed.
2. Transitory users. Arbritrates, obtains the grant, does relatively short term processing, and releases. Transitory users are intended to use the device quickly and then let go.

• SERIAL and NONE are selected explicitly. While GPS is turned on programatically and at least for debugging could turn on when SERIAL is active. This imples a mechanism to control switching between SERIAL and GPS so they can share in some reasonable fashion. Request/Grant/Release via an Arbiter seems the obvious choice.