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
