Note
This memo documents a part of TinyOS for the TinyOS Community, and @@ -318,8 +313,8 @@ requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This memo is in full compliance with TEP 1.
This memo describes the structure and standard implementation of the TinyOS 2.x serial communication system for mote-to-PC data exchange. The system is broken into three levels (encoding, framing, @@ -329,8 +324,8 @@ are not bound to the mote's radio packet format. Additionally, one of the supported packet formats is platform independent, so PC-side applications can communicate with arbitrary motes.
Users need to read data out of a TinyOS network. The most common approach is to attach a mote to a PC or laptop with a wired connection. While the interface on the PC side can vary from a serial @@ -345,8 +340,8 @@ parallel with platform-independent communication, which simplifies the PC toolchain. This memo documents the protocols and structure of the TinyOS 2.x serial communication stack.
The TinyOS 2.x serial communication stack is broken up into four functional components. From bottom to top, they are
@@ -357,20 +352,20 @@ functional components. From bottom to top, they are
Structurally, they look like this:
- _____________________ -| | + _____________________ +| | | Dispatcher | Packet formatting. -|_____________________| - _____________________ -| | +|_____________________| + _____________________ +| | | Protocol | Acknowledgements, CRC computation, |_____________________| windowing. - _____________________ -| | + _____________________ +| | | Encoder/Framer | Translating raw bytes into frame |_____________________| delimiters, escape bytes. - _____________________ -| | + _____________________ +| | | Raw UART | Platform code for reading/writing |_____________________| bytes over the serial connection.@@ -401,15 +396,15 @@ particular packet format begins (based on its header size). Section 3.4 describes how the default TinyOS 2.x implementation, SerialDispatcherC does this.
Section 2 describes the basic structure of the TinyOS 2.x serial stack. This section describes its actual implementation, including SerialActiveMessageC, which sits on top of the Dispatcher. All of the components except for UartC are part of the serial library that lives in tos/lib/serial.
-The UART HIL[TEP2] is UartC, which provides a byte-level interface to the underlying serial communication. It provides the SerialByteComm interface:
@@ -439,8 +434,8 @@ interface SerialFlush {It may provide additional interfaces for configuring the serial port. This TEP does not consider this topic.
HdlcTranslateC is the serial encoder/framer. It uses the SerialByteComm interface and provides the SerialFrameComm interface:
@@ -475,8 +470,8 @@ the transmitEscape flag to true, stores the data byte XOR -The SerialP component implements the serial protocol using PPP/HDLC- like framing (See RFC 1662[RFC1662]). Type dispatch and buffer management are left to higher layers in the serial stack. The protocol @@ -535,8 +530,8 @@ stored in a queue separate from the data buffer, so a data packet to be transmitted may begin spooling into SerialP while SerialP is actively sending an acknowledgement.
SerialDispatcherC handles the data packets that the Protocol component receives. It uses the SendBytePacket and ReceiveBytePacket interfaces, and provides parameterized Send and Receive interfaces. The parameter @@ -574,8 +569,8 @@ active messages (TOS_SERIAL_802_1 TOS_SERIAL_UNKNOWN_ID are reserved. New packet formats MUST NOT reuse any reserved identifiers.
SerialActiveMessageC is a platform-independent active message layer that operates on top of the serial communication stack. SerialActiveMessageC is a configuration that wires @@ -597,18 +592,18 @@ configuration SerialActiveMessageC { implementation { components new SerialActiveMessageP() as AM, SerialDispatcherC; components SerialPacketInfoActiveMessageP as Info; - + Init = SerialDispatcherC; Leds = SerialDispatcherC; - + AMSend = AM; Receive = AM; Packet = AM; AMPacket = AM; - + AM.SubSend -> SerialDispatcherC.Send[TOS_SERIAL_ACTIVE_MESSAGE_ID]; AM.SubReceive -> SerialDispatcherC.Receive[TOS_SERIAL_ACTIVE_MESSAGE_ID]; - + SerialDispatcherC.SerialPacketInfo[TOS_SERIAL_ACTIVE_MESSAGE_ID] -> Info; } @@ -629,17 +624,17 @@ typedef nx_struct SerialAMHeader { } SerialAMHeader;
A data packet in the TinyOS 2.x serial stack has the following format over the wire. Each protocol field is associated with a specific component:
____________________________________________
| | | | | | | |
- | | | | | | | |
+ | | | | | | | |
|_|_|_|_|_______________________________|__|_|
F P S D Payload CR F
-
+
F = Framing byte, denoting start of packet: HdlcTranslateC
P = Protocol byte: SerialP
S = Sequence number byte: SerialP
@@ -658,8 +653,8 @@ destination 0xbeef with a payload of 1 2 3 4 5 would look like this:
(P) is 0x40 (64), corresponding to SERIAL_PROTO_ACK (in Serial.h).
Two generic components: SerialAMSenderC and SerialAMReceiverC connect to SerialActiveMessageC to provide virtualized access to the serial stack. Each instantiation of SerialAMSenderC has its own queue of @@ -673,8 +668,8 @@ Section 4 of TEP 116[TEP116] for more in services in the TEP 116, the serial component virtualizations provide no snooping capabilities.