Sounds good, I'll make the changes. I'll need to set prescaler to 0 anyways so we can measure/count instruction cycles as well.
Calling stopwatch_start() then stopwatch_stop() with noting in between gave a value of 0 since the lib's lowest measurement was 1us which is slower then the speed of a instruction cycle at high OSC speeds. This will have to change. Matt. On Dec 24, 6:41 pm, Oliver Seitz <[email protected]> wrote: > > > 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.
