Zero cross detect - switching audio

[Jerson]

Of course you can 'read' the comparator output internally. I still feel you may be better off using an interrupt on the zero crossing as you might have some misses while polling the register in a code loop.

[cncmachineguy]

Hi Hank, I have to agree with Jerson here, his code suggestion is IMHO a better solution. hanging out in the ISR for .33uS seems a little wastful of the clock cycles available. And if the 1.5K is slower? then you are hanging out for a good while!

[HankMcSpank]

Of course you can 'read' the comparator output internally. I still feel you may be better off using an interrupt on the zero crossing as you might have some misses while polling the register in a code loop.

I guess my reticence to use the comparator interrupt method you describe is that I've absolutely no idea the latency between the comparator flipping to getting into the sub routine & being able to do something (this area for me will always be an enigma...in fact it's probably the largest impediment I'll contnue to face...if I don't know the timing impact of something, then I'll veer away from it!), and what is absolutely key for a 'close to zero cross' is that the moment the comparator flips, my switch control voltage needs to be raised as quickly as PIC-ly possible ....wouldn't a while/wend on the CxOUT bit be the quickest vs a comparator interrupt?

[HankMcSpank]

Hi Hank, I have to agree with Jerson here, his code suggestion is IMHO a better solution. hanging out in the ISR for .33uS seems a little wastful of the clock cycles available. And if the 1.5K is slower? then you are hanging out for a good while!

Hi Bert, for this application, the PIC won't be doing anything else (it's not like my main loop is waiting on the INT_RETURN) ....so once I'm in the interrupt routine, I can actually stay there for yonks (yes, I know everyone says, get in, get out asap......but surely that's for when your main is wating on the int_return?)

My *main* overpowering requirement here is that once the comparator flips, that I can raise the audio Switch IC control voltage as PICly ;-) as possible ....if you all think that a comparator interrupt will facilitate this quicker say vs a while/wend on the comparator output while inside a Switch derived IOC interrupt routine, then cool...I'll roll with it! (but in my noobesque, head, I'd always took it that there's a certain overhead getting out of the main loop & into an interrupt routine)

[cncmachineguy]

I don't remember off hand what the answer is, but DT_INT ASM type takes only a few cycles (I think) to get in. Or get in there the actual ASM way. But, no problem waiting around either. If you have nothing else you need to do.

Just saw your edit, If your main is really doing nothing, skip the ISR all together and just wait in main for the switch press.

[HankMcSpank]

Just saw your edit, If your main is really doing nothing, skip the ISR all together and just wait in main for the switch press.

ok, perhaps what I should have said(!), is that when the switch is pressed, it will supercede everything else that might/might not be going on in the (low priority stuff) main ...therefore once in the Switch IOC interrupt happens, I can hang out in the interrupt routine for as long as needs be! (the main will just have to wait!)

I don't remember off hand what the answer is, but DT_INT ASM type takes only a few cycles (I think) to get in.

As mentioned, I have no way of gauging this (I'm in "I think" territory too!), so when I seek something as time critical as catching a near zero cross, to my mind, I reckon it's better to be in there already & tracking the comparator output with a while/wend, then outside not knowing how long it'll take to get in!

[cncmachineguy]

Then I will have to agree with you. Now you could do it in reverse, on EVERY ZC, call ISR, Check for switch pressed or released, if it is, turn on thingy, of not leave.
Or use the ZC as the timing for main.

while not ZC :WEND
switch pressed do stuff
released do other stuff
continue to twiddle bits, flash LED's, whatever
goto main

As long as main takes less then 333uS (for a 1.5K period) you will never miss a beat, and I don't think you can get any faster

[HankMcSpank]

Hi Bert,

Apologies for the delay in coming back..... I don't really want to trigger an interrupt on every zero cross, as that will bog things down (there'll be heaps of them)...even though my main isn't doing much...it may get bigger & I'm still reeling from a similar thing with cap touch interrupts (basically to have a cap touch sensor feel 'zippy' you've got to generate a lot of interrupts ....I found to my cost how having a fairly modest interrupt rate quickly brought my main loop to its knees!)

I'd rather not go with the zero cross/switch close detect in the main loop, because as mentioned, it's not doing much at the moment...but I'm a terrible one for lobbing things into my main & making it bloaty in short order ...at least an interrupt will get priority no matter I may/may not do in my main!

Many thanks for everyone's input.