Andreas, The rationale behind the MeasureClockC component is to be able to figure out the clock related fuse settings of the MCU in software. The iris (not unlike the mica*) can be programmed to use an external baud friendly 7.3MHz crystal (default), or the internal oscillator at 8 or 1MHz. If you intend to write code that is agnostic to the fuse settings, the Atm128Calibrate.cyclesPerJiffy() command provided by MeasureClockC can help you convert between real time and clock ticks. If you're sure that the fuse settings will never be changed, you can just hardcode the TMilli to microsecond conversion function.
Please see my answers below. > I'm working with tinyos 2.x on an IRIS platform. I need to wait for or > set an alarm to 140 microseconds to get an energy detection value from > the RF230 radio chip. As far as I understand TEP102 and some > correspondence on this newsgroup > (http://www.mail-archive.com/[email protected]/msg30161.html), > the atm128 on the IRIS mote by default is configured to expose its > hardware timers 1 and 3 as "near microsecond" timers, using an external > crystal running at 7.372800 MHz with a prescaler of 8 (resulting in > 921600 Hz). Thus I suppose I could configure start BusyWaitMicroC or > AlarmMicro32C with a value of 140 * 0.9216 = 130 to wait at least 140 > microseconds. Please point out if my reasoning here is incorrect here at > some point. The reasoning is correct. (Timer 1 is ticking at 28800Hz, though, which is "near" 23kHz.) > Now I also found the MeasureClockC component implementing the > Atm128Calibrate interface that as far as I understand should help me to > do exactly that conversion from/to microseconds from/to units I have to > use with components like LocalTimeMicroC, AlarmMicro32C etc. that are > parametrized with TMicro precision tag and using counters from hardware > timers 1 or 3. However: > > Atm128Calibrate.calibrateMicro(140) yields a quite surprising value of > 241 (instead of about 130) > > Trying with values from 0 to 2000 in steps of 100 yields the following > output with the tinyos printf tool (code used at the end) > i / Atm128Calibrate.calibrateMicro(i) / > Atm128Calibrate.actualMicro(Atm128Calibrate.calibrateMicro(i)) > 0 112 242 > 100 204 342 > 200 296 442 > 300 389 543 > 400 481 643 > 500 573 742 > 600 665 842 > 700 757 942 > 800 850 1043 > 900 942 1143 > 1000 1034 1242 > 1100 1126 1342 > 1200 1219 1443 > 1300 1311 1543 > 1400 1403 1642 > 1500 1495 1742 > 1600 1587 1842 > 1700 1680 1943 > 1800 1772 2043 > 1900 1864 2142 > 2000 1956 2242 > > To me this seems to be quite far off everything I would expect, or am I > terribly misstaken about something here? I thought this conversion > function would have to be rather linear with a factor of about 0.9126 or > 1/0.9126 respectively? Thanks for any clarification on that topic. If you take a look at the actual implementation in MeasureClockC, you'll notice that both functions add an offset to the result: async command uint32_t Atm128Calibrate.calibrateMicro(uint32_t n) { return scale32(n + MAGIC / 2, cycles, MAGIC); } async command uint32_t Atm128Calibrate.actualMicro(uint32_t n) { return scale32(n + (cycles >> 1), MAGIC, cycles); } I don't know what the purpose of this, but I left this unchanged when I ported the corresponding mica2 code to the iris. You might want to drop a mail to David Gay regarding this, should you be interested in the rationale. If you really want to stick to using MeasureClockC to do platform TMilli to millisecond conversion (and back), I suggest that you use the Atm128Calibrate.cyclesPerJiffy() command, which gives you the number of clock cycles in 1/32765 of a second. This should be 225 for the iris with the default fuse configuration (using the external 7.3MHz crystal). Janos _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
