IR Remotes & Microcontrollers - Arduino & ESP32

@zander @davee    Good day , I have run the ir-remote-receive original sketch this morning in a NANO , Esp32, and a Seeduino XIAO that i had handy. Was about to write that I have downloaded my sketch instead of Upload but we can keep this one for a later rainy day , lol.

And here are my results:

NANO seems happy with DigitalWrite and AnalogWrite commands driving the same output.

esp32 and Xiao dont like to have both used, the output stays on, it wont toggle off.

I replaced digitalWrite with analogWrite(LED_PIN,0) for esp32 and Xiao, works .

Note you need to be finger fast but it is the same for the 3 micro i tested.

Ron , will wait for your results . 

tks

@shunt @davee @will @old-plumber It looks like we came to the same conclusion. I tested an genuine UNO, and clone and a DOIT ESP32. Here is the result.

Hi guys,

I am feeling well today and got the test done. The results may surprise you (more than 1 thing tested)

I ripped out all the IR code as it does not play a part in the LED code. I ended up with an almost entirely new sketch.

The RESULTS.

1. The UNO does turn off the Led with a digitalWrite of LOW after some analogueWrites.

2. The ESP32 DOES NOT! Therefore to answer the OP, your results are correct for that board.

HOWEVER there is more, disturbingly a bit more than a bit in fact.

Bonus 1: On the second pass thru the code the digitalWrite HIGH does NOT turn the Led on. This may require more testing but my hunch is that the analogueWrite LOW I added after the digitalWrite LOW may have an influence. I would test again, but I am at the limit of my ability to focus today. Someone else may want to try or y'all can wait until I am up to it.

Bonus 2: The waitForKey behaved strangely. I need to test this on it's own, but you will see what I did in the code. The UNO and esp32 are behaving differently, and the first wait acts differently from the rest. I added a flush at the last minute and that may 'fix' things but I am seeing cross eyed now as it is so this test will have to wait.

I used both a genuine and clone UNO and both behaved the same.

I am going to also post this publicly so everyone can benefit. I will also post the test sketch.

I am left very upset and concerned. My approach is 180 degrees from Dave's, I assume the best, that is everything works as 'advertised' or as I think it does.

Dave's approach is absolutely what is needed in the workplace, but as a hobbyist, I lack the time, education, relevant experience and patience. Now if someone wants to pay me the $200 an hour I was earning back in the oughts plus inflation, I would happily make the effort (just kidding guys, I not only don't want to work that hard, but can't and don't need to)

I am quite certain I got the tests done correctly, but if I did't, just blame it on being 82 in 2 days and having a heart that stops beating quite a few times a day.

#include <Arduino.h>

#define LED_PIN LED_BUILTIN

volatile int lampLevel = 255;

void waitForKey(String Msg){
  Serial.println(Msg);
  while(!Serial.available());
  while(Serial.available()) Serial.read();
  Serial.flush();
}

void setup() {
  Serial.begin(115200);
  while (!Serial.availableForWrite()) {}  // Wait until Serial port is ready for output
  pinMode(LED_PIN, OUTPUT);
  digitalWrite(LED_PIN, LOW);
  waitForKey(" Setup done ");
}

void loop() {
  waitForKey(" Top of loop ");

  Serial.println(" digitalWrite HIGH"); digitalWrite(LED_PIN, HIGH); waitForKey(" "); waitForKey(" Any key 1 ");
  Serial.println(" digitalWrite LOW"); digitalWrite(LED_PIN, LOW); waitForKey(" "); waitForKey(" Any key 2 ");

  for (lampLevel = 200; lampLevel > 140; lampLevel -= 10) {
    Serial.print(" Level: ");
    Serial.println(lampLevel);
    analogWrite(LED_PIN, lampLevel);
    delay(1*1000);
  }
  waitForKey(" "); waitForKey(" Any key 3 ");

  Serial.println(" digitalWrite LOW"); digitalWrite(LED_PIN, LOW); waitForKey(" "); waitForKey(" Any key 4 ");
  Serial.println(" analogueWrite LOW"); analogWrite(LED_PIN, 0); waitForKey(" "); waitForKey(" Any key 5 ");
}

