Hello. I perform a simple experiment: a TinyOS 2.0.2 application reads the 32kHz-timer (using interface Alarm<T32khz, uint32_t> provided by Alarm32khz32C.nc) and forwards the reading to computer. This happens each time when another timer fires (accessed via interface Timer<TMilli> provided by TimerMilliC.nc) - periodically once a second. I did several such experiments (several thousand readings in each one).
At first, the values are usual, e.g. 0xF0144, 0xF8144, 0x100144 and so on, i.e. the difference between two consecutive values is always 0x8000 (since each second the content of the 32kHz timer increases by 32768). But the readings around 250th, 750th, 1250th, 1750th etc. second from the beginning of the experiment are strange. For example, 0x7D01A5 is followed by this sequence: 0x7D81A5 (it's more by 0x8000 than the previous, so it's all right), 0x7D01A5 (it's less by 0x8000 than the previous!), 0x7D81A5 (it's OK with regard to the previous) and 0x7F01A5 (it's more by 0x18000 than the previous!). It looks like when the timer should go from 0x7DFFFF to 0x7F0000 it goes actually from 0x7DFFFF to 0x7D0000 (the first pair of values in the aforementioned sequence), i.e. the upper word is not incremented at all. But when the timer should go from 0x7DFFFF to 0x7E0000 it goes from 0x7DFFFF directly to 0x7F0000 (the last pair in the sequence), i.e the upper word is incremented by 2 right away. So, this "error and compensation" happens approximately every 500 seconds starting from 250th second of the experiment. I think this is somehow related to the handling of the 16-bit 32kHz timer overflow. But it's not clear why exactly when the timer content should change from 0x7DFFFF to 0x7F0000, from 0x17D0000 to 0x17E0000 etc. Could anybody explain it? Anton. _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
