If you buy an ESP32 that is on a board like the NodeMCU, they have a low dropout regulator onboard that can handle 5v (I think up to 7-8v but not 12). This is how they run off the USB power supply, and they have a Vin pin that is tied to the same trace.
I usually drive all my outputs active low which lets you drop in any micro regardless of voltage. It's also pretty easy to handle input voltage differences a couple of ways:
- voltage dividers
- zener clamping (most robust)
- large input resistors, 1M+ and just using the internal clamping diodes - not many devices are actually intolerant of voltage alone, it's current that does the destroying
Porting is a bigger problem. An ESP device is more like a tiny computer than traditional Arduino microcontrollers.
The thing about the ESP series is that when you run Arduino code on them it's actually running on their internal RTOS as a process - this can mess up timings when you are trying to bit bang things such as IR and it switches threads. ESPs will switch threads any time you call delay() which really messed me up when I first started using them - in fact, to have the built-in wireless libraries work properly on an ESP8266 you have to regularly call delay() in your main loop so that it has some time to work. I would guess this is the reason that the PWM/IR libraries don't support it.
Once you get used to it you start using the multithreaded RTOS all the time for handling things that used to require counting millis() or using interrupts. For example a 1 second slow PWM output for a heater can just run in its own thread, reading a global and sleeping with delay() between state changes. So easy!
ESP32 has its own hardware support for IR communications, though I've never looked into it. It probably just handles some standard protocols or is a UART in disguise.
There is a way to lock a process to a specific core at realtime priority, xTaskCreatePinnedToCore. This is where the ESP32 shines over the ESP8266, because you can set one core to run a single thread in realtime doing your bit bangs while the other stuff gets scheduled on the second core. You can pass values back and forth through global variables. So you never have to worry about finding time in your loops for running serial I/O, wireless or other slow logic. I suspect this would be the way to get the IR protocol to work on these units.
