DT_INT Vs ASM - Round 1

[Megahertz]

Hello everyone. I am trying to make an AC dimmer. Upto now I had a program in which the interrupt routine was written in assembly language. I am trying to change it to work with DT_INT's. To do that, I would like to understand it 100% to be able to conclude my next step in this process. Firstly, please have a look to the ISR code below in assembly:

; context save
T0Overflow
        bcf     INTCON, T0IF    ; clear the timer overflow flag
        movlw   158
        addwf   TMR0
        
        incf    _DimrWork       ; advance the timer

        ; check if channel value is crossed
        movf    _DimmerVal,w
        subwf   _DimrWork,w
        btfsc   STATUS,C
        bsf     _Dimr1

        goto    EndInt

ZeroCrossingInt
        bcf     INTCON, INTF    ; clear the interrupt
        clrf    _DimrWork       ; Dimmer Working variable
        bcf	_Dimr1
;context restore

So this is what I have understood upto now:
The timer0 prescaler is 1:8, so after 97 counts this timer runs out which means around after 750uS. This micro also receives signal from a noisy rf receiver @2400 baud where the first 3 bytes are the qualifiers bytes and then one more byte of data. I understand that (1/2400) * 8*4 = 14mS appx for the complete transmission. Now at interrupts happening @750uS - MY FIRST QUESTION is HOW is this micro able to receive the full transmission? this is baffling me a lot.
Zero-Detection is provided using 2 zener diodes and a high value resistance direct from the AC.

[HenrikOlsson]

You don't say what PIC it is, you don't to say to which pin the serial data input is connected and you don't say at what frequency the oscillator is running but I'm guessing from your calculations that it's 4MHz...

If you preload the TMR0 with 158 it will interrupt after 98 ticks because it interrupts on overflow from 255 to 0. With a prescaler of 1:8 and running at 4MHz that would be 98*8=784us + the time it actually takes to reload the timer.

As for the serial input I'm going to guess that the PIC has a USART which is taking care of that part.
Finally, there's actually atleast 10 bits to each byte transmitted, 1 startbit, 8 databits and 1 stopbit. So 1/2400*10*4=16.67ms.

/Henrik.

[Megahertz]

Yes, of course, that information is important as well. The PIC is 16F676, does not have a USART, OSC @ 4MHz, data coming at PortA.3.
I want to understand at that rate of interrupts, how is the transmission not getting messed up?

[HenrikOlsson]

Can you post the code so we can see how the serial input is handled? SERIN? DEBUGIN? Some custom bit banged rotuine?

[speculating]
That ASM interrupt is pretty short and quick, I count ~14 cycles. (14us @ 4MHz) or something.
"Stealing" 14us every 784us is around 1.8% of the available processing power. Yes, context save and restore adds to that.
At 2400baud each bit is 416us, perhaps the error is small enough for it to not cause any trouble.
[/speculating]

Switching to DT-Ints with the ISR written in PBP will in this case add A LOT of cycles to the interrupt processing due the overhead of saving and restoring all the PBP system variables.

/Henrik.

[Megahertz]

Can you post the code so we can see how the serial input is handled? SERIN? DEBUGIN? Some custom bit banged rotuine?

[speculating]
That ASM interrupt is pretty short and quick, I count ~14 cycles. (14us @ 4MHz) or something.
"Stealing" 14us every 784us is around 1.8% of the available processing power. Yes, context save and restore adds to that.
At 2400baud each bit is 416us, perhaps the error is small enough for it to not cause any trouble.
[/speculating]

Switching to DT-Ints with the ISR written in PBP will in this case add A LOT of cycles to the interrupt processing due the overhead of saving and restoring all the PBP system variables.

/Henrik.

How many cycles it would add with DT_INT, any approximate idea? The code uses SERIN PortA.3, N2400,["abc"],byte_recv, where byte_recv is a byte type variable. Do you think the solution could be to use a higher oscillator. Lets say @ 8MHz! What do you think?

[HenrikOlsson]

When in doubt, measure - so I did.

Here's the testcode I used:

INCLUDE "DT_INTS-18.bas"
INCLUDE "ReEnterPBP-18.bas"

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

@ INT_ENABLE  INT0_INT      ; enable Timer 1 interrupts

TRISB = %00000001  'PortB.0 input

Main:
  PortB.7 = 0   ' Turn off output
Goto Main

TimezUp:
  PortB.7 = 1
@ INT_RETURN

I'm feeding pulses into PortB.0 which trips an interrupt. The interrupt routine sets PortB.7 high so the time between the rising edge of input and output is the interrupt latency. I captured the result with the scope:

The bottom trace is the inout signal triggering the interrupt, the upper trace is output of PortB.7.
The time difference is ~7.4us which is around 120 cycles since my PIC is running at 64MHz. Then you'll have an equal amount of time to restore all the variables when returning from the interrupt which the width of the pulse in the upper trace shows.

/Henrik.