Trapping a flag/state change (rapidly)

[HankMcSpank]

Hank, I think the hangup for you is how you generate the pattern.

If you use some counters to "decide" when and what led to light up, instead of hanging your program for .4 seconds, you will see the flag check much faster.

Maybe have your interrupt be a time base, like .1mS or something. Then while in the ISR, check for button press and inc your "led counters"

I know this is vague, but all I have time for right now.

Hi Bert,

You're bang on ...using pauses is not optimum, as obviously while it's erhm pausing it ain't doing anything else.

the problem here is I'm already using two timers in my same testbed program here (one for a special event trigger & another to control HPWM) ...ok, so I've 3 timers left (16f1824 has 5 timers) , but I need a whole heap of different pauses (& some quite longish...I've always had an epic fail when I've tried to use timers for long pauses!) ....now I realise I could just reset the timer preload value accordingly each time I need a different pause, but ....aaargh ....brainache. I guess that's what it comes down to... a solution that avoids brainache ...it's a fair cop, I'll get me coat!


Henrik,

Many thanks for the comprehensive examples...I shall study them later tonight.

Cheers,
Hank

[cncmachineguy]

Henrik, I LOVE THAT!!!!!

Hank, I think I like Henrik's idea better, but may or may not work for your app. Are any of the current 2 timers you have ISR's or are they just being used? Cuz if either of them have ISR, you can use that for the timebase. Increment counters there and check for button.

[HenrikOlsson]

If you use TMR2 as the PWM timebase you can use its postscaler as "divider" between the PWM frequency and interrupt frequency. If you have, say, 16kHz PWM frequency and set the postscaler to 1:16 you'll get an interrupt rate of 1kHz which you can use as a timebase if nothing else you already have running is suitable for that.

Again, there are many ways.....

/Henrik.

[rmteo]

...You're bang on ...using pauses is not optimum, as obviously while it's erhm pausing it ain't doing anything else.

If you want to use a PIC (or any MCU for that matter) efficiently, one of the most important things to learn to do - after you have accomplished your first blinky program - is to wean yourself off using pause (blocking) type commands completely.

[rmteo]

....but I need a whole heap of different pauses (& some quite longish...I've always had an epic fail when I've tried to use timers for long pauses!) ....now I realise I could just reset the timer preload value accordingly each time I need a different pause, but ....aaargh ....brainache. I guess that's what it comes down to... a solution that avoids brainache ...

Here is pseudocode that blinks 2 LEDs at different speeds (1Hz and 2Hz) and does not use any pause (blocking delay) type commands. You can easily expand it to any number of LEDs (or tasks) with no performance degradation. It uses a single hardware timer to provide a system tick (also known as a heartbeat). It can be used as a template to create simple multitasking applications.

sub timer1 interrupt
  inc(cyctick1)
  inc(cyctick2)

  if cyctick1 > 500      ' 500mS delay, 1st. counter
    cyctick1 = 0         ' reset counter
    cycflag1 = 1         ' set flag        
  endif
  if cyctick2 > 250      ' 250mS delay, 2nd. counter
    cyctick2 = 0         ' reset counter
    cycflag2 = 1         ' set flag 
  endif
end sub  

sub usrfunction1
  toggle LED0
end sub

sub usrfunction2
  toggle LED1
end sub

main:
  cyctick1=0:cyctick2=0 ' Initialize variables
  ccyflag1=0:cycflag2=0 '         "
  
  timer1 = 1000         ' set up timer1 to interrupt every 1mS

  while true
    if cycflag1=1 then  ' check if 500mS has expired
      cycflag1 = 0      ' reset flag 1
      do userfunction1
    endif
    if cycflag2=1 then  ' check if 250mS has expired
      cycflag2 = 0      ' reset flag 2
      do userfunction2
    endif
  wend