12f675_fuse_about_to_blow!

[HenrikOlsson]

IF INTCON.2=1
is not needed in the interrupt routine, that is what send the code there in the first place.

Correct. But remember that if/when you start adding more interrupt sources you need to determine which one it was that tripped so checking the interrupt flag is probably good practice. But as have been said, it's not strictly needed in this case.

You seem to have a GOTO Main inside the ISR - you can do that but it is probably not a good idea as it will restart from the beginning of the program and not where it got interrupted. This MAY not be a problem in THIS particular program but can cause some interesting results so - try not to do that.

Have a look at this:

DISABLE 
TLOOP:
IF INTCON.2 = 1 THEN    'TMR0 Interrupt?
   I = I + 1            'Increment counter
   IF I = 100 THEN      'Has it reached 100?
      TOGGLE GPIO.2     'If so, toggle LED...
      I = 0             '...and reset counter
   ENDIF
   INTCON.2 = 0            'Reset interrupt flag
ENDIF
RESUME                  'back to work.
ENABLE

/Henrik.

[LEDave]

Well once again I've learned a lot of things, thanks as ever.

In the UK there's a famous comedy sketch where a musician says "I was playing all the right notes
but not necessarily in the right order".

I was a little (ok a lot) like that in this last exercise. I had written down I = 0 to reset the counter, I knew
I had to do that which is something and I'd figured I = I + 1 to add to / increment the counter, so not all bad.

Henrik highlighted within the program:

 INTCON.2 = 1 THEN   'TMR0 Interrupt?

I guess that's because as mackrackit pointed out to me that for the program to be there the INTERRUPT
must have already occured?

ANSEL   = %00000000      'Disable analog select so ports work as digital i/o
 CMCON0 = %00000111      'Disable analog comparators
 TRISIO = %11111110      'TRISIO.0 set as OUTPUT
 GPIO   = %00000000      'All bits set LOW
 INTCON.5 = 1            'ENABLE TMR0
 OPTION_REG = %10000101  '16BIT 1:64 PRESCALE
 

 ON INTERRUPT GOTO TLOOP  'ON INTERRUPT GOTO the INTERRUPT handler LABEL 'TLOOP'
                              
 i var byte               'Set I as a VARIABLE BYTE

Main: 
 
Not_pressed:
PAUSE 25                            'Leave 25mili_sec for a button press to occur.
if GPIO.5 = 1 THEN GOTO Not_pressed 'Keep waiting for +0v button press on GPIO.5
IF GPIO.5 = 0  THEN goto LED        'Button has been pressed move to LABEL LED:
LED:
TOGGLE GPIO.0                       'Change state of GPIO.0 pin
GOTO Not_pressed                    'Start again
 
 DISABLE                            'Disable INTERRUPT in handler
 TLOOP:
 IF INTCON.2 = 1 THEN   'TMR0 Interrupt?
   I = I + 1            'Increment counter
   IF I = 100 THEN      'Has it reached 100?
      TOGGLE GPIO.2     'If so, toggle LED...
      I = 0             '...and reset counter
   ENDIF
   INTCON.2 = 0         'Reset interrupt flag
ENDIF
RESUME:ENABLE           'ENABLE INTERRUPT in handler start prog again

10/10 for you guys.

Dave (not clever just persistent).

[mackrackit]

You are doing great Dave, I wish more that came here wanted to learn and not just looking for a copy/pastes solution.

I agree with Henrik about this

 INTCON.2 = 1 THEN   'TMR0 Interrupt?

Good to learn what to do if you have multiple interrupts. If you only have one interrupt and you are trying to save code space, as with the demo version, or an instruction cycle or two then you can leave it out.

Another thing to think about when using interrupts is to try and keep the instructions in the handler as few as possible. You would not want to miss an interrupt while taking care of one. Might have to get creative at times but that is the fun. Every project is a puzzle.

Hey, you did not ask "whats next"...

Do you have a serial port or a USB to serial converter on your computer?

[LEDave]

Hey, you did not ask "whats next"...

I nearly did, then I thought have we finished TMR0, I'll leave that one_liner one more post I thought, then you beat me to it

Do you have a serial port or a USB to serial converter on your computer?

On this M/C a DELL, I have only USB's. On my old pc I have two USB ports and a serial port on the back going spare.

Quick question:

When I built that last circuit (VDD/10k resistor/GPIO.5/button/gnd) it worked. When the button ON gpio.5 was pressed the GPIO.0 LED lit (most of the time 90%+). On some occations however the LED didn't latch on or off. I'm thinking switch de-bouncing was the problem. Is there a way of making the switch work 100% of the time? Maybe BUTTON.

Dave

[HenrikOlsson]

Hi Dave,
Yes the switch probably bounced so it did toggle on then off again before you could see it. Or, you happend to press (and release) the button during the 25ms pause which in case means the program misses the button-press.... Or you pressed it and held it longer than 25ms (quite likely) so that when the program "came around" the button was still pressed so it toggled the LED again....

I'd try lowering that first pause a bit or remove it completely and instead add a pause after the TOGGLE GPIO.0 statement to remove any debounce. Then I'd make the program check that the button was released again before jumping back to Not_Pressed But remeber what happens with the interrupt latency when you're using things like Pause etc.

The BUTTON command is another posibillity but to be honest I don't know exactly how it works internally so I can't say what impact it will have on your interrupt latency.

Side note: You can assign aliases to the port pins (or any variable, register, bit etc). So you can do something like:

myButton VAR GPIO.5
LED_1 VAR GPIO.0
LED_2 VAR GPIO.2

If myButton = 0 then....
....
....

/Henrik.

[mackrackit]

What Henrik said....
I have not used the button command either.
To do a check on the button, if the button is pressed the code would GOSUB to a routine to check if the button is still pressed, then return with that info one way or the other.

But... While we are one the subject of interrupts and GPIO5 is on the pin it is.
Look at Interrupt On Change.

In the mean time find a serial cable to connect to your PC and your board. We will get back to communications later.

Play with the switch problem for now.

[LEDave]

Hi Henrik,

But remember what happens with the interrupt latency when you're using things like Pause etc.

I do indeed remember. So as a rule of thumb, are pauses to be avoided in a program whenever possible or only when using INTERRUPTS.

Dave

[mackrackit]

Hi Henrik,



I do indeed remember. So as a rule of thumb, are pauses to be avoided in a program whenever possible or only when using INTERRUPTS.

Dave

In my opinion everything has a place. But most times it is best to avoid long pauses. If you need to pause for a long time setup a pause loop with several short pauses to total the time. Get into that habit and when you do need to use an interrupt you will be ready.