So, I tried Infrared (IRremote.h) receiving on ESP32 with FastLED.
As expected, @Yves_BAZIN 's library does not support this because it requires turning off interrupts. His code will not even compile if FASTLED_ALLOW_INTERRUPTS is set to 1
The good news is that @Sam_Guyer 's code since it uses RMT, doesn’t need interrupts to be turned off.
The other good news it that the ESP32 code in IRRemote does not use RMT because I wrote it, and I didn’t have the time to figure out how to make RMT work, so it uses silly interrupts and just reads a pin. Little did I know that my laziness would save me later by allowing this to work using interrupts without RMT while RMT is being fully used to output to 8 lines of fastled at a time.
I also did a quick timing test and with @Sam_Guyer 's FastLED ESP32 driver, I still get 55fps for 4096 LEDs, which is more than enough.
Anyway, just reporting back that 8 way parallel output plus interrupt driven IRRemote works fine on ESP32
Come to think of it, I think an RMT based IR driver + @Yves_BAZIN interrupt driven 16 line parallel output, might work too, but I don’t have one I can try with, nor do I really need one for now.
Not sure if you’re married to infrared or not (or what the end use application is) but I know @Leon_Yuhanov does amazing work networking esp8266’s on an adhoc WiFi connection using the espnow protocol. I haven’t had a chance to play with it at all, and at this point it’s a project for next year, but might be worth looking into if you’re looking to build a remote control for your costume. I think Leon makes a controller with an esp chip in it that works as a master, and then the other chips work as slaves and receive the data from the master
@chad_steinglass I already have all my code working with an IR remote. I could make it work with my phone, but
I care less about handing a remote to someone and or breaking/losing it
if I rely on my phone, I have my phone in that weird state where it must be connected to a wifi AP that goes nowhere while remaining on cell to actually do its primary function. It’s possible but kind of iffy.
That’s the remote, lots of buttons and costs maybe $2, if not $1
I’ll admit that IR receiving adds some complexity, but I already have the code, the driver just works on ESP8266 and I made it work last year on ESP32, so the incentive to switch is low.
Wifi would be nice for a more complex interface and a better UI than me remembering what each button does
(also I’m up to 54 demos now, so that’s a bit more than I have buttons) missing/deleted image from Google+
@Marc_MERLIN You are corect, cant beat a $2 IR remote on price! If your keen have a look here https://github.com/leonyuhanov/ESP-NOW-TX-RX its a bootstrap for the espnow protocol for the esp8266 and esp32 if you want to do more complex stuff. No phone required.
Nice! FYI: There is a way to use my FastLED driver with the built-in RMT driver for other IR applications. You just need to add a #define before including FastLED.h. It has some limitations, though, and it does use more memory.
@Sam_Guyer so you’re saying that RMT can be used both for outputting with your driver, and then it can also be used for IR input? The problem I have with IR input is that you have to be listening all the time or you may miss part of a message.
Or does RMT have separate and concurrent channels for input and output?
@Marc_MERLIN Yes, sort of. Here’s the deal: the RMT device itself has 8 channels that can be used for input OR output – the software determines how each channel is configured. My default driver takes over all of the software and uses all of the channels for FastLED. I have a switch you can set that uses the same strategy, but with the ESP32 Core RMT driver, which also has support for IR input.
What’s cool about the RMT device is that IT will listen all the time, and then send an interrupt when it gets the data. The Core driver just waits for this interrupt, then invokes a callback (I think) to your handler with the data.
The way to use it with FastLED is to use the #define above, limit the number of channels to no more than 7, then use the 8th channel for IR input.
@Sam_Guyer Gotcha, thanks for explaining.
To be honest, if I switch to 7 channels out, my framerate will go down from 55fps to 36fps.
Either I should stay with the pin banging interrupt IR driver with your RMT driver, or I can see if I can find an ESP32 IRRemote compatible RMT driver for IR in, and then @Yves_BAZIN 's bit banging 16 line output for output.
Looks like I need to check this out: https://github.com/ExploreEmbedded/ESP32_RMT
@Marc_MERLIN - Thank you for your awesome work with IR control and various MCUs. Would it be possible for you to share your code for the ESP32 and IRremote.h?
I have gotten IRremote.h for a receiver to work on my Lolin D32 ESP32 but I am still having some minor issues with other parts of my code that uses a timer which is probably due to interrupts. Not knowing anything about RMT for the ESP32, would it be a benefit to have the various functions in IRremote.h for a receiver run in Core 0 of the ESP32 similar to the way @Sam_Guyer has the FastLed.show() function run in Core 0 in his DemoReelESP32 example?
@Ken_White I’m assuming you’re referring to this page http://marc.merlins.org/perso/arduino/post_2017-04-03_Arduino-328P-Uno-Teensy3_1-ESP8266-ESP32-IR-and-Neopixels.html
Back then, I was already using an RMT driver for neopixels (that was before fastled worked on ESP32), and I was using the IRRemote interrupt driver I hacked up to work for ESP32.
You can look at it and the code I posted there, but ultimately I’m “just” using IRRemote from git, and it just works on ESP32 as long as you can fire interrupts. If they get blocked, then it will not work as well.
I am going to look this week at running an RMT based IRRemote; https://github.com/ExploreEmbedded/ESP32_RMT but I’ll try switching to the big banging Neopixel driver from Yves since using Sam’s driver would limit RMT sending to 7 bits while I need 16.
@Sam_Guyer well, guess what, the interrupt based IR receive driver I wrote actually works well enough with @Yves_BAZIN 's driver. I don’t have to re-enable interrupts because ESP32 is fast enough that even when bit banging 16 lines, it still does it quickly enough that interrupts get re-enabled in time for 90-95% of IR events to be received ok.
Also, and I can’t explain it, his driver is now working better than yours for me even though neither of your respective codes changed. I was getting more glitches with your code, and are getting none with his now that I’m using 5V level shifters.
I’m on the last home stretch to get a lot of code finished before burning man, so I’m not going to mess with it if it works well enough, but I thought I’d report back.
Incidently, and somewhat off topic, I also found out the hard way that enabling ESP32 interrupts for IRReceive causes reliable crashes if I use SPIFFS. Workaround is to disable the IR interrupt before any SPIFFS access.
