[NesC] Message Format Sent Over Serial Ports [T2 Only]

* TinyOS 2.x

A message sent through serial ports from motes to PC will typically look like this:

00 FF FF 00 00 08 00 09 19 77 02 07 00 13 00 00

---

• The first byte 00 is the leading zero.
  
  
• After that, the whole packet is of the type "serial_packet_t", defined in tinyos-2.x/tos/lib/serial/Serial.h.
  
  
• Inside the serial_packet_t structure, the first 7 bytes are of the type "serial_header_t", which is also defined in tinyos-2.x/tos/lib/serial/Serial.h.
  
  In the case above, it would be FF FF 00 00 08 00 09.
  
  Within the "serial_header_t", the following structure takes place:
• nx_am_addr_t     dest     // Destination (2 bytes)
  
• nx_am_addr_t     src       // Source (2 bytes)
• nx_uint8_t            length // Payload Length (1 byte)
• nx_am_group_t group  // Group ID (1 byte)
• nx_am_id_t          type     // Active Message Handler Type (1 byte), some enum value that you can define yourself.
  
  
• After the 7 byte header, here comes the payload, which can be up to TOS_DATA_LENGTH (28 bytes) long. The content could be anything.
  
  In the above example, the payload is: 19 77 02 07 00 13 00 00, which is of the length (8 bytes) denoted in the "Payload Length" field.
  

---

To note, besides the payload part, we need to fill out the destination address and payload length field by calling SerialActiveMessageC.AMSend(am_addr_t dest, message_t* msg, uint8_t len). It would be a good programming manner to fill the len with sizeof(). And we also need to specify the Active Message Handler Type by wiring the AMSend to SerialActiveMessage.AMSend[am_id_t id];

ref:
http://www.tinyos.net/tinyos-2.x/doc/html/tutorial/lesson4.html. The doc here doesn't seem to be up-to-date since it left out the source address from the header.

[NesC] Weird problem about typedef in header file

Environment:
Cygwin + Tinyos 1.15
gcc3.3.3

I was trying to compile a program with several structures defined by myself in a header file. And these structures are passed through some interfaces as parameters.

At first I didn't include the header file in the top level wiring configuration but only in the modules using it. However the compiler reported "conflicting types" on the parameters between my event handler definition and the "previous declaration" of that event in the interface definition file. This is weird since these two lines are exactly the same and to be perfectly cautious, I copy the definition to replace my event handler definition. It didn't work neither.

I tried to google it, no luck. Then I started to remove the parameters one by one. Finally after I removed the parameters of the structures defined by myself from the interface definition, it works. It seems although the compiler is able to translate that structure in the interface definition file into the correct type but unable to translate the ones in my application module although I included the header file as well. One solution to this problem is to replace that data structure with build-in types. That solved the problem, but it will become quite annoying.

Since it seems that the compiler have trouble in mapping the use of self-defined structures into correct definitions of those structures, I tried to include that file in the top level wiring configuration. Well, another weird thing happened. The compiler didn't recognize typedef in the header file at all.

It even complained about instructions like:

typedef uint8_t HANDLE;

The error appeared like this:

"parse error before "typedef"".

No better solutions so far. As the deadline of paper approaches, I have to give up trying on this single point and move on. Any suggestions are welcome and appreciated! Thanks!