> I figured this is a much needed > library. This will give a nice way to > benchmark your code :)
Indeed, it is handy! And I like the code in general, so I tried to find the few points I don't like too much, sorry... ;-) stopwatch_error is a bit a vague word. Why not call it clearly what it is: stopwatch_overflow ? 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. 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 have not tried it, but I presume stopwatch_start() stopwatch_stop() will read 1 Tcy. The time between the two calls is however 0 Tcy, so that one Tcy could also be subtracted. 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 ;-) 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.
