Sorry for the double-email, but I may have found some interesting information.
I tried using MSPSim, which I know isn't 100% accurate, but it at least has a "Profile" command. It seems I'm spending a LOT of time in McuSleepC__getPowerState. Does that indicate anything? On Thu, May 5, 2011 at 3:34 PM, David Lee <d...@gray101.com> wrote: > So, I've broken a test bit out that just handles the sending of a single > byte. > > I've stuck more printfs in there to check for loops (not enough leds to use > those) > > I'm not seeing any loops in my code's output. For references, here's the > output: > > Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200: >>> resynchronising >> >> RadioTestC Booted! >> >> Attempting to send 50 >> >> RadioResource.request() -> outside loop -> returned SUCCESS >> >> doSend returned 0 >> >> RadioResource.granted() -> before loop -> retVal: 0 >> >> RadioResource.granted() -> after loop -> retVal: 0 >> >> AMControl.startDone started. Parameter: 0. SendVal:50 >> >> Payload of 50 packed into message buffer at 0x38b6 >> >> AMSend.send() -> before loop -> returned 0 >> >> AMSend.send() -> after loop -> returned SUCCESS >> >> AMSend.send() about to return >> >> >> > The code puts the email above the moderation limit, so I've posted it > here<http://pastebin.com/9sqN6Bv1> > > > On Thu, May 5, 2011 at 1:37 PM, Michael Schippling <sc...@santafe.edu>wrote: > >> I don't know of any telos profiling tools. It does have >> pads for a JTAG connector which you could use to trace >> code, but I've never used it. Toggling LEDs is the best >> debugging tool available, since it's easy (if you keep >> the on/off patterns logical somehow) and doesn't interfere >> with timing -- of course I always debug with printf's >> on "real" computers too -- >> >> I think simplifying your program a bit and putting the >> send() in it's own task might be the best start. >> >> The issue with processor-hogging, and the reason >> programs need to be broken up into small execution >> units, is that TOS is not pre-emptive. So if you have >> something that gets stuck in a loop and doesn't return >> to the scheduler, no other tasks get executed. Since >> everything pretty much relies on being able to fire >> off a new task, even the Timer code, the system drags >> to a halt. >> >> MS >> >> David Lee wrote: >> >>> That's an excellent idea I never thought to look for. >>> >>> However, I know it's not that specific infinite loop, since the printf() >>> usually prints the same thing (except for the occasional bad packet?), and >>> that's: >>> >>> Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200: >>> resynchronising >>> Attempting to send 101 >>> RadioResource.request() returned SUCCESS >>> AMControl.startDone started. Parameter: 0. SendVal:101 >>> Payload of 101 packed into message buffer at 0x38b6 >>> AMSend.send() returned 0 >>> AMSend.send() returned SUCCESS >>> >>> Based on my code, that seems to imply it makes a success on it's first >>> try. >>> >>> Is there any profiling tool I can use on the msp430 found in the telosB, >>> rather than trying to tease out the error by hand? >>> >>> >>> Thanks again for your help and rapid response, >>> >>> >>> >>> On Thu, May 5, 2011 at 12:39 PM, Michael Schippling >>> <sc...@santafe.edu<mailto: >>> sc...@santafe.edu>> wrote: >>> >>> One "should" get a sendDone() with a failed ACK, although >>> you probably need to look at the message.ack field rather >>> then the error argument to figure it out. >>> >>> If you are not getting the sendDone() call ever-at-all, >>> I would suspect that you have something hogging the processor >>> -- like that possibly infinite-loop of error checking after >>> your send() call (I'm too lazy to run it in my head) -- or >>> that calling send() from the startDone() is too early in >>> the cycle. If that's the case you could try calling send() >>> from a Timer.fired(), or posting a Task to do it a little >>> later on. >>> >>> MS >>> >>> David Lee wrote: >>> >>> Hey everyone - >>> I'm working on some radio code for the telosB motes. >>> Specifically, my code calls AMSend.send(), and via the printf >>> library, I've proved that it returns SUCCESS. >>> >>> Unfortunately, the event for sendDone never gets called. >>> >>> I've heard that this can be caused due to ack issues, so for >>> now, I've tossed a >>> #define CC2420_NO_ACKNOWLEDGEMENTS >>> >>> right after my include statements. >>> >>> Anyone have any other ideas of what can cause this? >>> >>> ----------- Code Below --------------- >>> #include "SensorMsg.h" >>> #include "printf.h" >>> >>> #define CC2420_NO_ACKNOWLEDGEMENTS >>> >>> module Uint8_tSenderC{ >>> provides { >>> interface ByteSend; >>> } >>> >>> uses{ >>> interface Leds; >>> interface AMSend; >>> interface SplitControl as AMControl; >>> interface Packet; >>> interface AMPacket; >>> interface Resource as RadioResource; >>> } >>> } >>> >>> implementation{ >>> bool busy = FALSE; >>> uint8_t sendVal; >>> >>> event void AMSend.sendDone(message_t *msg, error_t error){ >>> error_t retVal; >>> printf("AMSend.sendDone(%p, %u)", msg, error); >>> printfflush(); >>> call Leds.led1On(); >>> if(error == SUCCESS) >>> { call Leds.led2Toggle(); >>> retVal = call AMControl.stop(); >>> while(!(retVal == SUCCESS || retVal == EALREADY )) >>> { >>> retVal = call AMControl.stop(); >>> } >>> } >>> else >>> { >>> call AMSend.send(AM_BROADCAST_ADDR, msg, sizeof(SensorMessage_t)); >>> } >>> } >>> >>> event void AMControl.startDone(error_t error){ >>> error_t retVal; >>> message_t msgBuf; >>> printf("AMControl.startDone started. Parameter: %u. >>> SendVal:%u\n",error, sendVal); >>> printfflush(); >>> if(error == SUCCESS) >>> { >>> >>> if(!busy) >>> { >>> SensorMessage_t * payload; >>> payload = (SensorMessage_t *) call Packet.getPayload(&msgBuf, >>> sizeof(SensorMessage_t)); >>> payload->nodeId=TOS_NODE_ID; >>> payload->sensorType=0x01; >>> payload->msgType=0x03; >>> payload->msgValue= sendVal; >>> busy = TRUE; >>> printf("Payload of %u packed into message buffer at %p\n", >>> sendVal, &msgBuf); >>> printfflush(); >>> retVal = call AMSend.send(AM_BROADCAST_ADDR, &msgBuf, >>> sizeof(SensorMessage_t)); >>> printf("AMSend.send() returned %u\n", retVal); >>> printfflush(); >>> while(retVal != SUCCESS) >>> { >>> if(retVal == EBUSY) >>> { >>> call Leds.led1On(); >>> } >>> if(retVal == FAIL) >>> { >>> call Leds.led1On(); >>> } >>> printf("AMSend.send() returned %u\n", retVal); >>> printfflush(); >>> retVal = call AMSend.send(AM_BROADCAST_ADDR, &msgBuf, >>> sizeof(SensorMessage_t)); >>> } >>> printf("AMSend.send() returned SUCCESS\n"); >>> printfflush(); >>> call Leds.led2On(); >>> } >>> } >>> else { >>> printf("AMSend.send() restarted!\n"); >>> printfflush(); >>> call AMControl.start(); >>> } >>> } >>> >>> event void RadioResource.granted(){ >>> error_t retVal; >>> retVal = call AMControl.start(); >>> while(!(retVal == SUCCESS || retVal == EALREADY )) >>> { >>> retVal = call AMControl.start(); >>> } >>> >>> } >>> >>> event void AMControl.stopDone(error_t error){ >>> call RadioResource.release(); >>> signal ByteSend.sendDone(); >>> } >>> >>> command error_t ByteSend.doSend(uint8_t toSend){ >>> error_t ret; >>> if(!busy) >>> { >>> printf("Attempting to send %u\n", toSend); >>> printfflush(); >>> sendVal = toSend; >>> ret = call RadioResource.request(); //immediateRequest(); >>> while(ret != SUCCESS) >>> { >>> printf("RadioResource.request() failed with status %u\n", ret); >>> printfflush(); >>> ret = call RadioResource.request(); //immediateRequest(); >>> } >>> printf("RadioResource.request() returned SUCCESS\n"); >>> printfflush(); >>> call Leds.led0On(); >>> } >>> else >>> { >>> ret = FALSE; >>> } >>> return ret; >>> } >>> } >>> ----------- Code Above ---------------- >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Tinyos-help mailing list >>> Tinyos-help@millennium.berkeley.edu >>> <mailto:Tinyos-help@millennium.berkeley.edu> >>> >>> >>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>> >>> >>> >
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
