Does variable value change being transferred to code running in interrupt loop?

[CuriousOne]

Hello.

Say I have some code, the "main" code and the interrupt driven looped code.

The interrupt driven code flashes the led according to variable value changed in main code. Is this possible? will it work that way?

[Heckler]

As long as the variable used in your INT for LED timing is the same variable as referenced and adjusted in your main code loop it should work.

You will learn more by knocking it up on a breadboard to test your theory (At least I would learn more)

[Art]

Yes it’s the same variable, things can only go wrong if you don’t do your business in enough time for the next interrupt.
The interrupt gets called more often than your code expects, or something like that, then things can run away from you.

Essentially though, the interrupt code isn’t special, don’t think of that part of the program in interrupt land.
It’s just a part of the same program that gets called under certain event driven circumstances and that’s all.
If you want to share any variable between the ISR and main program you will probably have to declare it in the include file,
or in your main program before you inserted the include line. The only reason you have to save and restore w & status
(assembler interrupt) is because your main program doesn’t know when the interrupt will happen.. or you wouldn’t need one

[CuriousOne]

Here is the code how I want to use it. The code shown is one included in interrupt:

SOFTPWM:
IF A=1 THEN
HIGH LED1
PAUSE 100
LOW LED1
PAUSE 100
ENDIF

IF B=1 THEN
HIGH LED2
PAUSE 100
LOW LED2
PAUSE 100
ENDIF

IF C=1 THEN
HIGH LED3
PAUSE 100
LOW LED3
PAUSE 100
ENDIF

IF A>1 THEN
HIGH LED1
PAUSE 100
LOW LED1
PAUSE 100
ENDIF

IF B>1 THEN
HIGH LED2
PAUSE 100
LOW LED2
PAUSE 100
ENDIF

IF C>1 THEN
HIGH LED3
PAUSE 100
LOW LED3
PAUSE 100
ENDIF

IF A>2 THEN
HIGH LED1
PAUSE 100
LOW LED1
PAUSE 100
ENDIF

IF B>2 THEN
HIGH LED2
PAUSE 100
LOW LED2
PAUSE 100
ENDIF

IF C>2 THEN
HIGH LED3
PAUSE 100
LOW LED3
PAUSE 100
ENDIF

GOTO SOFTPWM

The idea is to realize multichannel software PWM using interrupt. The PAUSE values are just for illustration purposes.

This is just short code, to illustrate how I want to do it.

If A=1 then led only will be lit 1/3 of total time, approx. 33% of duty cycle
If A=2 then led only will be lit 2/3 of total time, approx. 66% of duty cycle

and so on, for other leds. This code allows to have different leds at different duty cycle in one loop. Total there will be 16 leds and 16 duty cycle levels. The meaning of A/B/C variables will be changed externally, outside this loop, so that was the question, will it "sense" variable value change.

[HenrikOlsson]

Hi,
In PBP all variables are global, meaning they are always "in scope" and can be accessed by anything/everything at any time/all the time so the answer to your question is yes.

Pay special attention to what Art said, the total execution time of the interrupt code can not be allowed to be MORE than the time between interrupts. If you have a timer tripping an interrupt at 100Hz then the total execution time of the code in the interrupt service routine can not be more than 10ms. If it is then your main code will not run.

You'll see comments about never doing any "real work" in the interrupt code, quick in, quick out, set flags etc or you'll set the world on fire. These are generally good advice but there's absolutely no problems with spending 90% of your time in the ISR and 10% in the main code as long as you understand what that does to your code. A PAUSE 100 in the main code will pretty much turn into a PAUSE 900 due to the interrupt service routine "absorbing" 90% of the CPU power without the rest of the system knowing about it. The same goes for all the software times commands like SERIN, COUNT, PWM, DEBUG etc etc - as long you understand that and you're OK with it then no problem.

/Henrik.

[CuriousOne]

Well, that PAUSE 100 was provided just as filler - at such rate, leds going to blink rapidly. I believe, PAUSEUS 100 would be much better, but PBP PAUSEUS accuracy is far from desired.