[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] Global Variables in NesC

It seems that there are not such support in NesC.

I've tried to apply the "extern" storage in C here but it does not work. The compiler complains about undefined reference to that variable during linking stage.

The only way I can think of is to store the data in components, and to provide get/set interfaces of those components.

[NesC] NesC syntax highlighting in UltraEdit

Attach the following section at the end of "wordfile.txt" file in your UltraEdit installation directory. Just some trivial modification from the original C/C++ syntax highlighting wordfile.

Say your UE currently supports n languages highlighting.

/L($n+1)"NesC" NesC_LANG Line Comment = // Block Comment On = /* Block Comment Off = */ Escape Char = \ String Chars = "' File Extensions = NC H
/Delimiters = ~!@%^&*()-+=|\/{}[]:;"'<> , .?
/Function String = "%^([a-zA-Z_0-9^[^]*]+^)[ ^t]+([^p*&, ^t^[^]a-zA-Z_0-9.!]++)[~;]"
/Function String 1 = "%[a-zA-Z_0-9*]*::^([a-zA-Z_0-9^~]+^)[ ^t^p]++([^p*&, ^t^[^]/*=:&amp;amp;amp;a-zA-Z_0-9./(!]++)[~;]"
/Function String 2 = "%[a-zA-Z_0-9^][a-zA-Z_0-9^[^]]+[ ^t*]+^([a-zA-Z_0-9]+^)[ ^t]++([^p*&, ^t^[^]a-zA-Z_0-9./(!]++)[~;]"
/Function String 3 = "%[a-zA-Z_0-9*&$^[^]*]+[ ^t]+[a-zA-Z_0-9*&amp;amp;amp;$^[^]]+[ ^t*]+^([a-zA-Z_0-9]+^)[ ^t]++([^p*&, ^t^[^]a-zA-Z_0-9./(!]++)[~;]"
/Function String 4 = "%[a-z_0-9^[^]*]++ [a-z_0-9*^[^]]+[ ^t]++[a-z_0-9*^[^]]+[ ^t]++^([*a-z_0-9]+^)[ ^t]++([^p*&, ^t^[^]a-z_0-9./(!]++)[~;]"
/Function String 5 = "%^([a-zA-Z_0-9^[^]*]+^)[ ^t]++([^p*&, ^t^[^]a-zA-Z_0-9./()!]++)[~;]"
/Indent Strings = "{" ":"
/Unindent Strings = "}"
/Open Brace Strings = "{" "(" "["
/Close Brace Strings = "}" ")" "]"
/Open Fold Strings = "{"
/Close Fold Strings = "}"
/C1"Keywords"
auto
break bool
case char const continue
default do double defined
else enum extern
float for
goto
if int
long
register return
short signed sizeof static struct switch
typedef
union unsigned
void volatile
while
__asm __based __cdecl __declspec __except __far __fastcall __finally __fortran __huge __inline __int16 __int32 __int64 __int8 __interrupt __leave __loadds __near __pascal __saveregs __segment __segname __self __stdcall __try __uuidof
#define #error #include #elif #if #line #else #ifdef #pragma #endif #ifndef #undef
/C2"NesC Keywords"
as async atomic
call command components configuration
default
event
implementation includes interface
module
post provides
signal
task
uses
/C3"Operators"
+
-
=
// /
*
~
%
&
>
<
^
!
|

The "dictionary" in it is sufficient for me but you can extend it as long as necessary.

Be aware: replace "($n+1)" with the actual index number.

[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!