Difference between revisions of "Complex Arbritration Example"
| Line 15: | Line 15: | ||
<br/> | <br/> | ||
| − | Communications can be in one of three modes, NONE, SERIAL, or RADIO. This will determine which | + | Communications can be in one of three modes, NONE, SERIAL, or RADIO. This will determine which DefaultOwner will own the resource. 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 | 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 | another module requests it. This ownership allows the serial port to receive packets. The SERIAL driver manages incoming bytes on a packet level and | ||
| Line 21: | Line 21: | ||
=== Impact of GPS === | === Impact of GPS === | ||
| − | GPS | + | The addition of GPS allows multiple serial stacks to be active at the same time. 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), | 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. | 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 | + | 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. |
| − | === | + | === Other Considerations === |
| − | * Forcing the GPS to release/request at message boundaries costs significant overhead from the unconfigure/configure at each release/request/grant. It is | + | * Forcing the GPS to release/request at message boundaries costs significant 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 | + | * Basing module release purely on time seems rigid. Policy based on requests seems to be more flexible. However it does increase complexity of both implementation as well as symantics. |
| + | * During normal operation, the GPS module and SERIAL (direct connect) | ||
Revision as of 18:14, 27 November 2008
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. This uses SPI1/USART1.
- SD Mass Storage uses the SPI and uses SPI1/USART1.
Communications can be in one of three modes, NONE, SERIAL, or RADIO. This will determine which DefaultOwner will own the resource. 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 allows multiple serial stacks to be active at the same time. 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.
Other Considerations
- Forcing the GPS to release/request at message boundaries costs significant 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. However it does increase complexity of both implementation as well as symantics.
- During normal operation, the GPS module and SERIAL (direct connect)
