Janos, Andreas and David,
>From scale.h the scale32(x,a,b) call calculates x*a/b with fixed point
arithmetic without overflow. The offset was added to help rounding,
but it was not implemented correctly. If you want to calculate x/b,
then it makes sense to calculate it as (x + b>>1)/b to get the
rounding effect. However, this is NOT needed here since a/b should be
close to 1 and in fact the added offset should be a/(2*b). So I think
this is clearly a bug and should be removed!
Andras, can you please change the code to
async command uint32_t Atm128Calibrate.calibrateMicro(uint32_t n) {
return scale32(n, cycles, MAGIC);
}
async command uint32_t Atm128Calibrate.actualMicro(uint32_t n) {
return scale32(n, MAGIC, cycles);
}
and rerun your experiments? David, can you confirm that this is indeed a bug?
Miklos
They add that value to enable rounding
On Mon, Feb 8, 2010 at 5:58 PM, Janos Sallai <[email protected]> wrote:
> 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
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