Hi @zander Ron, @shunt @will @old-plumber

  Well done Ron on your investigative work!

  I am not surprised that there is a difference between the Atmel (UNO) processor and the ESP. Equally, I would not have been surprised if they have behaved similarly. To me, both scenarios looked to be roughly equal in probability, assuming the families were designed completely independently.

-------

Ron, perhaps where you and I have different views is in our expectations of what can be 'mixed and matched', without expecting some 'unexpected' behaviour. 

----------------

GPIO pins on a microcontroller are intended to make the device more versatile, by enabling the same pin to be used in different ways. Hence, a single pin may include a selection of (say) any 3 or 4 from:

• Digital output (under direct software control)
• Digital input (under direct software control)
• PWM output
• Serial input
• Serial output
• I2C
• SPI
• Analogue A/D input
• Analogue D/A output

If you look at the physical architecture of the chip, each of these options will often have a little 'private subsystem' to perform the necessary functionality.

I think most chip designers, and probably many software writers who are concerned with writing the associated low-level hardware drivers, will look at each of these as separate functions, and for a given application, assume each pin will be assigned a single role, that it will keep for its entire operating life.

Of course, one can always postulate exception cases in which a pin swaps roles. The most obvious, might be a pin used in a half-duplex arrangement, swapping between digital input and output, but I suggest that this is fairly rare, and in that particular case, probably confined to routing paths around the GPIO pin driver itself.

By contrast, I would look at the analogWrite and digitalWrite as likely to be independent options, using different bits of the microcontroller's circuitry. analogWrite requires a PWM functional block, whilst digitalWrite is a simple software controlled write operation to a register.

Hence, I would not generally expect a programmer to apply them to them both to the same pin, and I would not be surprised to find that the respective libraries have never been tested in a combined usage on the same pin scenario. If you look at the number of different options available, it will be obvious that comprehensive testing of all possibilities would be immensely challenging, and probably of almost no value to most users, who do not need to 'mix and match'.

-------------

Please understand, I am not saying you cannot mix and match, but rather that if you do mix and match, be prepared to thoroughly test the result, and not be surprised if it doesn't behave in the way that you expect, because to me, it seems quite plausible, you are the first person to even attempt to do it, in those particular circumstances!

-----------

It might also be useful to understand why microcontrollers have acquired 3 or more alternate functions per pin, when clearly only one function is ever likely to be used.

Obviously, it increases chip versatility, but more importantly, most of that versatility is at very low additional cost to the chip manufacturer. One of the main cost factors is the silicon surface area required for each functional entity. Each pin requires a relatively large amounts of surface area, not only for the bonding contact pads, but also supplementary things like ESD (electrostatic discharge) protection, etc., as well as an increase in package cost and size, whilst specialised processing blocks like serial data handlers or PWM counters can be very small, and hence almost zero additional cost. So the chip designer will want to minimise the number of pins required, by routing several functions to each pin, and leave the system designer to decide which (single) function will be allocated, to that pin.  

----------

Sorry, this is another sermon, but I hope it helps everyone to see the situation a little more clearly. It is not just considering if something meets an advertised performance, but also appreciating what that advertised performance means, and understanding the practical limitations. That can be really complex and difficult.

As hobbyists, it is easy to try to pretend that complexity is irrelevant, and of course, on a good day, things may work in our favour, but the trade is there will be other occasions, when it catches us out. Hopefully, the consequences on a bad day, will only be a little frustration, whilst we look for a better option.

Take care everyone, and best wishes, Dave

@davee Professionally I understand that. As a hobbyist though I tend to trust that these common basic functions (digitalWrite and analogueWrite) will work the same, especially within the same IDE. What I find even more concerning is the news (in a private conversation from @shunt) that even different boards from Arduino behaved differently.

