Is there a faster way to compare?

[tenaja]

Russ,
I am sure there are other ways to get the pwm you need (such as interrupts), since this method takes up a HUGE amount of cpu time. However, if that doesn't matter and you just need a bit more speed, consider asm.

I compiled your snippet with PBP, and it used up 57 words of program space on a 16F. Proton+ did the same code in 36 words; almost 2/3 the size. PBP's asm file is nearly unreadable, so I can't compare them, but here is the Proton output from a single basic line for both 16F and 18F:

16F...
[TEST.BAS] IF INDEX>A THEN PORTA.1=1
MOVF INDEX,W
SUBWF _A,W
BTFSC STATUS,0
GOTO BC@LL4 'go to the next line...
BSF PORTA,1

18F...
[TEST.BAS] IF INDEX>B THEN PORTA.1=1
MOVF INDEX,W,0
CPFSLT _B,0
F@JUMP BC@LL6 'go to the next line...
BSF PORTA,1,0

[RussMartin]

Thanks for the suggestion, Darrel; I'll try it, expanding to add PIN5 and value E.

Thanks for the comparison, tenaja.

Although now I wonder if I'm looking for the wrong problem. Using the o'scope, I see that each of those IF . . . THENs actually takes only about 22us; that's only 110us for all 5. Maybe it's the FOR . . . NEXT. Each time I added an IF . . . THEN, I had to reduce SOMETHING and rescale each of however many variables I was comparing.

[Darrel Taylor]

... Using the o'scope, I see that each of those IF . . . THENs actually takes only about 22us; that's only 110us for all 5. ...

That's 110us * SOMETHING (the loop count).

If SOMETHING is ever higher than 63, you will have used up the 7ms and more.

With the ASM code I gave, each IF takes only 2us @8mhz.
SOMETHING can be 255 and it will still only take ~2.6ms.

hth,

[RussMartin]

Yes, I knew about the <b>* SOMETHING</B> !

But now I have the opposite problem . . . since yours is so much faster, I would need to run it almost three times (because the variables can range from 0 to whatever SOMETHING is scaled to). Should I just run it three times in succession, or do I need to go to a WORD variable for SOMETHING? (I need to scale SOMETHING through as much of that time span as possible.)

[Darrel Taylor]

since yours is so much faster, I would need to run it almost three times (because the variables can range from 0 to whatever SOMETHING is scaled to).

Totally Lost me on that one.
<br>

[RussMartin]

Okay, let me background this first.

For each of 5 channels: A 0-5V value is read (derived from an op-amp) by an ADC channel (presently at 10 bits, so 0-1023). That value is manipulated depending on other data (an offset or a correction, for example). The complementary value (1023-value), scaled so that 0 (1023-1023) can be managed in x repetitions (the maximum that can be fit into about 7.8ms) of the loop, is how long the delay in the interrupt handler must be before turning on the corresponding output pin to a triac driver. Normally, a 5us pulse would be adequate to keep the triac on until the end of the AC phase, but the indicator for the channel is an LED, so the pin is left high until the end of the phase.

Just sending a pulse on a pin means running the FOR . . . NEXT loop only up to the scaled value and sending the pulse; keeping the indicator on proportionately (well, somewhat) means the pin must stay high until near the end of the phase.

Your code running to 255 and finishing in 2.6ms means that only 36 percent of the 7.8ms period is controlled, because it is so fast. Proportionately, the phase would have to be scaled something like 0-765, probably a little less.

Could I just run additional cycles of the tests before incrementing the INDEX to stretch it out?

The code works as is, but over a very limited signal range.

[Ioannis]

I have not tested the idea.

Instead of writing each IF-THEN test to the port, writing to a variable and at the end that variable to the port will be faster?

Ioannis