> 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... ;-)
I do appreciate all suggestions, good or bad :) > stopwatch_error is a bit a vague word. Why not call it clearly what it is: > stopwatch_overflow ? Sure > 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 I'll have to think up a way to reduce this using user constants. > 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'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. I also thing it may be nice to have a stopwatch to measure instruction cycles instead of time. > 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? Matt. -- 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.