I do not have the training or experience in these boards to intuitively 'know' what is possible and in fact I would expect the compiler to flag the dual use of a single pin or in this case the built in Led.

As you are no doubt aware, libraries are required to supply a library.properties file that specifies what architectures the library will work on. Just thinking out loud, why then does not a similar facility not exist for the more basic operations? OR, if this is a case of 'ridiculous' use akin to using a pin for both input and output, I sincerely believe the compiler should flag that. I would submit an issue, but since it is two different manufacturers it is probably not possible. I do think it more correctly belongs in the Espressif camp, but I will not be surprised to get a response that says something along the line of it being undefined behaviour.

Now I quite literally am afraid to invest much more of my precious time troubleshooting problems that are not easily resolved as I have no way of knowing without substantial testing if it is another of this kind of problem.

At the very least, in the future if someone is having an issue with one of Bill's or anyone else's sketches on a different hardware platform I will not be inclined to offer my assistance. That pains me greatly, but you know how important not wasting time is to me personally.

@davee @shunt @will Something else I noticed, although since it wasn't my main objective I could be mistaken. The waitForKey function seemed to work differently between the two processors. Also, it worked differently the first time it was invoked versus the subsequent times. I added the flush after a bit and can't be sure if/how that affected things. I will try to do some more testing on that small bit of code later today but I am a bit distracted as I have 4 car/tank kits most with no instructions that I have had for a while and now want to get at least the basic mechanical parts assembled.

@shunt @davee @will @old-plumber Gentlemen, in doing the Digital/Analogue write test I noticed something else. I added a waitForKey function in order to observe various actions on the LED. When the ESP32 was connected it worked perfectly but the UNO most of the time only paused every 2nd time. I rewrote the wait code using the more primitive Serial.read but that changed nothing. See included code.

I also think I saw a 2nd different behaviour between the UNO and ESP32 regarding the dual use pin. I will create another sketch in order to focus on what I think I am seeing. I am still confident it will work differently on the UNO and ESP32.

#include <Arduino.h>

#define LED_PIN LED_BUILTIN

int lampLevel = 255;

void waitForKey(String Msg){
  int incomingByte = 0;

  Serial.print(Msg);
  Serial.flush();
  incomingByte = Serial.read();
  while (-1 == incomingByte) {
    incomingByte = Serial.read();
  }
  while (-1 != incomingByte) {
    incomingByte = Serial.read();
  }
  Serial.println(" done");
  Serial.flush();
}

void setup() {
  Serial.begin(115200);
  while (!Serial.availableForWrite()) {;}  // Wait until Serial port is ready for output
  pinMode(LED_PIN, OUTPUT);
  waitForKey(" pinMode ");
  digitalWrite(LED_PIN, LOW);
  waitForKey(" DW LOW ");
  waitForKey(" Setup Done ");
}

void loop() {
  waitForKey(" Top of loop ");

  digitalWrite(LED_PIN, HIGH); 
  waitForKey(" DWH-Any key 1 ");
  digitalWrite(LED_PIN, LOW); 
  waitForKey(" DWL-Any key 2 ");

  for (lampLevel = 100; lampLevel > 70; lampLevel -= 10) {
    Serial.print(" Level: ");
    Serial.println(lampLevel);
    analogWrite(LED_PIN, lampLevel);
    delay(1*1000);
  }
  waitForKey(" End of loop-Any key 3 ");

  digitalWrite(LED_PIN, LOW); 
  waitForKey(" DWL-Any key 4 ");
  analogWrite(LED_PIN, 0); 
  waitForKey(" AW0-Any key 5 ");
  analogWrite(LED_PIN, 50); 
  waitForKey(" AW50-Any key 6 ");
  digitalWrite(LED_PIN, LOW); 
  waitForKey(" DWL-Any key 7 ");
}

Hello All,

As hinted earlier, I am starting a new post as I cannot find a fix to my question that I can understand.

My new post is in I/O Devices-Sensors-Modules, titled "IR Sender Debounce - Sort Of"

Hope to see you there!

Old Plumber