[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