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?


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.


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?


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.


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:
6830
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.

[Megahertz]

Thanks Henrik. This explains a lot. I do not have an any device currently with me so I could not measure it at the moment.
Few things come to mind - What is the actual acceptable delay/error @ 2400 baud? Is it upto 20uS - 40uS that the transmission will not be affected? This would help, as I may use an higher oscillator, lets say 20MHz and bring down the latency if possible. Secondly, DT_INT also has assembly routine type interrupts, could you please check those for me, what is the latency there. If the way exists and all fits in, I would like to make this work using DT INT only without adding another PIC to handle the RF part.

[HenrikOlsson]

Hi,
Simply changing the interrupt declaration from type PBP to ASM makes the latency go from 7.4us to 2.7us (around 40 cycles) with the code in my previous post.
However, if you're going to use assembly interrupts I don't really see the need for DT-Ints. You can not use PBP statements in an interrupt routine declared as ASM (well it IS possible but it's very easy to screw things up and really not recommended).

I don't know what an acceptable error at 2400baud is OR how the bitbanged serial routines in PBP works when being interrupted like that. Apparently it does seem to work the way you currently have it. I guess one way for you to find out is to try.

/Henrik.