[chbot] !!!Choc fish challenge!!!!
Col
colp42 at gmail.com
Sat Jul 23 08:14:21 BST 2011
On 22/07/11 16:24, Synco Reynders wrote:
> Well, I feel honored for winning the chocolate fish, and sorry for
> anyone who hasn't got a mute function on this email thread.
> I've had a frustrating day trying to code up a brushless DC motor
> controller... (hence the procrastinating).
> Anyway I'd like to put this winning chocolate fish up for grabs again to
> the first person that tells me how to measure a pulse-width (connected
> to an external interrupt), glitch-free!! :
> This is roughly what I got:
>
> #define TIMERWRAP 1024
>
> ISR(ExternalInterrupt) // highest priority
> {
> if (triggered on +ve edge) {
> set to trigger on -ve edge;
> count = TIMERWRAP - Timer;
> }
> else {
> set to trigger on +ve edge;
> count += Timer;
> // Now Count should be the pulse length... but it has glitches
> see below
> }
> }
>
> ISR(TimerOverflow) // overflows at TIMERWRAP ticks
> {
> count += TIMERWRAP;
> ....
> }
>
> ISR(other)
> {
> ...
> }
>
> Now the problem occurs (very infrequent) when both the TimerOverflow and
> External interrupt occur while another (non-nesting) ISR is being
> processed. The Ext Interrupt will be processed first therefore missing
> out on the extra TIMERWRAP. I've tried compensating by reading the
> interrupt flag register when processing the external interrupt, it
> reduces the frequency of glitches but as-long as there is any
> time between reading the flags register and the timer I get glitches.
> Is this one of those impossible micro-processor problems?
>
Here's my attempt at a solution.
ISR(other ,ISR_NOBLOCK)
{
disable other ISR's;
...
//re-enable other interrupts in reverse priority order;
re-enable timer interrupt;
re-enable external interrupt;
}
Col.
More information about the Chchrobotics
mailing list