cire831
commented
7 years ago It isn't a language issue.
it is a header issue.
TI defines C as..
define C (0x0001)
not a good idea but what they did.
its like one goes out and defines say uint8_t as something else.
another one is FAIL.
the tinyos code handles this problem by doing...
// redefine ugly defines from msp-gcc
ifndef DONT_REDEFINE_SR_FLAGS
undef C
undef Z
undef N
undef V
undef GIE
undef CPUOFF
undef OSCOFF
undef SCG0
undef SCG1
undef LPM0_bits
undef LPM1_bits
undef LPM2_bits
undef LPM3_bits
undef LPM4_bits
define SR_C 0x0001
define SR_Z 0x0002
define SR_N 0x0004
define SR_V 0x0100
define SR_GIE 0x0008
define SR_CPUOFF 0x0010
define SR_OSCOFF 0x0020
define SR_SCG0 0x0040
define SR_SCG1 0x0080
define LPM0_bits SR_CPUOFF
define LPM1_bits SR_SCG0+SR_CPUOFF
define LPM2_bits SR_SCG1+SR_CPUOFF
define LPM3_bits SR_SCG1+SR_SCG0+SR_CPUOFF
define LPM4_bits SR_SCG1+SR_SCG0+SR_OSCOFF+SR_CPUOFF
endif//DONT_REDEFINE_SR_FLAGS
It isn't a language problem.
Dear all,
I am trying to develop a system with nesC only (not using TinyOS). My target platform is msp430. Since I need a "main", I created a component which has
int main () @spontaneous() @C() { ... }
However, the nesC compiler does not compile things when is included. After spending a couple of days, I realized that the NesC compiler gives an error for '@C()' and I solved the issue by creating another header file as
ifndef _MSP430_H
define _MSP430_H
include
// otherwise the nesC compiler gives error for @C() definition
undef C
endif
So, I guess that @C() and the C flag in the real msp430,h conflicts and makes nesC compiler confused. Maybe this is an issue that needs to be resolved in the following versions of nesC language. What do you think?
Cheers,
Sinan