I have been maintaining the ESP32 support for the FastLED library (http://fastled.io/), and I've noticed some changes to the ESP32 IDF RMT code that I'm concerned about.
We use the RMT device to drive clockless RGB LED strips, such as those built on the popular WS281X and SK681X chips. We don't use the ESP32 IDF driver, however, because we want to convert the RGB data into RMT items on-the-fly. That is, each time the RMT device finishes sending the buffer, it generates an interrupt, and we refill it with newly computed rmt_item32_t's. We offer an option to use the driver provided with ESP32 IDF, but it requires all of the color data to be converted to 32-bit items first -- a substantial memory overhead.
OK, so here is the issue: in the latest version of ESP32 IDF, I noticed that a lot of the API functions rely on having information from the p_rmt_obj array, which is only created when rmt_driver_install is called. I'm worried that when our code calls functions like rmt_tx_start, it will crash because the p_rmt_obj array is full of null pointers.
Can anyone from the ESP32 IDF team comment on these changes? What do you recommend we do for our custom driver?
Thanks!
For reference, here is the FastLED RMT driver code:
https://github.com/FastLED/FastLED/blob ... mt_esp32.h
Changes to RMT driver implementation?
Re: Changes to RMT driver implementation?
Interesting -- I have not seen the translator option before. Thanks!
I'll take a look at it more closely. There are two potential problems. The first is that the translation from pixel colors to data bits is not a simple mapping that could be done on a byte-by-byte basis. One option would be to translate all of the pixel colors into bytes ahead of time, which would require more memory, but not nearly as bad as translation all the data into RMT items.
The other issue is that we actually do a kind of double buffering. We set the RMT device to send an interrupt when *half* of the data is sent; we then refill that half while the device continues sending the other half.
I'll take a look at it more closely. There are two potential problems. The first is that the translation from pixel colors to data bits is not a simple mapping that could be done on a byte-by-byte basis. One option would be to translate all of the pixel colors into bytes ahead of time, which would require more memory, but not nearly as bad as translation all the data into RMT items.
The other issue is that we actually do a kind of double buffering. We set the RMT device to send an interrupt when *half* of the data is sent; we then refill that half while the device continues sending the other half.
Re: Changes to RMT driver implementation?
As a more general comment for the ESP32 IDF developers: it is not clear which RMT functions you can safely use with your own driver/interrupt handler vs those that only work with the default driver. I had to look at the code in rmt.c to figure it out.
Re: Changes to RMT driver implementation?
Hi szguyer,
I'm running in the same problem,
it worked perfect before updating IDF to idf_v4.1-dev-2047-g600d542-dirty
now I'm getting a crash at fastled init
Could you fix that issue by now ?
Regards,
Michael
I (1035) fastled: init
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was un handled.
Core 0 register dump:
PC : 0x400fd1ab PS : 0x00060c33 A0 : 0x800f917e A1 : 0x3ffbbea0
0x400fd1ab: rmt_set_tx_thr_intr_en at /home/micha/esp-open-sdk/esp32/esp-i df/components/driver/rmt.c:389 (discriminator 2)
A2 : 0x00000000 A3 : 0x3ffb48b8 A4 : 0x00000018 A5 : 0x00000080
A6 : 0x0000000d A7 : 0x00000000 A8 : 0x00000000 A9 : 0x3ffbbe80
A10 : 0x00000000 A11 : 0x00000012 A12 : 0x00000001 A13 : 0x00000000
A14 : 0x00000000 A15 : 0x00000002 SAR : 0x0000000e EXCCAUSE : 0x0000001c
EXCVADDR: 0x00000000 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffffd
ELF file SHA256: 6f12803fc555092448c38b25b894d13ae89e1ae5ec38e95cd3fbfd663 cc6411b
Backtrace: 0x400fd1a8:0x3ffbbea0 0x400f917b:0x3ffbbed0 0x400f8fef:0x3ffbbf 10 0x400fa16a:0x3ffbbf50 0x400f9f73:0x3ffbbf80 0x400d6b55:0x3ffbbfb0 0x400 d6e73:0x3ffbbfd0 0x400d6ef7:0x3ffbbff0 0x400d4542:0x3ffbc020 0x400d3b37:0x 3ffbc040 0x400d23a8:0x3ffbc090 0x40088119:0x3ffbc0b0
0x400fd1a8: rmt_set_tx_thr_intr_en at /home/micha/esp-open-sdk/esp32/esp-i df/components/driver/rmt.c:389 (discriminator 2)
0x400f917b: ClocklessController<18, 60, 150, 90, (EOrder)66, 0, false, 5>: :showPixels(PixelController<(EOrder)66, 1, 4294967295u>&) at /home/micha/p rojects/projects_esp32/httpd/components/FastLED-idf/include/clockless_rmt_ esp32.h:264
(inlined by) ClocklessController<18, 60, 150, 90, (EOrder)66, 0, false, 5 >::showPixels(PixelController<(EOrder)66, 1, 4294967295u>&) at /home/micha /projects/projects_esp32/httpd/components/FastLED-idf/include/clockless_rm t_esp32.h:294
I'm running in the same problem,
it worked perfect before updating IDF to idf_v4.1-dev-2047-g600d542-dirty
now I'm getting a crash at fastled init
Could you fix that issue by now ?
Regards,
Michael
I (1035) fastled: init
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was un handled.
Core 0 register dump:
PC : 0x400fd1ab PS : 0x00060c33 A0 : 0x800f917e A1 : 0x3ffbbea0
0x400fd1ab: rmt_set_tx_thr_intr_en at /home/micha/esp-open-sdk/esp32/esp-i df/components/driver/rmt.c:389 (discriminator 2)
A2 : 0x00000000 A3 : 0x3ffb48b8 A4 : 0x00000018 A5 : 0x00000080
A6 : 0x0000000d A7 : 0x00000000 A8 : 0x00000000 A9 : 0x3ffbbe80
A10 : 0x00000000 A11 : 0x00000012 A12 : 0x00000001 A13 : 0x00000000
A14 : 0x00000000 A15 : 0x00000002 SAR : 0x0000000e EXCCAUSE : 0x0000001c
EXCVADDR: 0x00000000 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffffd
ELF file SHA256: 6f12803fc555092448c38b25b894d13ae89e1ae5ec38e95cd3fbfd663 cc6411b
Backtrace: 0x400fd1a8:0x3ffbbea0 0x400f917b:0x3ffbbed0 0x400f8fef:0x3ffbbf 10 0x400fa16a:0x3ffbbf50 0x400f9f73:0x3ffbbf80 0x400d6b55:0x3ffbbfb0 0x400 d6e73:0x3ffbbfd0 0x400d6ef7:0x3ffbbff0 0x400d4542:0x3ffbc020 0x400d3b37:0x 3ffbc040 0x400d23a8:0x3ffbc090 0x40088119:0x3ffbc0b0
0x400fd1a8: rmt_set_tx_thr_intr_en at /home/micha/esp-open-sdk/esp32/esp-i df/components/driver/rmt.c:389 (discriminator 2)
0x400f917b: ClocklessController<18, 60, 150, 90, (EOrder)66, 0, false, 5>: :showPixels(PixelController<(EOrder)66, 1, 4294967295u>&) at /home/micha/p rojects/projects_esp32/httpd/components/FastLED-idf/include/clockless_rmt_ esp32.h:264
(inlined by) ClocklessController<18, 60, 150, 90, (EOrder)66, 0, false, 5 >::showPixels(PixelController<(EOrder)66, 1, 4294967295u>&) at /home/micha /projects/projects_esp32/httpd/components/FastLED-idf/include/clockless_rm t_esp32.h:294
Who is online
Users browsing this forum: VinayDand and 405 guests