12f675_fuse_about_to_blow!

[LEDave]

Hi Henrik

As you can see, if an interrupt occurs in the middle of a Pause it won't get serviced until the Pause statement has finished so if you're using PBP's ON INTERRUPT you need be aware of this.

Very interesting that because I built a little test circuit based on mackrackit's code using a PIC12F683 (program below) with the INTERRUPT toggling an LED on GPIO.4 The MAIN code turned an LED on and off you've guest it using pause statements!

I was expecting the INTERRUPT LED (GPIO.4) to blink really quickly and the LED on GPIO.0 to blink at 500 mili_secs much slower, in reality they were much the same speed.

The manual refers to this as (latency). Like you say it pays to be aware of it. You wouldn't want an interrupt acting as an emergency stop when combined with a long pause statement.....Ouch!

ANSEL  = %00000000
CMCON0 = %00000111
TRISIO = %11101110
GPIO   = %00000001
INTCON.5 = 1                    'ENABLE TMR0
OPTION_REG = %10000101  '16BIT 1:64 PRESCALE
 
    ON INTERRUPT GOTO TLOOP

    MAINLOOP:
    PAUSE 500    
    low GPIO.0   
    PAUSE 500    
    high GPIO.0  
    GOTO MAINLOOP
     

    DISABLE
    TLOOP:
    INTCON.2=0:TOGGLE GPIO.4
    RESUME: ENABLE

[HenrikOlsson]

Hi,
Now that you're aware of how ON INTERRUPT works there are a few things that can be done to help speed up the response (latency). Instead of having a single 500ms long pause, how about 500 pauses, each 1ms long?

i VAR WORD
Main:
  GPIO.0 = 1
  GOSUB GoToSleep
  GPIO.0=0
  GOSUB GoToSleep
Goto Main

GoToSleep:
  For i = 1 to 500
    PauseUs 1000     'Tweak this if timing is critical.
  Next
RETURN

Now, you should get pretty close to what you expected in the first place. If timing is really critical you'll need to tweak the PauseUs statement as each time thru the loop takes a couple of uS longer due to the inserted checks of the interrupt-flag and the fact that it takes a few cycles to jump around inside the FOR-NEXT loop.

Also, remember what we said about HIGH and LOW? That they write to the TRIS register everytime.....and there's no need for you to use them as you've so elegantly set the TRIS register correctly at the beginning of your program. It's usually "better" and faster to simply write directly to the port register with GPIO.0=1 etc.

/Henrik.

[LEDave]

Henrik thank you.

The program ran a treat. GPIO.0 blinking away at around a half a second period, GPIO.4 essentially 'on' all the time, very clever.

Nice little project you set up there mackrackit, thanks a lot. I've learned a lot from that namely:

1/ Read the program specification more closely! mackrackit wrote:

But if you do this using pauses to blink the LED the pauses will maybe get in the way (they did. I'm pleased they did though, I've learned from that).

2/ How a timed INTERRUPT works and some pitfalls (PAUSE)!

3/ A re-iteration about HIGH / LOW writing to the register everytime they're used. Far better to set the TRISIO register up and write directly to the PORT. I'm starting to appreciate the subtlety of these things, still lots to learn / re-learn though.

Right then, what's next?

Dave

[rmteo]

My suggestion is to learn what a "true" interrupt is and how to use it - as your next step. If it means using DT's routines because PBP does not do it, then by all means do so. It will enable you to do so much more as you advance in your adventures with microcontrollers.

[LEDave]

Thanks for that rmteo.

I'll bear that in mind. Don't forget I'm very new to this, sure I'll have to learn all about interrupts at sometime (maybe now is that time).

I'll be very interested in hearing where mackrackit, Henrik and Joe S think I should go next as they have an understanding on where my knowledge base (or lack of it) lies.

Hey I couldn't turn an LED on a Month ago!

Cheers.

Dave

[mackrackit]

Henrik,
Thanks for finishing that lesson, I got busy.

rmteo,
Good point about ASM interrupts. I am not sure if Dave can do that with the demo version. But when he gets the full version...

Dave,
We are not finished with PBP interrupts yet
As you saw things can move pretty fast with the hardware and if you want to have an event happen at a certain time no matter what an interrupt can help.

Many times it is not recommended to use PAUSEes because as you now know they block other things from happening. There are enough things that do this without adding more, but sometimes we have to use them. Every thing in its place.

Now try something like this...
Do a "MAIN_LOOP" that will TOGGLE a LED with a button press. Every time you press a button the LED changes state.

Then make a BYTE size variable and add the PBP interrupt routine for another LED. The new variable will increment a value of 1 every time the interrupt "triggers".

After a given amount of "trigger", the variable reaches 10 the second LED changes state.

This should happen whether the first LED and button has been activated or not.
By having the variable increment to change the second LED state you can now make it blink at any time frame you want.

[rmteo]

It may be worth pointing out that one does not need to use ASM to use interrupts. I have (and use) 3 different versions/dialects of BASIC for PIC's and they all handle interrupts (including vectored interrupts) without having to delve into ASM. Same situation with C.