> > Even without using any prescaler, with 4 byte > stopwatch size at 64MHz, the watch will not overflow before > four and a half minutes. That's quite some time when > benchmarking an algorithm. If that's not enough, one could > use 5 bytes to time up to 19 hours. Of course you can leave > it as it is, but my approach would have been to always have > the best (=no prescaler) resolution. Then there can be two > functions (and pseudo variables, for that matter) to read > the result in Tcy or µsec. > > Yes, I may change this. Originally, I was trying to save > from a large > multiply with a result of > byte*4 > ((1/64000000)*4) = 0.0000000625 > > 0xFF_FF_FF_FF * 625 = 2_70_FF_FF_FD_8F
It is good to try to save bytes. But I'm not sure it is absolutely neccessary here. The calculation is just done when the timer is read, which can usually be when it is not running, so the measured time will not get messed up by a time-consuming multiplication. You're giving back microseconds, the 625 are 100*picoseconds. You will be dividing by 10000 anyway, which is more than 13 bit, and brings your value well back to the range of byte*4. So it is just temporary ram used by that multiplication. > > If I had the time (which is not the case right now...) > I'd add a correction constant. For example when reading back > the stopwatch, I would subtract a > constant*_stopwatch_high_value to compensate for the > instruction cycles the stopwatch_isr() has taken. I wouldn't > put the compensation inside the isr, for it is not easy to > safely modify a timer that's incrementing at Tcy. > > I'm not that good with ASM, so I'll leave that to someone > else later > on. I'll take a quick look. If you are timing something > large ( > > 65535 cycles) you may not care about correction. If you are > timing > something that is 4 minutes, you may not care if it is 1ms > off. Fair point ;-) But still, it is a library. We do not know what fancy uses it will be brought to. It could be that it is most useful if it has the maximum achievable accuracy. > > I like the controllable size of the stopwatch, but the > read function only works for sizes of 2 and 4 bytes, the > rest seems to be working with arbitrary numbers of bytes. > Here's a bit room for improvement ;-) > > What other sizes would you want? is "byte" really useful? > is anything > larger useful? Well sometimes I forget that there seems to be a "real" world. No, byte isn't useful. I had just seen that all the library can go with a counter of 2,3,4,5,6,7... bytes, just reading is limited to 2 or 4 byte. Perhaps a larger value could be handy in some setting, but I can't say if 5,6 or 8 bytes is the best choice for that. You're right: Let's wait until someone needs a larger counter, let him do the work on that procedure and update the lib then ;-) Greets, Kiste -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
