logo elektroda
logo elektroda
X
logo elektroda

Why does my if(led1==1) statement get skipped and else executed in LED display code?

291 16
Best answers

Why does `if(led1==1)` evaluate false in my 8051 Keil C LED code after I set `led1 = 1`, and how can I test the port bit correctly?

The `if` is probably not wrong by itself; `led1` is a port bit, so writing `led1 = 1` does not guarantee that reading `led1` back will still be 1 if the pin is configured or wired in a way that forces the actual pin level low [#21668190][#21668201] On an 8051, a memory-mapped I/O bit may not latch the written value in a way you can compare directly, and other port bits or the pin configuration can affect the readback [#21668201] Try isolating the bit before comparing it, for example `if ((led1 & 1) == 1)` or by copying it to an `int` first and testing that [#21668198] It was also suggested to look at the generated `.LST`/assembly file to see what the compiler is actually doing [#21668198]
Generated by the language model.
ADVERTISEMENT
  • #1 21668185
    Usman Saleem
    Anonymous  
  • ADVERTISEMENT
  • #2 21668186
    Steve Lawson
    Anonymous  
  • #3 21668187
    Mark Harrington
    Anonymous  
  • ADVERTISEMENT
  • #4 21668188
    Bob Loy
    Anonymous  
  • #5 21668189
    AB Ahmad
    Anonymous  
  • #6 21668190
    Steve Lawson
    Anonymous  
  • ADVERTISEMENT
  • #7 21668191
    Usman Saleem
    Anonymous  
  • #8 21668192
    Steve Lawson
    Anonymous  
  • #9 21668193
    Usman Saleem
    Anonymous  
  • #10 21668194
    Steve Lawson
    Anonymous  
  • ADVERTISEMENT
  • #11 21668195
    Steve Lawson
    Anonymous  
  • #12 21668196
    Usman Saleem
    Anonymous  
  • #13 21668197
    Usman Saleem
    Anonymous  
  • #14 21668198
    Pieter Kruger
    Anonymous  
  • #16 21668200
    Steve Lawson
    Anonymous  
  • #17 21668201
    george gonzalez
    Anonymous  

Topic summary

✨ The discussion addresses a problem in C code for an 8051 microcontroller using Keil uVision, where an if statement checking if a bit-addressed LED pin (led1) equals 1 is unexpectedly skipped, causing the else block to execute instead. The led1 variable is defined as a single bit (sbit) mapped to P3.0, representing an LED connected to pin 1.1. Despite assigning led1=1, the if condition (if(led1==1)) does not behave as expected. Possible causes include the nature of bit-addressed I/O pins on the 8051, where writing to a port bit may not be reliably read back due to hardware configuration or the difference between PORT and LAT registers in some microcontrollers. Suggestions include masking the bit with a bitwise AND (if((led1 & 1) == 1)) or assigning led1 to an integer variable before comparison to handle integer promotion issues. The importance of posting complete, properly formatted code and verifying LCD initialization and display routines was emphasized. Reviewing the generated assembly (.LST) file to understand compiler behavior on bit variables was recommended. The problem likely stems from reading a hardware port bit that does not reflect the written value, common in memory-mapped I/O on 8051 devices.
Generated by the language model.

FAQ

TL;DR: With 9 LEDs connected, the common fix is: "try (led1 & 1) == 1" or cast led1 to int before testing. This avoids type/bit-read surprises in if() and makes your LCD branch execute as expected. [Elektroda, Pieter Kruger, post #21668198]

Why it matters: This FAQ helps 8051/Keil C users quickly diagnose why a true bit condition still falls into else and how to display the right message on LCDs.

Quick Facts

Why does if(led1==1) skip and go to else on an 8051?

Because led1 is a single bit tied to a port, comparing it directly can be unreliable for logic checks. Mask the bit or assign it to an int first. Example: if ((led1 & 1) == 1) { ... }. This avoids integer-promotion and bit-read quirks. “Try (led1 & 1) == 1.” [Elektroda, Pieter Kruger, post #21668198]

How should I correctly test an sbit like led1 in C?

Two robust patterns: 1) if ((led1 & 1) == 1) { ... } or 2) int i = led1; if (i == 1) { ... }. Both make the intent explicit and keep comparisons stable across compilers. [Elektroda, Pieter Kruger, post #21668198]

Could the read of led1 ignore my previous write?

Yes. Memory‑mapped I/O may not latch writes for readback, and mixed-direction bits can leak unexpected values into the read. Mask the lowest bit and test that. [Elektroda, george gonzalez, post #21668201]

Nothing shows on my LCD—does that prove the if() didn’t run?

No. It can also mean LCD init or the print routine is wrong. Confirm initialization, then add a known test print before the if(). That distinguishes display issues from logic flow. [Elektroda, Steve Lawson, post #21668192]

What does sbit led1 = P3^0 mean in Keil C for 8051?

It maps led1 to bit 0 of port P3, letting you read or set that single pin directly. The code example defines led1, led2, and led3 this way. [Elektroda, Usman Saleem, post #21668196]

Is spacing like led1 = 1; and if (led1 == 1) important?

Functionally, no—but it improves clarity and helps weaker toolchains. Write spaces around operators to avoid misreads and ease debugging. [Elektroda, Bob Loy, post #21668188]

Should I reinstall the compiler to fix this?

Reinstalling can help if toolchain files are corrupted or mismatched. However, first confirm code logic with masking/casting and minimal examples. [Elektroda, Mark Harrington, post #21668187]

I use PICs too—could a PORT vs LAT mix cause similar behavior?

Yes. On some PICs, reading PORT vs writing LAT can confuse readbacks. Similar aliasing mistakes lead to misleading if() results. Edge case, but real. [Elektroda, Steve Lawson, post #21668190]

How do I verify what the Keil compiler actually generated?

Build with list output (.LST) and inspect the assembly. You’ll see how led1 is read and compared. This often reveals promotion or bit-masking details. [Elektroda, Pieter Kruger, post #21668198]

Can mixed input/output configuration on a port bit affect my check?

Yes. If other bits behave as inputs, you can read stray states when sampling the port. Mask the target bit before comparing. [Elektroda, george gonzalez, post #21668201]

What’s the minimal reproducible example for this LED/LCD issue?

Define sbit led1=P3^0; set led1=1; then test using (led1 & 1)==1 and print a short LCD string on true/false. Keep initialization obvious. [Elektroda, Usman Saleem, post #21668196]

How do I format and share code on forums so helpers can parse it fast?

Use code tags and include full but minimal listings. Add comments about hardware pins and what each line should do. It speeds diagnosis. [Elektroda, Steve Lawson, post #21668194]

Do I need extra delays before reading or printing to LCD?

Yes, brief delays appear in the thread code before LCD ops. Keep short, then confirm with a known string. Excess delays slow response. [Elektroda, Usman Saleem, post #21668193]

How many LEDs were driven in the example, and does scale matter?

Nine LEDs were connected; the failing check was on the first. Scale matters when power and port loading increase and timing tightens. [Elektroda, Usman Saleem, post #21668191]

Quick 3‑step: how do I make the if() branch reliably on led1?

  1. Assign led1 to an int: int i = led1. 2. Or mask: if ((led1 & 1) == 1). 3. Print a test string before and inside the branch to confirm flow. [Elektroda, Pieter Kruger, post #21668198]
Generated by the language model.
ADVERTISEMENT