Eric,
Did you ever stop and restart the UART through the SplitControl of SerialActiveMessageC? That is where I found the problem to be. Once I added the following it worked: Added txInit(); rxInit(); and ackInit(); inside of SplitContorl.start() from SerialP.nc. Seems it never re-initialized txState causing the sendDone() event never to be signaled. I'm not sure if this is a bug or if I'm calling the routines incorrectly. If anyone has any thoughts of the above please let me know. -Shaun From: Eric Decker [mailto:[email protected]] Sent: Monday, December 22, 2008 6:12 PM To: Shaun Lawrence Cc: [email protected] Subject: Re: [Tinyos-help] SPI Resource Help Hi Shaun, I too have a custom mote that is very similar to the telosb. I have the following devices on USART1: SERIAL (direct connect), GPS (there is a serial mux that I also have to wiggle to get the right things to happen), SD (mass storage) via SPI1 and eventually we will also put the radio out there as well. I'm making heavy use of Resource contention via Arbiters. I am based on the current tip of the T2.1 cvs tree. If you make it possible for me to see your source tree I maybe able to figure out what is going on. On Mon, Dec 22, 2008 at 1:35 PM, Shaun Lawrence <[email protected]> wrote: Has anyone tried to share the UART1/SPI1 ? I cant use the UART0/SPI0 bus because that is being used solely for the radio, don't want to mess with that. >From my understanding I can stop the UART with (SplitControl.stop()) and then do the SPI commands (Request->Granted->SPI Send->SPI SendDone->Release) then start up the UART again to send the data to the PC over the serial connection. I am using a custom mote very similar to the TelosB. What I have in my tree is a wrapper around the serial driver that also does a request/grant kind of thing. Then I let the arbiter handle resource contention. The arbiter also handles configuration and unconfiguration. Keep in mind the original serial code is very old and predates arbitration and the Resource interface stuff. That's why we added a wrapper. Anyone know if you can do this the way I'm thinking? My code works so the existence proof exists :-) eric Thanks, Shaun From: [email protected] [mailto:[email protected]] On Behalf Of Shaun Lawrence Sent: Monday, December 22, 2008 10:37 AM To: [email protected] Subject: Re: [Tinyos-help] SPI Resource Help Seems I had an old snapshot too. I just updated to the 2.1 snapshot. Still trying to battle getting the UART1 and SPI1 bus on the MSP430 to cooperate. -Shaun From: Michiel Konstapel [mailto:[email protected]] Sent: Monday, December 22, 2008 9:41 AM To: Eric Decker Cc: Shaun Lawrence; [email protected] Subject: RE: [Tinyos-help] SPI Resource Help Ah, I'm looking at the 2.0 release snapshot, I think. Michiel From: Eric Decker [mailto:[email protected]] Sent: maandag 22 december 2008 16:10 To: Michiel Konstapel Cc: Shaun Lawrence; [email protected] Subject: Re: [Tinyos-help] SPI Resource Help I'm not sure what version of the code you are looking at but the following is from the current T2 tree and it is different. And will return SUCCESS if the resource has been appropriately released. Eric async command error_t Resource.release[uint8_t id]() { atomic { if(state == RES_BUSY && resId == id) { if(call Queue.isEmpty() == FALSE) { reqResId = call Queue.dequeue(); resId = NO_RES; state = RES_GRANTING; post grantedTask(); call ResourceConfigure.unconfigure[id](); } else { resId = default_owner_id; state = RES_CONTROLLED; call ResourceConfigure.unconfigure[id](); signal ResourceDefaultOwner.granted(); } return SUCCESS; } } return FAIL; } On Mon, Dec 22, 2008 at 1:26 AM, Michiel Konstapel <[email protected]> wrote: If you dig deep enough, you eventually get down to tos/system/ArbiterP.nc which implements the Resource interface: async command error_t Resource.release[uint8_t id]() { atomic { if(state == RES_BUSY && resId == id) { if(call Queue.isEmpty() == FALSE) { reqResId = call Queue.dequeue(); state = RES_GRANTING; post grantedTask(); } else { resId = default_owner_id; state = RES_CONTROLLED; signal ResourceDefaultOwner.granted(); } call ResourceConfigure.unconfigure[id](); } } return FAIL; } So basically. it always return FAIL, which I think is a bug. Michiel From: [email protected] [mailto:[email protected]] On Behalf Of Shaun Lawrence Sent: vrijdag 19 december 2008 21:02 To: [email protected] Subject: Re: [Tinyos-help] SPI Resource Help Ok I figured out that the release is happening but for some reason it's returning FAIL instead of SUCCESS. Since I am not the owner initially the request is handled and granted and after the release led1 is toggled showing that I am no longer the owner. If I comment out "call SpiResource.release();" then led2 is toggled. So everything is expected but for some odd reason the .release() is not returning what I thought. Anyone know what might cause this? I am running the telosB.. this request is happening on Msp430Spi1. Here is the code I am using: task void release() { call SpiResource.release(); if (!call SpiResource.isOwner()) call Leds.led1Toggle(); else call Leds.led2Toggle(); } event void SpiResource.granted() { post release(); } async command error_t Spi.convert() { if (!call SpiResource.isOwner()) call SpiResource.request(); return SUCCESS; } From: [email protected] [mailto:[email protected]] On Behalf Of Shaun Lawrence Sent: Friday, December 19, 2008 8:10 AM To: [email protected] Subject: [Tinyos-help] SPI Resource Help I'm having a little trouble with the SPI Resources, I need to setup arbitration but that will come later. Just need to make sure I can get the following to work first. First I want to say that only one device is on the SPI bus, the one I'm trying to control. So the problem isn't that something else already has control. I call SpiResource.request() and in turn the SpiResource.granted() is called like its suppose to, I have already verified this. However, when I try to call SpiResource.release() it's coming back as FAIL but I have verified that the SpiResource.isOwner() is coming back as TRUE. Does anyone know why the release() is failing? Thanks in Advance. -Shaun _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Eric B. Decker Senior (over 50 :-) Researcher Autonomous Systems Lab Jack Baskin School of Engineering UCSC _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Eric B. Decker Senior (over 50 :-) Researcher Autonomous Systems Lab Jack Baskin School of Engineering UCSC
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
