The asterisk indicates it's a pointer - you may need to brush up on your C skills. txBytes wants a pointer to (essentially, "the location in memory of") the bytes you want sent, and the number of bytes at that location. If you want to send initialDispHexValue, you'd pass the address of the variable: call txBytes(&initialDispHexValue, numBytes).
The & operator means "take the address of this expression, instead of the value". However, how does txBytes work? Does it send the bytes right away and return when it's done, or does it schedule them for later sending and give you an event when it's done? In TinyOS, the second way of working is more common. Because in that case, you'll need to put the bytes you want it to send somewhere where they still exist when your function returns, for example in a global or module variable. As it is now, initialDispHexValue is located on the stack and it will basically stop to be exist when you leave your function. Michiel > -----Original Message----- > From: Mark Tsang [mailto:[EMAIL PROTECTED] > Sent: donderdag 20 maart 2008 20:37 > To: Michiel Konstapel > Cc: tinyos-help@millennium.berkeley.edu > Subject: RE: [Tinyos-help] Utilizing a command from another module, > > Thanks Michael, I'm able to compile and build now but I'm pretty sure > the > command isn't sending successfully because I had toggle the yellow led > if > it's unsuccessful and it seems to be toggling. Do you know what the > asterisk before the variables is for? Do you know what the problem is? > Are > these warnings an indication my unsuccess in sending the byte? > > > NoCRCPacket's command: > command result_t txBytes(uint8_t *bytes, uint8_t numBytes) > > My command call: > uint8_t initialDispHexValue = 0xFE; > uint8_t numBytes = 1; > > // send message to UART (serial) port > 122 if (call txBytes((uint8_t*)initialDispHexValue, > (uint8_t)numBytes) > != SUCCESS) > { > sending_packet = FALSE; > call Leds.yellowToggle(); > } > > 132 if (call txBytes((uint8_t *)baudRateDispHexValue, > (uint8_t)numBytes) > != SUCCESS) > > The warnings > C:\Crossbow\cygwin\opt\MoteWorks\apps\tutorials\myapp\MyAppM.nc: In > function > `MyAppM$Timer$fired': > C:\Crossbow\cygwin\opt\MoteWorks\apps\tutorials\myapp\MyAppM.nc:122: > warning: cast to pointer from integer of different size > C:\Crossbow\cygwin\opt\MoteWorks\apps\tutorials\myapp\MyAppM.nc:132: > warning: cast to pointer from integer of different size > > -----Original Message----- > From: Michiel Konstapel [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 20, 2008 2:16 AM > To: Mark Tsang > Cc: tinyos-help@millennium.berkeley.edu > Subject: RE: [Tinyos-help] Utilizing a command from another module, > > It's possible to provide/use commands directly, without them being part > of an interface, though I think it's a bit of a hack. You have just got > to get the wiring right. > > > configuration MyApp { > > provides { > > command result_t txBytes(uint8_t *bytes, uint8_t numBytes); > > } > > } > > Are you sure your app needs to provide the command? Usually, the top > level configuration neither provides nor uses anything. > > To wire txBytes to your module: > > > implementation { > > components Main, MyAppM, TimerC, LedsC, NoCRCPacket as NoPacket, > UART; > > MyAppM.txBytes -> NoPacket.txBytes; > > Should do the trick. Then inside the module: > > > module MyAppM { > > provides { > > interface StdControl; > > > > } > > uses { > > interface Timer; > > interface Leds; > > interface StdControl as PhotoControl; > > interface SendUART; > > > > command result_t NoCRCPacket.txBytes(uint8_t *bytes, uint8_t > numBytes); > > You shouldn't mention the NoCRCPacket here, just the command: > > command result_t txBytes(uint8_t *bytes, uint8_t numBytes); > > Then, call it as > call txBytes(...); > > > HTH, > Michiel _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
