Instant Interrupts - Revisited

[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.