Instant Interrupts - Revisited

[Darrel Taylor]

Nothing wrong there.

There are two different actions that can change the way INT_ENABLE works with version 1.10.

DEFINE INT_ENABLECLEARFIRST 1 ; (default)
With the above define, which is also the default, whenever you INT_ENABLE, the flag is automatically cleared before the interrupt is enabled.

DEFINE INT_ENABLECLEARFIRST 0
Whith this define, the flag is NOT cleared.
This can dramatically change the results and cause immediate interrupts if the flag is already set.

If INT_ENABLECLEARFIRST is 0, then INT_ENABLE takes one instruction cycle.
If INT_ENABLECLEARFIRST is 1, then INT_ENABLE takes two instruction cycles.

INT_DISABLE always takes one instruction.

[reik6149]

hi all, i face a problem here.

why when im trying to compile the dt_ints-18 file without changing anything, it shows

Error[113] c:\picbas~1.47\pbppic18.lib 1170 : symbol not previously defined (int_entry_H)

im using 18f2680

[Ioannis]

I suppose you did commend the 4 lines starting with __CONFIG in the xxx.inc file inside your PBP directory, right?

Ioannis

[reik6149]

huh?? do you means 18f2680.inc ? but i dint change anything with it..below is the inc file

;************************************************* ***************
;* 18F2680.INC *
;* *
;* By : Leonard Zerman, Jeff Schmoyer *
;* Notice : Copyright (c) 2006 microEngineering Labs, Inc. *
;* All Rights Reserved *
;* Date : 06/05/06 *
;* Version : 2.47 *
;* Notes : *
;************************************************* ***************
NOLIST
ifdef PM_USED
LIST
"Error: PM does not support this device. Use MPASM."
NOLIST
else
LIST
LIST p = 18F2680, r = dec, w = -311, w = -230, f = inhx32
INCLUDE "P18F2680.INC" ; MPASM Header
__CONFIG _CONFIG1H, _OSC_XT_1H
__CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
__CONFIG _CONFIG3H, _MCLRE_ON_3H & _PBADEN_OFF_3H
__CONFIG _CONFIG4L, _XINST_OFF_4L & _LVP_OFF_4L
NOLIST
endif
LIST
EEPROM_START EQU 0F00000h
BLOCK_SIZE EQU 64

[ScaleRobotics]

hi all, i face a problem here.

why when im trying to compile the dt_ints-18 file without changing anything, it shows

Error[113] c:\picbas~1.47\pbppic18.lib 1170 : symbol not previously defined (int_entry_H)

im using 18f2680

It's not really clear, but it sounds like you might be trying to compile the include file, rather than including it in your code. You are supposed to compile something like this:

LED1   VAR  PORTB.1

INCLUDE "DT_INTS-18.bas"     ' Base Interrupt System
INCLUDE "ReEnterPBP-18.bas"     ' Include if using PBP interrupts

ASM
INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
        INT_Handler   TMR1_INT,  _ToggleLED1,   PBP,  yes
    endm
    INT_CREATE               ; Creates the interrupt processor
ENDASM

T1CON = $31                ; Prescaler = 8, TMR1ON
@ INT_ENABLE  TMR1_INT     ; enable Timer 1 interrupts

Main:
  PAUSE 1
GOTO Main

'---[TMR1 - interrupt handler]--------------------------------------------------
ToggleLED1:
     TOGGLE LED1
@ INT_RETURN

[reik6149]

yea !! it works !!!! thank you very much ! im too busy body and trying to compile the file each of it.zzzz

[HankMcSpank]

Nothing wrong there.

There are two different actions that can change the way INT_ENABLE works with version 1.10.

DEFINE INT_ENABLECLEARFIRST 1 ; (default)
With the above define, which is also the default, whenever you INT_ENABLE, the flag is automatically cleared before the interrupt is enabled.

DEFINE INT_ENABLECLEARFIRST 0
Whith this define, the flag is NOT cleared.
This can dramatically change the results and cause immediate interrupts if the flag is already set.

