Can't get an IR receiver and remote to work properly using the IRremote library

Other Hardware Sensors
21 
void readIR(void) {
  decode_results results;

  int ret = 0;
  while (ret == 0) {
    irrecv.decode(&results);
    if (results.value == 0xFFB04F) {
      ret = 1;
    }
    irrecv.resume();
  }
  delay(100);
}
22

That fixed it. Thank you!! It’s weird though, I could have sworn I tried exactly this already…

23

To fix your problems, you must test parts of your sketch. You kept including your sketch which you defended as "correct." Learn to suspect your own code.

24

How do you know that the data type of results.value is 32-bit as it is being compared with an operand > 16 bit?

25

Why would you have to know that to write this ?
(Promotions rules will kick in as necessary)

To your question, you just need to look into the source code to find the answer.

26

To know if OP suspects his codes?

27

In C++ if you compare a 16 bit variable with a 32 bit variable then the 16 bit variable is promoted to 32 bit before the comparison..

28

How are the upper 8-bit populated -- by the MSBit of the 24-bit operand
(0xFFB04F) or by 0s?

29

A better alternative to "my code is perfect."

30

When a 16 bit and a 32 bit integers are compared, the usual integer promotions and arithmetic conversions are applied so depending on the signed or unsigned type you get zero padding or signed extension .

31

You mean --
===> depending on signed or unsigned or signed type you get zero padding or signed extension.

Library codes of post #25 show: uint32_t value;. Acordingly ---
===> 0xFFB04F
===> 0x00FFB04F

Am I correct?

32

Yes if you want it to be respective to the same order in the sentence

Signed ➜ sign extension
Unsigned ➜ zero padding

Also remember that when an operation happens between signed and unsigned - unsigned wins so a signedness conversion can happen under the hood too.

33

That is a precise answer. I appreciate it!

34

In C++, a hexadecimal literal like 0xFFB04F without a suffix is never inherently negative; it is always considered a positive integer value for the purposes of type selection and has a type determined by its value and the rules for integer literals.

By the standard, hexadecimal integer literals without a suffix are given the first of these types in which the value fits: int, unsigned int, long int, unsigned long int, long long int, unsigned long long int.

0xFFB04F is a positive integer that fits in 32 bits but not in 16 bits. So on an Uno, 0xFFB04F has type long (signed 32-bit). On an ESP32, int is already 32-bit, so the literal fits in int.

So the memory representation does indeed have zeros in front - regardless of the comparison with a uint32_t

35

I only told him where to place the .resume() statement for it to work; I didn't review all the code.

36

In fact, my question in #24 was directed to OP and NOT to @MaximoEsfuerzo. Sorry for the confusion.