There is some amount of confusion with regards to binary vs. decimal/metric frequency.
On the telosb, TI msp430f1611, the main timer is run off the 32768 clock generating 1mis (binary millisec, = 1/1024 secs). And unless carefully documented it is unclear what is being referred to when one sees 1MHZ in the code. To further confuse things, TI has brought out new chips like the ti msp430f2618 that includes factory calibration values for dco (main cpu clock) frequencies for running at 1000000, 4000000, 8000000, 16000000 and baud rate tables for various uart speeds etc. It would be nice to be able to make use of these tables when we program the ti peripherals. I've been working on code in the msp430X area that deals with many of these issues. But this mixture of decimal and binary units while using the same nomenclature is very confusing and also leads to programming errors. I'd like to suggest that we adopt the nomenclature of binary units. ie. binary millisecond, mis, decimal millisecond ms, binary megahertz MIHZ or MiHZ, etc. eric On Wed, Mar 17, 2010 at 9:27 AM, Vlado Handziski <[email protected]>wrote: > On Tue, Mar 16, 2010 at 23:50, Attila Strba <[email protected]> wrote: > >> Hi Vlado, >> as far as I read the source and underestood the TEP's right the tag has no >> influence on the transofrmation calculation right? It just makes sure the >> timer conversion types does not get mixed ? >> >> > Yes, but TMicro is a confusing name for something that is 1/16us. > > >> The clock source is the 16MHz XTAL oscillator driving the miccrocontroller >> so I guess metric. After 65535 tackts wraps around and 1 tick takes 1/16us. >> To be honest I don't underestand how could be a microcontroller clock source >> be "binary". >> >> > What I mean is when you say 1MHz this can be 1 * 1000 * 1000 ticks per > second or 1 * 1024 * 1024. When we say that the clock source has 1MHz in > tinyos, it means the later. I.e. all units are binary, i.e. 1 second has > 1024 binary milliseconds. > > >> Any more idea where I could look for problems? >> >> > No, sorry. I guess you will have to debug this with a scope and toggling a > pin in the fire events of the alarms in the transform components. > > Vlado > > >> thanx a lot for the help Vlado, >> >> greetings >> >> Attila >> >> >> >> ------------------------------ >> *From:* Vlado Handziski <[email protected]> >> *To:* Attila Strba <[email protected]> >> *Cc:* [email protected] >> *Sent:* Tue, March 16, 2010 5:23:56 PM >> >> *Subject:* Re: [Tinyos-help] Timer precision problem during proting to >> platform >> >> If you like to export a 16MHz timer, the TMicro precision tag is not >> appropriate. You can use T16mhz (just like we have T32khz) for this >> particular prescaler, or TOne, etc. like in the atm128 when the prescaler is >> not fixed. Is this a binary 16MHz clock source or metric? TinyOS is always >> using binary units. The transforms with the 14 bit-shift look correct to me. >> >> Vlado >> >> >> On Tue, Mar 16, 2010 at 08:26, Attila Strba <[email protected]> wrote: >> >>> Hi Vlado, >>> thanks for the mail it helped a lot. I implemented this the following way >>> like described but the TimerMilli was doing random periodes. For example I >>> tried to get a fire every 1ms and I got it for every 700us. I think my HPL >>> works fine, because if I use the HPL component as separate I can get correct >>> fire events. But when I go through all the transformation it behaves >>> strange. >>> >>> For sure I am doing something wrong. Just to make sure I underestand you >>> right, could you please confirm my steps? >>> >>> *Steps:* >>> >>> - I create a HPL for the timer where 1 tick has 1/16=0,0625us >>> - I provide an alarm, counter interface in HPL following way >>> provides interface Counter< TMicro, uint16_t> as Counter >>> provides interface Alarm< TMicro, uint16_t> as Alarm[ >>> uint8_t id ]; >>> - the counter signalises overflow in 4.096ms = (65536 ticks) >>> - the alarm is implemented using the compare register, and the fire event >>> is the compare match with the counter >>> - I transform the counter to 32bit 1ms counter following way, 2^14 ticks >>> = 16384 * 0.0625 = 1024 which is aprox. 1ms >>> >>> *CounterMilli32C.nc:* >>> components CounterMicro16C as CounterFrom; >>> components new >>> TransformCounterC(TMilli,uint32_t,TMicro,uint16_t,14,uint32_t) as Transform; >>> >>> Counter = Transform.Counter; >>> Transform.CounterFrom -> CounterFrom; >>> >>> - I transform the alarm to 32bit 1ms counter following way, 14: 2^14 >>> ticks = 16384 * 0.0625 = 1024 which is aprox. 1ms >>> *AlarmMilli32C.nc:* >>> components new AlarmMicro16C() as AlarmFrom; >>> components CounterMilli32C as Counter; >>> components new TransformAlarmC(TMilli,uint32_t,TMicro,uint16_t,14) as >>> Transform; >>> >>> Init = AlarmFrom; >>> Alarm = Transform; >>> Transform.AlarmFrom -> AlarmFrom; >>> Transform.Counter -> Counter; >>> >>> - I provide both AlarmMilli32C and CounterMilli32C to HilTimerMilliC.ncso I >>> can use the TimerMilli interface for timing: >>> *HilTimerMilliC.nc:* >>> components new AlarmMilli32C(); >>> components new AlarmToTimerC(TMilli); >>> components new VirtualizeTimerC(TMilli,uniqueCount(UQ_TIMER_MILLI)); >>> >>> Init = AlarmMilli32C; >>> TimerMilli = VirtualizeTimerC; >>> >>> VirtualizeTimerC.TimerFrom -> AlarmToTimerC; >>> AlarmToTimerC.Alarm -> AlarmMilli32C; >>> >>> Thank you very much for the help, >>> greetings >>> Attila >>> >>> ------------------------------ >>> *From:* Vlado Handziski <[email protected]> >>> *To:* Attila Strba <[email protected]> >>> *Cc:* [email protected] >>> *Sent:* Tue, March 16, 2010 3:46:07 AM >>> *Subject:* Re: [Tinyos-help] Timer precision problem during proting to >>> platform >>> >>> On Sun, Mar 14, 2010 at 23:50, Attila Strba <[email protected]> wrote: >>> >>>> Hi Guys, >>>> >>>> >>>> I am trying to port the TinyOS to the Dolphin EO3000I chip from EnOcean >>>> and I have a poblem with the Timer precission. >>>> >>>> As I read from the TEP 102, it is written that the HLP timer interface >>>> should provide either 32kHz or 1ms or 1us tick precision. The Dolphin runs >>>> on 16MHz clock. The Timer0 I am trying to use is 16bit, uses the same clock >>>> source and it has the possibility to use either 2,4,8 prescaler. But that's >>>> all, so in best case using prescaler 8 I would get 0.5us pro 1 tick. >>>> >>>> >>>> >>> The TEP 102 is only specifying how the HIL _must_ look, and provides >>> examples how the lib/timer components can be used to build a flexible HAL >>> layer. The HPL component interfaces are fully driven by the hardware >>> characteristics, so you can do whatever you like there. >>> >>> >>>> My question is what to do with this? I am far away from the values >>>> TEP102 considers. The transformation components are only for the width >>>> adjustment right? (i.e. TransformAlarmC). >>>> Or should I manually adjust the values I get through the HPL interface >>>> using constants (multiplication of the input values by 2) such way that I >>>> get 1us interface? >>>> >>>> >>> My suggestion is to expose the maximal precision on HPL and as >>> Counters/Alarms on HAL level and then use TransformAlarmC which also >>> transforms precision (to a lower one) to provide the HIL. >>> >>> Vlado >>> >>> >>> >>>> Any help is highly apritiated, >>>> >>>> greetings >>>> >>>> Attila >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Tinyos-help mailing list >>>> [email protected] >>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>> >>> >>> >>> >> >> > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
