I've been messing with hooking a gps talking at 115200 (about 87us per byte)running at interrupt level. When I did a timer set Timer.startOneShot(xxx) this was taking long enough such that I would sometimes lose bytes (impling that the interrupt routine which then signalled the routine that reset the timer took longer than 87 us). Yea I know there are async issues (I've since restructured to avoid the potential race conditions the compiler was flagging).
On Sat, Jul 26, 2008 at 9:43 AM, Michael Schippling <[EMAIL PROTECTED]>wrote: > Lets keep this on the help list in case anyone actually knows something... > > You might try putting LED toggles in the various code sections so you > can measure the time taken. I would recommend putting in instrumentation (grabbing LocalTime.get() etc to see how long things actually are taking. Do keep in mind that milliSec time in TinyOS is binary milliseconds (mis vs. ms). 1mis = 1/1024 seconds or about 0.95 ms. I instrument my code and then look at the results after stopping the processor. But I'm using a Jtag interface. > I didn't have the patience to make sense > of the MSP manual vis instructions and MCLKs so if you say 500 > instructions that really seems like it oughta be plenty. But of > course, TOS has been optimized for indirection so there's probably > more overhead than I expect.... > > MS > > > Kirak, Hong wrote: > > Hi, > > > > Actually, I'm talking about UART0 and I checked error flag of USART > module > > which indicates > > some overrun errors. And I think interrupt handling codes of SFD pin and > > FIFOP pin of CC2420 are The other problem I've noticed is that the stock interrupt handler for the UART first grabs the RXBYTE which automatically clears any errors that might be in RCTL. > > > too long to handled within 69 micro seconds(552 cycle). I didn't measure > the > > cycles needed for interrupt handling, > > but I can see huge atomic sections and lots of codes inside of interrupt > > handler. > > (cc2420/receive/CC2420ReceiveP.nc , cc2420/transmit/CC2420TransmitP.nc) > > > > Because such interrupts are occurred even if CC2420 doesn't grab the SPI > > resource, I think > > it can't be done by resource arbitration. What can't be done by resource arbitration? I would think that the interrupt handling goes along with the resource arbitration. That is if something is using the uart, it arbritrates and when granted then interrupts for the uart would be okay. If the uart isn't owned (because the 2420 stack owns it) then uart interrupts shouldn't be occuring. If they do and the interrupt handler is hit then its a bug. And should be checked for. The current handlers are a bit iffy about this. eric > > > > > Any advices will be highly appreciated. Thanks. > > > > Kirak > > > > -----Original Message----- > > From: Michael Schippling [mailto:[EMAIL PROTECTED] > > Sent: Friday, July 25, 2008 10:31 AM > > To: Anton > > Cc: Kirak, Hong; [email protected] > > Subject: Re: [Tinyos-help] UART with RADIO stack > > > > Which UART? I think the USB side uses UART1 and that UART0 is > > shared by the Radio and the expansion port. Thus U0 needs > > some kind of arbitration if you want to use it yourself, > > and that could lead to interference. > > > > Perhaps some interrupt handling problem crept into T2 such > > that the two UARTs can't be used "simultaneously", but 70us > > is a couple hundred instruction cycles which should be enough > > to handle the traffic. > > > > I haven't done extensive testing with telosb and T1 but my > > impression is that a basestation type Radio<->USB pass-through > > can maintain a fair data rate. Would be interesting to compare > > T1 and T2 in that respect I suppose... > > > > MS > > > > > > > > Anton wrote: > >> Hi, > >> > >> I use uart and radio on TelosB and I have the same problem. A mote > >> should receive a radio packet, extract some data and forward it to > >> computer. When packets are sent by only one transmitter and arrive > >> infrequently (say one packet per second) everything is all right, the > >> mote receives packets, transfers them to computer and computer receives > >> correct data. When additional transmitters send their packets (not > >> intended for the uart-using mote, i.e. address recognition should fail > >> in such a case) computer receives some garbage instead of correct data. > >> Now I use TinyOS 2.x. As far as I remember there was no such problem in > >> TinyOS 1.x applications. > >> Probably, this is not very good solution, what I have applied: the > >> mote collects packets and stores data in the memory, then (when there is > >> no longer any radio communication) it can calmly send the data via uart > >> after I press the user button. May be the right thing to do is to reduce > >> uart baud rate. > >> > >> Anton. > >> > >> _______________________________________________ > >> Tinyos-help mailing list > >> [email protected] > >> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > -- > Platform: WinXP/Cygwin > TinyOS version: 1.x, Boomerang > Programmer: MIB510 > Device(s): Mica2, MicaZ, Tmote > Sensor board: homebrew > > _______________________________________________ > 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
