It may be that, rather than handlers that don't work right, there could be big-hog atomic sections in other parts of the code that cause interrupts to go missing. As I said before, TOS is not optimized for speed...
MS Eric Decker wrote: > 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] > <mailto:[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] > <mailto:[EMAIL PROTECTED]>] > > Sent: Friday, July 25, 2008 10:31 AM > > To: Anton > > Cc: Kirak, Hong; [email protected] > <mailto:[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] > <mailto:[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] > <mailto:[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
