Here is how I would approach the problem.... I've been doing industry development for 30+ years. Equally split between old (mini-computer days) cpu bring up, design, system software and embedded systems.... (early router development at cisco, essentially embedded systems).
First, I would instrument in some way. I currently use the TI JTAG FET pod connected to gdb and I use that for all my main debugging. That gives me internal visibility of the machine state. mspdebug continues to get better. They've recently added watch points but I haven't used them yet. For your problem, I would add a simple trace mechanism that writes to a circular buffer in memory. This of course assumes that you have access to machine state through the above. This trace mechanism then logs arriving at certain points in the code and at what time. I use the uSec ticker (which assumes the machine doesn't go to sleep). There is no substitue in my opinion in being able to see what is actually going on. for example, a bunch of i2c drivers have been written but to my knowledge (expect perhaps for what Steve Ayers has done) no one has actually observed what the i2c bus has actually behaved like. So I've rewritten the i2c driver and have hooked up to the i2c bus a logic analyzer so I can actually see what the bus is doing. That is how I would approach the problem.... On Sun, Sep 30, 2012 at 11:47 AM, wasif masood <rwmas...@gmail.com> wrote: > > Dear Eric, > > I am experiencing a very strange behavior which, in my opinion, is not > possible. I am using this AlarmMicro16C component and I am observing > that it almost take around 6000 ticks each time the call goes from my > Application component into the AlarmMicro16C component, when measured using > Alarm.getNow() command, now some delay is most likely since I am using > printf commands, but a delay of around 6000 ticks just passed between the > calls when followed from the application component, where the AlarmMicro16C > component is delcared to the AlarmMicro16C itself. > > I really need some experienced advice here coz I am deep stucked in the > problems now I never anticipated! > > > On Sun, Sep 30, 2012 at 6:00 AM, Eric Decker <cire...@gmail.com> wrote: > >> >> I strongly suspect none of the implementations have been tested for >> corner cases. >> >> >> On Sat, Sep 29, 2012 at 8:43 AM, wasif masood <rwmas...@gmail.com> wrote: >> >>> >>> Dear Janos, >>> >>> There is a strange behaviour I am experiencing with AlarmMicro16C. From >>> the tinyos general documentation, it is pretty clear that start command >>> starts the timer from current time to dt, now since we know >>> that AlarmMicro16C can has a maximum 65535 value so if one intend to give >>> this value i.e. start(65535), logically it should run uptil 65535 ticks, >>> but the catch I saw in the implementation is something different, there it >>> is something like >>> call Msp430Compare.setEvent( now+remaining ); which means that if "now" >>> is even 1, now+remaining time will overshot the uint16_t limit so it will >>> reset the timer to 1. This all means that dt can not be greater than >>> 65535-now, otherwise now+remaining will become greater than 65535 limit and >>> the new alarm value would be the overflow value rather the "remaining" >>> value. >>> >>> So According to my understanding, dt should mean that how long you want >>> the timer/alarm should run, it should not have any dependency over the >>> current time. Is my understanding correct, and if soo, how this current >>> implementation can be changed to compensate for the desire behaviour? >>> >>> >>> Regards, >>> Wasif! >>> >>> >>> On Tue, Sep 25, 2012 at 5:05 PM, Janos Sallai < >>> sal...@isis.vanderbilt.edu> wrote: >>> >>>> Wasif: >>>> >>>> tos/chips/msp430/timer/AlarmMicro16C.nc is what you're looking for. >>>> Please note that the us counter is driven by the DCO, which stops when >>>> the MCU goes to sleep. You will have to prevent the MCU from sleeping >>>> by implementing McuPowerOverride.lowestState(). >>>> >>>> Janos >>>> >>>> On Tue, Sep 25, 2012 at 2:37 AM, wasif masood <rwmas...@gmail.com> >>>> wrote: >>>> > >>>> > Thanks Eric, I have been through a alot of these posts. So far, I >>>> think, the >>>> > solution I am looking for, is not answered in any of them. Either >>>> there >>>> > isTMicro packet timestamping being discussed or the TMicro counters >>>> are >>>> > explained just to track the time elasped between two events. But I am >>>> > interested in an Alarm, of TMicro, cable of signaling interrupts >>>> > periodically, with the granurality of 1 us. So far, the closet I got >>>> is >>>> > Alarm32Khz, where I tick ~ 30us, is there any way to wire the Alarm >>>> to get a >>>> > granurality of 1us per Tick FOR TELOSB only? >>>> > >>>> > >>>> > On Tue, Sep 25, 2012 at 12:53 AM, Eric Decker <cire...@gmail.com> >>>> wrote: >>>> >> >>>> >> >>>> >> You want Tmicro. >>>> >> >>>> >> Search via >>>> >> http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/for >>>> >> tmicro. >>>> >> >>>> >> This topic has been discussed previously. >>>> >> >>>> >> >>>> >> >>>> >> On Mon, Sep 24, 2012 at 5:39 AM, wasif masood <rwmas...@gmail.com> >>>> wrote: >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hi All, >>>> >>> >>>> >>> A quick question, is there a timer with granularity of 1us. more >>>> than >>>> >>> Alarm<T32khz, uint32_t>, where I tick~30us? for Telosb. >>>> >>> >>>> >>> VG, >>>> >>> Wasif Masood >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> Tinyos-help mailing list >>>> >>> Tinyos-help@millennium.berkeley.edu >>>> >>> >>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Eric B. Decker >>>> >> Senior (over 50 :-) Researcher >>>> >> >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > Wasif Masood >>>> > >>>> > >>>> > _______________________________________________ >>>> > Tinyos-help mailing list >>>> > Tinyos-help@millennium.berkeley.edu >>>> > >>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>> >>> >>> >>> >>> -- >>> Wasif Masood >>> >>> >> >> >> -- >> Eric B. Decker >> Senior (over 50 :-) Researcher >> >> >> > > > -- > Wasif Masood > > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
