Tuesday, March 27, 2007

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

Friday, March 9, 2007

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

Sunday, March 4, 2007

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