If INT_ENABLECLEARFIRST is 0, then INT_ENABLE takes one instruction cycle.
If INT_ENABLECLEARFIRST is 1, then INT_ENABLE takes two instruction cycles.

INT_DISABLE always takes one instruction.

thanks for the clarification Darrel!

I look forward to the day where I don't have to read something 10 times ...and still not be 100% sure what it means! Until then please humour me - I'm using V1.1 of your interrupts ...when you mention the default is for your code to clear any interrupt flag (ie prior to enabling) , but then I got confused when seeing this accompanying snippet....

DEFINE INT_ENABLECLEARFIRST 1 ; (default)

So, Pop quiz, should I....

a) should I be putting such a line at the top of my program?
B) modifying DT_INTS-14.BAS?
c None of the above (it's erhm..... done by default!)

thanks!

[reik6149]

finally i could done with the code, hereby special thanks to darrel taylor and scalerobotics !!!

[Ioannis]

I downloaded the latest version 1.10 for the DT-INTS14 and now I get a lot of errors.

Does anyone else has the same problem? With v1.0 had no error (but nothing was working either.... )

I want to use IOC of a F887 device.

The test code is this:

DEFINE OSC 4

;----- Configuration bits ------------------------------------------------
@Line1 = _DEBUG_OFF & _LVP_OFF & _FCMEN_OFF & _IESO_OFF & _BOR_OFF
@Line2 = _CP_OFF & _MCLRE_ON & _PWRTE_ON & _WDT_ON & _XT_OSC

@ __CONFIG _CONFIG1, Line1 & Line2
@ __CONFIG _CONFIG2, _WRT_HALF & _BOR40V

OPTION_REG.0=1		'PSA0 PRESCALER SELECT 1:1 TO 1:256
OPTION_REG.1=1		'PSA1
OPTION_REG.2=1		'PSA2
OPTION_REG.3=1		'PRESCALER TO: 1->WDT, 0->TMR0
OPTION_REG.4=0		'T0SE SOURCE EDGE 1->H TO L, 0->L TO H
OPTION_REG.5=0		'T0CS 1->FROM RA4, 0->FROM INT. CLOCK
OPTION_REG.6=0		'INT EDGE SELECT 0->H TO L, 1->L TO H
OPTION_REG.7=0		'PULL UP 1->DISABLE, 0->ENABLE

adcon0=%01000001    '0 off
adcon1=$80'6 off (all digitals)
ansel=$01
anselh=$00

PORTA=%00000001:PORTB=%00010000:PORTC=%10000001:PORTD=0:PORTE=0

TRISC=$80:TRISD=0:TRISE=0

TRISA = %00000001:TRISB = %00010000

WPUB=%00010000          'Enable weak pull up on PortB.4

while 1
wend

ASM
INT_LIST  macro;    IntSource,  Label,      Type,  ResetFlag?
    INT_Handler     RBC_INT,    _IOC2,      PBP,    yes
    endm
    INT_CREATE            ; Creates the interrupt processor
ENDASM

@   INT_ENABLE  RBC_INT      ; Enable Port B on change
'-------------   INTERRUPTS SETUP   ---------------------

IOC2:
    if portb.4=1 then
        high portb.0
    else
        low portb.0
    endif
@ INT_RETURN

The errors are like ERROR: (" Add:" wsave1 VAR BYTE $A0 SYSTEM, Or change to wsave BYTE $70 SYSTEM)

or

ERROR: (Chip has RAM in BANK3, but wsave3 was not found.) etc

Ioannis

[Darrel Taylor]

Everyone seems to do that.....

What you need to do is contained in the error messages.
Follow the directions, and they will go away.

[Ioannis]

Sorry I did not fully understood what you mean...

With the old (version 1.00) there is no problem in compiling with RBC_INT interrupt. With 1.10 I get various errors like the ones posted.

Of course I made a mistake in interrupt selection. IOC_INT should be used and not RBC_INT.

With the old version 1.00, after compiling I get

ERROR: ("INT_Handler" - Interrupt Flag (INTCON,IOCIF ) not found.)

and

ERROR: ("INT_ENABLE" - Interrupt Flag (INTCON,IOCIF ) not found.)

Ioannis

[ScaleRobotics]

Hey Iannis,

This may be a dumb question, but are you including the includes? I don't see them in your code.

if you are getting the wsave, wsave1, wsave2, or wsave3 errors, change the wsave settings in the DT_INTS-14.bas, like it shows you.

[Ioannis]

Hi. Yes I did included them. The sample was stripped down from the obvious.

Well, the new DT-INTs have changed a little I suppose.

OK, Darrel pointed what to do. I did uncomment the wsave1,2,3 lines and put on the main program the lines:

wsave   VAR BYTE    $20     SYSTEM      ' location for W if in bank0
;wsave   VAR BYTE    $70     SYSTEM      ' alternate save location for W 
                                         ' if using $70, comment wsave1-3

It seems that it doesn't matter which one I un-comment as it compiles both.

But with version 1.10 of the DT-INTs I have a new error about the INTCON,IOCIF flag...

Ioannis

[ScaleRobotics]

Your code compiles here without errors. PBP 2.60A

[Ioannis]

DT-INTS version 1.00 or 1.10?

Ioannis

[ScaleRobotics]

I used DT-INTS 1.10 on a 16f887

[Ioannis]

When compiling the attached file I get the attached error.

It drives me crazy....

Ioannis

[aratti]

Hi Ioannis, you cannot use the wsave variable outside the DT interrupt since such a variable is in use within the routine.

wsave   VAR BYTE    $20     SYSTEM      ' location for W if in bank0
;wsave   VAR BYTE    $70     SYSTEM      ' alternate save location for W 
                                         ' if using $70, comment wsave1-3
clear
INCLUDE "c:\projects\picdem2\DT_INTS-14.bas"
INCLUDE "c:\projects\picdem2\ReEnterPBP.bas"

You have to comment/uncomment the variable within DT int routine.

Al.

[ScaleRobotics]

Are you still compiling for a 16f887? Because that chip doesn't even have a IOCIF. I think only the 16f1827's and such have one of those. So that is pretty weird.

[Darrel Taylor]

For a 16F887, it's RBC_INT.
You can tell that from the datasheet which specifies "PORTB change" interrupts.

And with DT_INTS-14 you'll see some comments in the file ...

;-- Place a copy of these variables in your Main program -------------------
;--   The compiler will tell you which lines to un-comment                --
;--   Do Not un-comment these lines                                       --
;---------------------------------------------------------------------------
;wsave   VAR BYTE    $20     SYSTEM      ' location for W if in bank0
;wsave   VAR BYTE    $70     SYSTEM      ' alternate save location for W 
                                         ' if using $70, comment wsave1-3

' --- IF any of these three lines cause an error ?? ------------------------
'       Comment them out to fix the problem ----
' -- Which variables are needed, depends on the Chip you are using -- 
;wsave1  VAR BYTE    $A0     SYSTEM      ' location for W if in bank1
;wsave2  VAR BYTE    $120    SYSTEM      ' location for W if in bank2
;wsave3  VAR BYTE    $1A0    SYSTEM      ' location for W if in bank3
' --------------------------------------------------------------------------

The idea is that wsave variables should be in your main program.
The old way, when you compile for a different chip, it may not have had the correct variables, and it would not have warned you.

Now it will always tell you when the wrong variables are commented.
And you can just change them in your code, and NEVER have to edit DT_INTS-14.

Some people get carried away with the editing and screw everything up.
Now there's NO REASON to edit DT_INTS-14

[ScaleRobotics]

Your code compiles here without errors. PBP 2.60A

To be clearer, your code in post 609 compiles using the code shown. I had not tried it with the IOC_INT, only with the code listed in post 609. I guess you meant that when you changed it to IOC, you got the errors.....

Sorry

Walter

[Ioannis]

Thanks all for the support.

Al.: We are testing the new DT-INTs version 1.10. Here as Darrel pointed out the wsave are set in the main program.

Darrel: You are correct in the Port change Interrupts. Ok, I have them corrected and the two errors went away. But no joy on Interrupts. It seems that they are never triggered.

The latest test code is this:

DEFINE OSC 4

@Line1 = _DEBUG_OFF & _LVP_OFF & _FCMEN_OFF & _IESO_OFF & _BOR_OFF
@Line2 = _CP_OFF & _MCLRE_ON & _PWRTE_ON & _WDT_ON & _XT_OSC

@ __CONFIG _CONFIG1, Line1 & Line2

@ __CONFIG _CONFIG2, _WRT_HALF & _BOR40V

OPTION_REG.0=1		'PSA0 PRESCALER SELECT 1:1 TO 1:256
OPTION_REG.1=1		'PSA1
OPTION_REG.2=1		'PSA2
OPTION_REG.3=1		'PRESCALER TO: 1->WDT, 0->TMR0
OPTION_REG.4=0		'T0SE SOURCE EDGE 1->H TO L, 0->L TO H
OPTION_REG.5=0		'T0CS 1->FROM RA4, 0->FROM INT. CLOCK
OPTION_REG.6=0		'INT EDGE SELECT 0->H TO L, 1->L TO H
OPTION_REG.7=0		'PULL UP 1->DISABLE, 0->ENABLE

adcon0=%01000000    '0 off
adcon1=$80'6 off (all digitals)
ansel=$01
anselh=$00

PORTA=%00000001:PORTB=%00010000:PORTC=%10000001:PORTD=0:PORTE=0

TRISC=$80:TRISD=0:TRISE=0

TRISA = %00000001

TRISB = %00010000

wsave   VAR BYTE    $20     SYSTEM      ' location for W if in bank0
;wsave   VAR BYTE    $70     SYSTEM      ' alternate save location for W 
                                         ' if using $70, comment wsave1-3
clear
INCLUDE "c:\projects\picdem2\DT_INTS-14.bas"
INCLUDE "c:\projects\picdem2\ReEnterPBP.bas"

'-------------   VARIABLES   ---------------------

code_in             var portb.4

'-------------   VARIABLES   ----------------------

t1con=%00000000         '65,535ms interrupt time base

clear
goto main

'-------------   INTERRUPTS SETUP   ---------------------

IOCB=%00010000          'Enable IOC on PortB.4
WPUB=%00010000          'Enable weak pull up on PortB.4

ASM
INT_LIST  macro;    IntSource,  Label,      Type,  ResetFlag?
    INT_Handler     RBC_INT,    _IOC2,      PBP,    yes
    endm
    INT_CREATE            ; Creates the interrupt processor
ENDASM

@   INT_ENABLE  RBC_INT      ; Enable Port B on change

'-------------   INTERRUPTS SETUP   ---------------------

IOC2:
    if code_in then
        high portb.0
    else
        low portb.0
    endif
@ INT_RETURN


main:
while 1
toggle portb.2
pause 100
wend

End

Ioannis

[Darrel Taylor]

Ioannis,

Remove the second CLEAR statement, and move the GOTO Main after the interrupt declaration, just before the IOC2: handler.

The interrupt declaration and the IOCB/WPUB must be allowed to execute.

[Ioannis]

Hi Darrel.

Well, with 3 toddlers running around till 10.30 pm sure I will have double CLEAR commands to clear my mind!

OK I moved the IOCB/WPUB before GOTO main but still no Interrupts occur.

In fact is second or third try with different controller that I cannot make an interrupt on change to work... Not lucky I guess.

The latest test code is this:

t1con=%00000000         '65,535ms interrupt time base
IOCB=%00010000          'Enable IOC on PortB.4
WPUB=%00010000          'Enable weak pull up on PortB.4

goto main

'-------------   INTERRUPTS SETUP   ---------------------
ASM
INT_LIST  macro;    IntSource,  Label,      Type,  ResetFlag?
    INT_Handler     RBC_INT,    _IOC2,      PBP,    yes
    endm
    INT_CREATE            ; Creates the interrupt processor
ENDASM

@   INT_ENABLE  RBC_INT      ; Enable Port B on change
'-------------   INTERRUPTS SETUP   ---------------------

IOC2:
    high portb.1
    if portb.4 then
        high portb.0
    else
        low portb.0
    endif
@ INT_RETURN


main:
while 1
    toggle portb.2
    pause 1000
wend

Thanks for the efforts.

Ioannis

[Ioannis]

OK. I got it. Was the goto main before Interrupt setup.

Sorry for my careless... A cupof coffee did the job!

Ioannis

[HankMcSpank]

I'm needing to use DIV32 in my program, this from the compiler manual...

"...blah, blah, blah...........ON INTERRUPT must be
DISABLEd from before the multiply until after the DIV32. If ON
INTERRUPT is not used, there is no need to add DISABLE to the
program. Interrupts in assembler should have no effect on the internal
variables so they may be used without regard to DIV32."

Now I'm blissfully unaware how DT's interrupts work 'under the hood' ...so could someone put a layman's spin on whether DT's interrupts are "interrupts in Assembler" (& therefore whether I'm free to use DIV32or not?)

Thanks.

[Darrel Taylor]

DIV32 only has a problem with ON INTERRUPT.

ASM interrupts and DT_INTS has no problem with it.

[HankMcSpank]

DIV32 only has a problem with ON INTERRUPT.

ASM interrupts and DT_INTS has no problem with it.

Excellent news....and thanks for the quick response (I'm off to divide 2147483647 by 32767 .....just because)

[mark_s]

Hello,

I was trying to experiment with HankMcSpank's comparator interupt code. But am having problems getting it to compile.

I am using,
PIC18f4480
PBP 2.60A
DT_INT-18 3.3
ReEnter-18 v?
MPASM 5.2

It is giving me "missing argument", Interupt(FlagReg,Flagbit) not found etc
Error ("Int_handler"..... Error (Int_Enable

If anyone has any ideas, I would be greatfull.

Thanks

[Darrel Taylor]

The 18F4480 only has 1 interrupt flag for both comparators.

You would use CMP_INT, then check the C1OUT/C2OUT bits in CMCON to determine which one triggered the interrupt.

[mark_s]

The 18F4480 only has 1 interrupt flag for both comparators.

You would use CMP_INT, then check the C1OUT/C2OUT bits in CMCON to determine which one triggered the interrupt.

Thank you, Darrel!

Had the same issue with the PIC16f877A- Will revisit tonight.

[HankMcSpank]

Hello,

I was trying to experiment with HankMcSpank's comparator interupt code.

Be warned...it's still very much a work in progress, I've just revisited this one & noticed a whopping proble. On the basis that a picture is worth a thousand words, I just posted up a youtube video, which illustrates my last remaining problem - there appears to be bit of an ssue measuring smaller phase shifts...

Have a look at my video on this thread...

http://www.picbasic.co.uk/forum/show...4382#post94382

[mark_s]

Be warned...it's still very much a work in progress, I've just revisited this one & noticed a whopping proble. On the basis that a picture is worth a thousand words, I just posted up a youtube video, which illustrates my last remaining problem - there appears to be bit of an ssue measuring smaller phase shifts...

Have a look at my video on this thread...

http://www.picbasic.co.uk/forum/show...4382#post94382

Hank,

I got my code working last night , thanks to Darrel. The pic chips I am using only have one comparator interupt. By reading the output bits on each comparator and putting an IF statement in the ISR, I can read the frequency and phase like your code. My test so far is with a fixed 180 deg. I need to wire up a variable phase shifter, so that I can compare my results with yours. Not sure why you can't read below 33 deg? Maybe phase locking between the two comparators or interupt house keeping? What happens if you halve the frequency?

[HankMcSpank]

Hank,

I need to wire up a variable phase shifter, so that I can compare my results with yours. Not sure why you can't read below 33 deg? Maybe phase locking between the two comparators or interupt house keeping? What happens if you halve the frequency?

It all works well above a certain phase shift (depending on the signal frequency)...just when you get to the lower regions that this quirk kicks in.

I'm sure you're sorted for a phase shift cct, there's a simple one here....

http://www.werewoolf.org.je/graphics/apf1.gif

....make R1 & R2 the same value -I used 10k - the cap about 100nf & R4 a 10k pot (wired with the wiper to the ground end)....this gives about 90 degrees of phase shift @ 159Hz...if you want more phase shift,cascade a few together & use this designer http://www.aleph.co.jp/~takeda/radio/psDesigner.swf

just be sure that the signals into your PIC comparator are identical (I square them up first - remember ...different edge 'slopes' equals different triggering points for the PIC comparators which translates into a phase measurement error - and I also check on a scope to make sure there aren't any edge timing errors intrduced prior to the PIC)

If I half the incoming frequency (or double it), the Comp2 count remains the same (ie it won't go below 336, as I phase shift to the lower regions)...so I'm inclined to think it's housekeeping 'can't avoid' timing issue of some sort.

there maybe one fly in my particular ointment - my PIC supply is 4V...the datasheet says that 4.5V is the minimum when using a 20Mhz External clock. (& annoyingly, I don't appear have any 5V regulators handy so now looking at dropping the clock back to 8Mhz)

I look forward to your results so get a move on!

[mark_s]

If I half the incoming frequency (or double it), the Comp2 count remains the same (ie it won't go below 336, as I phase shift to the lower regions)...so I'm inclined to think it's housekeeping 'can't avoid' timing issue of some sort.

there maybe one fly in my particular ointment - my PIC supply is 4V...the datasheet says that 4.5V is the minimum when using a 20Mhz External clock. (& annoyingly, I don't appear have any 5V regulators handy so now looking at dropping the clock back to 8Mhz)

Thats strange that halving the frequency does not change the minimum phase reading. The interupt process of saving and restorring variables should take the same amount of time weather your input frequency is 1hz or 1khz. So halving your frequency, should double your count on tmr1 while the interupt processing time remains constant. As a ratio, the lower the input frequency, the less effect processing delays have on your final value.

Example
Input 500Hz = 2ms or 5.5us/deg with a 33 degree lag = 183us

Then at 250Hz = 4ms or 11.1us/deg with a 33 degree lag = 366us

So for argument sake, lets say it takes minimum of 183us to process the interupt (not likely). If
we plug this into the 250hz case, we get 183us/11.1us or a minimum of 16.4 degrees.

I think there is something else going on, 183us is a long time. The power supply is pretty important and could cause havic in the analog circuits (Vref) if not regulated. If you're feelin lucky you can get 5v regulated off your USB port.

[HankMcSpank]

Thats strange that halving the frequency does not change the minimum phase reading. The interupt process of saving and restorring variables should take the same amount of time weather your input frequency is 1hz or 1khz. So halving your frequency, should double your count on tmr1 while the interupt processing time remains constant. As a ratio, the lower the input frequency, the less effect processing delays have on your final value.

Example
Input 500Hz = 2ms or 5.5us/deg with a 33 degree lag = 183us

Then at 250Hz = 4ms or 11.1us/deg with a 33 degree lag = 366us

So for argument sake, lets say it takes minimum of 183us to process the interupt (not likely). If
we plug this into the 250hz case, we get 183us/11.1us or a minimum of 16.4 degrees.

I think there is something else going on, 183us is a long time. The power supply is pretty important and could cause havoc in the analog circuits (Vref) if not regulated. If you're feelin lucky you can get 5v regulated off your USB port.

We're straying off (probably better to visit the ongoing related thread - http://www.picbasic.co.uk/forum/showthread.php?t=13690), but just to clarify....I'm not even calculating phase wrt to this specific problem (other than on a spreadsheet)...this is more to do with an apparent timing overhead/problem, where once comp1 interrupt has finished, it takes a minimum count of 336 clocks (@20mhz Osc) to store the comp2 timer1 count.

Sequence is...
comp1 interrupts - (timer1 was reset earlier and is therefore is already at zero)
comp1 interrupts again (timer1 value is stored, timer 1 is cleared)
comp2 interrupts - timer1 value is stored into another variable & is used against the above to glean the delay - ie phase shift.(it's this one that won't go below 336 - whatever audio frequency I'm feeding in)


Since comp2 count time won't go below a count of 336 - @ 500hz, that represents the first 12 degrees of phase shift not being 'capturable'. If I take the frequency up to 1.4kz...once again, I cant get the comp2 count down below 336 - but now, this represents something nearer the first 32 degrees of phase shift not being capturable.

It's plausible that the vcc is to blame but in such a scenario, I would have expected the comp1 interrupt count to be all over the place (& comp2's count too!)... I more wonder that when comp2 interrupts if there isn't some delay going on, eg while it parks up some registers (housekeeping) prior to actually doing what's being asked of it in the interrupt handler? I know the pic comparators are firing right (cos I presented the output of both PIC comparators on a physical output pin - they scoped the same as the inputs looked)...so IMHO, this has something to do with the internal PIC proceedings ....or the way I'm approaching this, hence posting my interrupts on the related thread (incidentally, such is the sensitivity of the timings, I'm not able to do much else in those interrupt handlers..else the counts go bananas! It's literally get in, store to a variable , get out asap! I'm only wanting to measure up to 1.4khz...which equates to a waveform cycle period of 700us - a veritable eon in processing time?!)

I guess I'll have to mull learning a little more about assembly?

edit: It couldn't be the hserout bogging the interrupts down could it? That's a fair amount of text being piped down a 9600 line, so I'd imagine there'll be some associated USART registers to store away with each and every frequent interrupt!? (but how else can I see what the timer1 count numbers going on inside the pic are?!)

[retepsnikrep]

This is my first try with DT interrupts to implement a 4hz timer ticks.

I'm probably being a bit thick but do the instant interrupts preserve all the variables and return to exactly the same place in program after execution?

Also i have some serin2 code that i don't want interrupting, i can't find the command that enables/disables the interrupts temporarily?

	SERIN2 Bcm, 8276, 250, Main, [WAIT($87), STR BCM87\11]	'Receive $87 (12) byte data packet on BCM Bus

I don't want the above interrupted. ? Thanks

[Darrel Taylor]

I'm probably being a bit thick but do the instant interrupts preserve all the variables and return to exactly the same place in program after execution?

Yes it does.

Also i have some serin2 code that i don't want interrupting, i can't find the command that enables/disables the interrupts temporarily?

    INTCON.7 = 0
	SERIN2 Bcm, 8276, 250, Main, [WAIT($87), STR BCM87\11]	'Receive $87 (12) byte data packet on BCM Bus
    INTCON.7 = 1

But that will throw off your 4hz timing.

If possible, use the USART with HSERIN, and you won't need to disable anything.

[retepsnikrep]

I think i'll have to go back to something which leaves the timer running in the background i can poll the timer overflow flag and just count 4 ticks myself. Hmm?

Does your intcon just stop/start the timer?

I can't use hserin as chip is 12F683

[Darrel Taylor]

Polling the timer won't help, since it's the time it takes to execute the SERIN2 statement that causes the delay in responding to and reloading the timer. It can't do anything else until that statement is finished, and with a WAIT() in there, who knows how long it will take.

And INTCON.7 is the GIE bit (Global Interrupt Enable).
Setting it to 0 disables ALL interrupts, but does not affect the timer other than delaying the Interrupt Service Routine (ISR), which needs to reload the time to keep it accurate.

Depending on what your 4hz interrupt is doing, ... you may not need to worry about it interrupting the SERIN2. If the ISR is fast enough, it won't cause a problem.