On Wed, May 26, 2010 at 05:52:59PM +1000, Martin Visser wrote: > Pretty much based on the knowledge that the MCU program counter is clocked > on a 16MHz crystal (according to http://en.wikipedia.org/wiki/Quartz_clock > they > are generally good for 6 parts per million for standard grade crystals, > whatever that is).
Ok, that's reasonably accurate. > If you program it using a standard loop to read inputs, calculate and write > out to say a LCD display, you should have a loop-length of known number of > CPU cycles. (This is quite possible with a microcontroller as everything is > in memory and as long you aren't waiting for random DMA interrupts should be > quite feasible. A general purpose CPU running a mega operating system with > lots of peripherals would make this task pretty much impossible). That's what I was thinking - apart from wanting to be sure that the timebase is sufficiently accurate. > Another option is to use the built-in timer/counters (one 8 bit and one 16 > bit are available) on the AVR ATmega MCU. Again clocked against the same > crystal, and using a configurable frequency divider mechanism. The arduino language/library includes a millis() function which returns the number of msec of uptime; it's a 32-bit unsigned counter so it overflows after 49.7 days. There's also a microsecond counter with a 4 or 8 uS resolution depending on the CPU clock speed. > And finally there are various dedicated real-time chips, such as DS1307, > which combined with a crystal (usually 32.768KHz) can be easily interfaced > if needed. These chips tend to be human-scale timers so you might have to > count lots of repetitions of your loop under test and do the maths to get an > average loop time (possibly limiting its usefulness). Depending of course on the timescales being measured either the milli- or microsecond counter should be adequate. Reasons for looping several times would be "the counter resolution isn't high enough" and "the program being tested takes a varying time to run". If run on a desktop operating system, there's a lot of activity going on in the background so looping many times and taking an average is, I think, a necessity. I have an Arduino which I'll be using for temperature monitoring among other things. While running the Thermistor2 program I noticed the reported temperature jumped around almost at random. I did some analysis and a lot of that "noise" is coming from the ADC itself: I wired it up to fixed value resistor dividers (instead of a resistor and thermistor) and monitored the ADC value twice a second for several days. It turns out the ADC value is approximately Normally distributed with a standard deviation of about 0.7 x LSB. From what I have read this is out of spec and it may be due to noise in the input voltage (USB powered) and can also be reduced by adding a capacitor to the circuit (which I haven't done). I modified the code to take 10 readings at a time and average them; this reduces the standard deviation considerably. So I'm looking forward to hooking it back up to the thermistor and running the revised temperature program. It should show better than 0.1 degree C precision, however it will still need to be calibrated to be at all accurate. Nick. -- PGP Key ID = 0x418487E7 http://www.nick-andrew.net/ PGP Key fingerprint = B3ED 6894 8E49 1770 C24A 67E3 6266 6EB9 4184 87E7 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
