Toggle led and turn off another

[longpole001]

hi guys , not sure why this happens can someone advise

problem - RGB LED has 3 outputs from Pic connected to it and assigned variables , PWR_LOWLED(red) , PWR_LED (blue),OK_LED(green)

In the follow code , all works ok as expected , the PWR_LOWLED , is toggled , the PWR_LED is turned off

 if T0Count1 = Flash_rate  and IR_RX_PWR_Low = 1 then 
        toggle PWR_LOWLED                   ' Flash PWR_LOWLED 
        pwr_led =0                           ' turn off PWR_LED
        T0Count1=0                          ' clear counter 
     endif

However in this code when i put the command to turn off the PWR_LED = 0 before the toggle PWR_LOWLED command , the PWR_LED remains on , and i dont see why it is the case

any advise on why


Regards

Sheldon

 if T0Count1 = Flash_rate  and IR_RX_PWR_Low = 1 then 
         pwr_led =0                          ' turn off PWR_LED
        toggle PWR_LOWLED                   ' Flash PWR_LOWLED 
       T0Count1=0                          ' clear counter 
     endif

[Amoque]

It is difficult to say exactly without seeing/ knowing what pins are represented by which variable names, but some general info:

HIGH [PIN] will always set the pin represented to +5V if configured as output. As will [PIN] = 1
LOW [PIN] will always, similarly, set the pin to ground. [PIN] = 0, the same.

TOGGLE [PIN] will reverse the state - if the pin was HIGH, TOGGLE will make it LOW; if LOW, it becomes HIGH. It is likely, looking at this explanation, that if your output is ending in the wrong state, it is because it began in the wrong state.

Your comment "when i put the command to turn off the PWR_LED = 0 before the toggle PWR_LOWLED command , the PWR_LED remains on" indicates you:

Turn Off PWR_LED
Then TOGGLE the pin, thus turning it from LOW to HIGH.

You state "the PWR_LED remains on". Which, would appear to agree with what I understand you to say, but is not correct. TOGGLE simply makes the pin HIGH again immediately after turning it off and so, it appears to remain on. Try putting a pause between the statements to verify my assumption, so that you may observe PWR_LED being turned off, then [PAUSE], then TOGGLE reversing the pin output and turning the LED on again.

[longpole001]

RGB LED has 3 outputs from Pic connected to it and assigned variables , PWR_LOWLED(red) , PWR_LED (blue),OK_LED(green

You state "the PWR_LED remains on". Which, would appear to agree with what I understand you to say, but is not correct. TOGGLE simply makes the pin HIGH again immediately after turning it off and so, it appears to remain on. Try putting a pause between the statements to verify my assumption, so that you may observe PWR_LED being turned off, then [PAUSE], then TOGGLE reversing the pin output and turning the LED on again.

1. colors are different so i would see if the " PWR_LED= 0" command worked or not
2. the toggle is changing the " PWR_LOWLED " ( red) only, not the other colors
3. pause had no effect ,
4. the PWR_LED is on before getting to this part of the code
5. if the " toggle PWR_LOWLED " (red) is placed after the command "PWR_LED =0" ( blue ) then the blue led remians on , with the red flashing
6. if the command "PWR_LED =0" ( blue ) is placed after " toggle PWR_LOWLED " (red) then the blue led is off , with the red flashing

is not a biggy and its works ok when done in the sequence described , just cant see why

[Amoque]

Ok, I think I get it. Doesn't help me to explain it, but I get it.

I do not see anything in the code snippets to explain this so, I think it must be a hardware anomaly. Darrel once mentioned to me that output pins are first read before set and that setting individual pins(PORTA.1=1 : PORTA.2=1 : ...) is less desirable than the style of PORTA = %00000110, or that a brief PAUSE between may be necessary between statements to allow for this. I don't claim that this is happening in your code, only that their are some issues and limitations beyond the obvious. Sadly, I am not advanced enough in knowledge or equipment to troubleshoot at that level... Perhaps someone with more of one or the other will happen by.

Wish I'd been more help...

[HenrikOlsson]

That is called Read-Modify-Write or RMW for short. It was my first thought when I read the thread earlier but since a PAUSE between the two statements did't help it sounded less likely - not that I know what else it would be.....

On a PIC ALL "bit flipping" are performed as a Read-Modify-Write operation - it's how the hardware works internally.
So, when you do PortB.0 = 1 the PortB register is read to a working register in the PIC (Read), bit 0 is set (Modify), the working register is written back to PortB (Write). This has nothing to do with PBP it's how the hardware works and it's basically what's happening during the 4 internal cycles of the oscillator which makes up for a full instruction cycle.

Now lets look at what CAN happen with something like

PortB.0 = 1
PortB.1 = 0

The first operation, by it's own, works as expected. But when the second line was added the first one stopped working. What's happening is that whatever is connected to PortB.0 prevents the voltage at the pin to rise quick enough so by the time the second operation performs the Read-part of the RMW PortB.0 is still at a logig LOW level so that's what is being read. When the Write-part of the RMW is performed a logic LOW will then be written to PortB.0.

Inserting a PAUSE between the two lines allows the voltage to rise to level where the second operation works properly.

If the device in question has LAT-register then using those instead totaly circumvents the issue. TOGGLE however won't work on LAT as far as I know.

Now, TOGGLE pwr_lowled is a high level commad, it takes longer time to execute than pwr_led = 0 which would explain why it matters in which order you put them. But again, a PAUSE in between the two instruction should have "fixed" it - which it supposedly didn't.

Make sure you're not trying to pull more current thru the pin that it's rated for. Always use current limiting resistors when driving leds - always. Not doing it CAN work but it's just BAD practice - really bad practice.

/Henrik.

[longpole001]

thanks guys , for that great information . i am very greatfull ,
i did set the port using %00000010 and it sorted the issue , strange why the pause did not as i think that that was the prob


Now for the next problem - silicon bug issues with ADC and ADCIN command , how to get arround it
next topic


cheers

Sheldon