Instant Interrupts - Revisited

[HankMcSpank]

Just a quickie, re IOC interrupts....how do I know which one to use? (previously I was using IOC with a 16f690 & used RABC_INT then, but the PIC I'm using now doesn't have a PORT B)

From DT's site...

Several new interrupt sources have been added in version 1.00. GPC_INT, IOC_INT, RAC_INT, RABC_INT and the original RBC_INT are all forms of Port Change Interrupts. The chip being programmed determines which one you need to use.

Where do I look to establish this info?

I'm using one of the newer 14 pin 16F1823 PICs.

[Darrel Taylor]

The key is to look in the INTCON register.

For the 16F690, INTCON.0 is RABIF. So you would use RABC_INT.

With the 16F1823, INTCON.0 is IOCIF, so it's IOC_INT.

I could probably make it so IOC_INT works for all of them.
They are all "Interrupt On Change".

[HankMcSpank]

Many thanks Darrel.

I have a problemetette - my program runs fine, but then when I press a switch (to generate an IOC), an interrupt *is* triggered, but it then seems to loop in my interrupt handler (it's actually becuase the INTCON.0 bit seems to be staying at 1, which keeps it jumping to the interrupt handler constantly)

Any ideas, why the IOC_FLAG = 0 entry towards the end of the interrupt handler doesn't appear to be taking affect?

IOC_FLAG VAR INTCON.0 ' Alias RABIF interrupt flag bit
debug_out var byte
SW1    VAR PORTA.5
on_status var byte
Green_LED VAR PortC.1 

ASM
INT_LIST  macro ; IntSource,    Label,         Type, ResetFlag?
    INT_Handler  IOC_INT,  _Switch_Interrupt,  PBP,  YES 
    endm
    INT_CREATE       ; Creates the interrupt processor
ENDASM

Check:                        
  'Check switches before enabling/re-enabling IOC   
  WHILE SW1 = 0 : WEND  ' Wait until all switch inputs = 1 
 IOC_FLAG = 0          ' Clear the int-on-change flag bit

@ INT_ENABLE IOC_INT   ; Enable 'Int On Change' interrupts
on_status = 0
Low GREEN_LED


'+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Switch_Interrupt:
hserout ["trap ", dec IOC_FLAG, 13, 10]

@ INT_DISABLE IOC_INT  ; Disable further IOC interrupts


        pause 10
        IF sw1 = 0 THEN
        if on_status = 1 then 
        on_status =0
        Low GREEN_LED
        else

        High GREEN_LED
        on_status =1
        endif
        endif
        pause 20


        WHILE SW1 = 0 : WEND
        pause 25
        IOC_FLAG = 0
@ INT_ENABLE IOC_INT
@ INT_RETURN

This is almost certainly something I'm doing wrong, but then again, it's pretty much a direct what was working fine my functioning 16F690 IOC routine?

[Darrel Taylor]

On these Enhanced chips, the Interrupt On Change works much better than on the older chips.

You can specify wether you want Rising edges, Falling edges or both by enabling them in the IOCAP and IOCAN.

Then each Pin has it's own interrupt flag in IOCAF. And you need to clear those bits.

It's described better in section 13.0 in the datasheet.
http://ww1.microchip.com/downloads/e...Doc/41413A.pdf

[HankMcSpank]

Yet again, you've come up trumps - worse still I knew about the positive edge/falling edge for triggering an interrupt ...since I'm using weak internal pullups, I selected negative, but I never made the connection that I'd have to clear the flag you mentioned....I've now modified my code to clear IOCAF ..... & it works a treat.

You've made a happy man very old.

[DaTiNs]

Thank you for quick reply!

Yes i have, this is configuration for my pic



ADCON1 = $0F
CMCON = 7
UCFG.3 = 1
PORTA = 0
PORTB = 0
PORTC = 0

[DaTiNs]

Just want to add,when I turn off TRM1 before reading i2c, rtc is operating normally, but problem is with LED strips on PWM channel they strart flashing.

T1CON.0=0
I2CRead sda,scl,$D0,$00,[RTCSec,RTCMin,RTCHour,RTCDay,RTCDate,RTCMonth,RTCY ear]
T1CON.0=1

[Darrel Taylor]

Damir,

I can duplicate the issue here, which appears to be the old R-M-W hardware problem.
I moved the PWMs over to PORTC, and everything works fine.

Since I2C uses pull-ups instead of bi-polar driven outputs, it's more susceptable to R-M-W problems.

If you cannot move pins around on your project, you can get away with the following.
In general, I do not recommend doing this type of modification.
But in your specific case, it should work.

  SPWM_LIST macro 
      SPWM_PIN LATA, 2, _CH1 
      SPWM_PIN LATA, 3, _CH2 
      SPWM_PIN LATA, 4, _CH3 
      SPWM_PIN LATA, 5, _CH4 
    endm

[Darrel Taylor]

I should have also mentioned that when using the LATA register, you'll need to set the pins to output manually.

TRISA = %11000011

[DaTiNs]

Thank you very much!

I must add TRISA = 0 to the begin of code, and then start work great.

One more time, thank you, Damir.

[SteveB]

Darrel,
While poking around and getting ideas, I got to looking at ver 1.2 of "Elapsed_INT-18.bas". I was particularly interested in the nice routine to calculate the timer reload constant:

' -------------- calc timer reload Constants -------------------------------
ASM
T1PS = 1                             ; start with 1:1 postscaler
TimerConst = ((OSC*1000000)/4/100)   ; how many timer ticks will it take
  while TimerConst > 65400           ; if it's more than the timer can count
T1PS = T1PS * 2                      ;   double the postscaler
TimerConst = TimerConst / 2          ;   halve the count
  endw
TimerConst = 65536 - TimerConst + 8  ; final reload value

But, I think there is an error in the formula. The absolute time it takes to execute the 8 instruction cycles doesn’t change. But, the time in relation to the TMR1L will be proportional to the prescaler. So, that should be accounted for in the formula, as such:

TimerConst = 65536 - TimerConst + (8/T1PS)  ; final reload value

Since it's not likely the prescaler will need to be above 1:8, the 8/T1PS shouldn’t get too low.

Thanks again for your great work and inspiring examples,
Steve