> Another question: Does a PIC not need overflow interrupts to count say > 5000000 counts as I do in the Arduino?
Lars, For precision work you must avoid having more than one interrupt. Otherwise there is the chance both will occur at or too near the same time and introduce unexpected latency. There are a couple of solutions. 1) Use a chip with capture h/w so you don't need an interrupt for critical time measurements. 2) Handle timer rollover in software (as in polling) to avoid timer interrupts. 3) Keep track of time with instruction counting instead of an overflowing and interrupting timer. 4) Avoid overflows and interrupts by using time intervals instead of elapsed time. 5) Use a chip with multiple cores with at most one interrupt per core (or a propeller chip with no interrupts at all). The other point to make is interrupt latency. Aside from the sub-cycle h/w synchronization jitter (which is always present) each microcontroller family has a certain number of instruction cycles of latency before your interrupt code executes. In the case of the PIC, this is a fixed number, which is why something like the picPET can be accurate to one cycle. From what I've read the AVR does not have fixed latency, due to its variable- or multi-cycle instructions. Consequently your interrupt handler has both h/w jitter and s/w jitter. To most people this is who-cares. But when you're counting nanoseconds these details matter a lot. Many uC these days have CCP (capture/compare) in h/w, which pushes the problem of timing to bare hardware instead of being tied to instruction timing or interrupts. So if the chip you're using has CCP, by all means use that. That way your 1PPS timing is done in h/w and your s/w only has one timer interrupt to deal with. /tvb _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
