Marc’s Weblog: arduino – LED Pants and Shirt v5 on ESP32 and Raspberry Pi with P2 RGBPanels and Wifi

==>>> See this full article on the why and evolution of my LED outfit <<<== Properly, the fifth (and perhaps final?) version of my LCD outfit was plenty of work in comparison with the earlier ones, it took 1.5 years of labor throughout covid to make it occur. Version 4 was described here.

end result after 1.5 years of work
finish end result after 1.5 years of labor

Transfer to Raspberry Pi

The v4 outfit was 64x96 decision (3 P4 panels of 64x32), whereas the brand new v4 outfit adjustments to 128x192 (3 P2 panels of 128x64), or 4 instances extra pixels working in the identical actual footprint (my physique measurement, which ideally stays fixed 🙂 ).
As a result of I now have 4x extra pixels, and that might have been an excessive amount of for an ESP32 or teensy (earlier than teensy 4, which might have performed it, nevertheless it lacks wifi), I needed to swap to one thing with extra reminiscence and horsepower, I went with rPi and Henner Zeller's rpi-rgb-panel library, which additionally supported extra panels like mine that had an FM6126 or FM6127 chip that required a particular init string.
The opposite motive for rPi is that to get a excessive refresh fee and keep away from seen refresh bars when taking photos with cameras, it was higher to run the three panels on 3 totally different channels to offer them most refresh fee (300-400Hz is feasible that means), which is supported by that library, utilizing the active-3 board. So, straightforward, I simply must port all my code from arduino/ESP32 to rPi/linux, proper? Rattling, that is really plenty of work, and I did not wish to do that, so I used to be capable of do one thing higher, I discovered ArduinoOnPC, and was capable of fork and modify it so as to add Framebuffer::GFX help and added 3 show outputs:
  • https://github.com/marcmerlin/ArduinoOnPc-FastLED-GFX-LEDMatrix is my primary fork with FastLED_NeoMatrix on prime linux/SDL help (this enables 2D rendering straight on linux)
  • Whereas the SDL help is greatest, I wrote a take a look at X11 framebuffer too: https://github.com/marcmerlin/FastLED_TFTWrapper_GFX
  • Then I've this FrameBuffer::GFX driver I wrote to output on RGBPanels on rPi: https://github.com/marcmerlin/FastLED_RPIRGBPanel_GFX
  • This mixed work permits working my arduino code on linux, principally unmodified, which suggests it runs on rPi. Then, the FastLED_RPIRGBPanel_GFX glue driver I wrote to make rpi-rgb-panel appropriate with FrameBuffer::GFX, permits working all my 2D code, unmodified and have it despatched to RGBPanels by the rpi-rgb-panel driver, I am glad I did not have to put in writing 🙂 So, that is what the prototype appeared like now 2 years in the past:


    I ended up writing this page explaining how others can do the same (run their arduino code on linux). On the way in which there, I took a small detour, constructed some RGBPanel frames with "extra panels" (these value $50 a bit, I've over $1000's value, ouch), and wrote this web page about it: RGB Panels, from 192x80, to 384x192, to 384x256 and maybe not much beyond

    ok, that was a nice distraction :)
    okay, that was a pleasant distraction 🙂

    Within the course of, I fastened plenty of bugs in all of the 2D code I had after I went to a 384x256 panel which clearly overflowed all code that relied on x and y being smaller than 256, and in addition blew up FastLED code that assumed that there might solely ever be 64K pixels 🙂 Whereas this was an enormous milestone and proved that my loopy concept working arduino code on rPi utilizing my identical 2D library, was doable, there was a **lot** of labor left to do for my outfit, together with altering all of the code to take care of a a lot greater decision, and days (sure days) of labor discovering near 200 animated GIFs within the greater decision, and rescaling them for my non normal 128x192 decision. Additionally, all of the fonts needed to be modified, and a bunch of different stuff, which took months and months of labor (all in throughout a yr): So, that is what it seems to be like, ESP32 SmartMatrix 64x96, in comparison with rPi rpi-rgb-panel 128x192, triple channel. Some gifs, I discovered the precise one in greater decision:




    this gif was so cool, it's only with the higher resolution that I found out it was Pulp Fiction
    this gif was so cool, it is solely with the upper decision that I discovered it was Pulp Fiction

    Different gifs, I discovered a a lot better one:


    Right here is an effective video displaying th decision distinction between the two chips:

    {Hardware}

    The {hardware} obtained a bit extra difficult, particularly as my wiring wasn't giving dependable sufficient 5V energy to the rPi inflicting random failures. Finally I needed to feed the battery voltage (16V) through a distinct cable and step it right down to 5V/USB behind the panels to get full energy to the rPi (in any other case when the panels drew an excessive amount of from the principle 5V supply, it dipped it a bit an excessive amount of and brought on points).
    It doesn't look nice, it is meant to be serviceable and simple to debug, and that half is in opposition to my physique, so folks do not see it 🙂


    For wiring causes, I had a pleasant trick with the entrance panels would shift out bits, and I might ship them to the again panels with ribbon cables. If you understand how RGBPanels work, it does imply {that a} BCM airplane meant to be displayed for an interval t1 within the entrance, finally ends up being displayed for an interval t2, when shifted to the again. Due to random luck of the order of BCM planes, it occurred to work effectively sufficient with SmartMatrix, so it saved wiring for me (no must splice the output to go to entrance and rear panels). Sadly with rpi-rgb-panel, the BCM planes are displayed within the reverse order it appears, so the output shifted on the rear panels, is visibly not good:



    Sadly, there isn't any good repair to this exterior of splicing cables, which I did not wish to do, so as a substitute I barely hacked the rpi-rgb-panel library to shift output bits twice. It is a bit wasteful for refresh fee, however issues have been quick sufficient with 3 channels, that I might afford the software program hack and shedding half of my refresh velocity.
    One other challenge with the ribbon cables is that the energetic 3 board is wired to have the cable stick up (i.e. in the direction of my stomach). I labored with the good of us at electrodragon to get naked boards with out the connectors soldered and checked out how one can greatest make it work for minimal top footprint. Backside in blue is the unique which sticks up the flawed means, higher proper is what I might like to have however is not doable as a result of the traces on the board must be rewired (pin order is flawed when the plug is put beneath), so I needed to settle with higher proper, some angled connectors and I needed to transfer the important thing gap from one aspect to the opposite for the cable to go in the correct means.


    I really wish I could have done this, but the wire order would be wrong
    I actually want I might have performed this, however the wire order could be flawed

    Then, I additionally needed to defend the panels with my kitchen chopping board sheets that I have been utilizing. It isn't good, however they act as diffusers and defend the pixels a bit, as a result of the P2 pixels are so small that they fall off in case you take a look at them flawed:


    Battery Use

    The brand new setup makes use of a bit extra battery, first due to the rPi, and in addition as a result of the brand new panels use barely extra energy, though not 4 instances extra as a result of the pixels are 4 instances slower, so the quantity of sunshine is considerably related. I needed to improve my setup to permit including a third 80Wh battery for longer festivals (12 to 14H with 240Wh). With 2 batteries within the black field, I get about 8-9H.


    ESP32 - rPi Integration

    As a result of all my code was written for ESP32, together with Wifi code that generated pages on the fly from code, because of https://github.com/distrakt/OmEspHelpers , and the ESP32 nonetheless runs the neopixels on legs and arms (plus IR enter, though it is turn into a bit out of date now), I took a really uncommon strategy of working my code on each CPUs a tthe identical time.
    The ESP32 runs the demo, and blind outputs it to an RGBPanel that is not there anymore. On the identical time, its debug serial output is linked to rPi which reads it as a textual content enter over a ttyUSB serial port. The rPi code can run in unbiased mode (the place I management it through ssh from my cellphone, haha), or it detect a hearbeat from the ESP32 over serial, and browse instructions from the ESP32, together with what demo to run. So, the ESP32 controls what demo is run, tells the rPi to modify to that demo and show to the RGBPanels. That makes the rPi a bit greater than only a glorified graphics card/GPU because it generates what pixels must be displayed as a substitute of simply being given a pre-computed framebuffer to show.
    I needed to make the code good over time in order that the rPi can join and disconnect from the ESP32 and run independently if the connection dies (which it used to after I had energy points that trigger the FTDI ttyUSB to fail routinely when working on batteries). The rPi can even back-control the ESP32, so after I take a look at at residence, I ssh into the rPi, and the rPi makes use of the serial connection to the ESP32 to inform it what to do, or I can use the net server on the ESP32 and inform it what to do straight. This implies the rPi can work by itself with out the ESP32 being wanted, apart from: - IR enter (it is not likely vital, and linux IR code could be very totally different, so it could be a full rewrite) - Wifi instructions (none of Wifi code works on linux and must be solely rewritten) - FastLED output wouldn't work effectively on rPi because it's timing dependent, and in addition there are not any IO pins left on mine with 3 channel output If I have been to re-write plenty of code to make wifi work on linux, that might make the rPi unbiased and never want the ESP32 anymore (apart from the neopixel strips), so I simply did not hassle. Additionally I can brag about having a twin CPU system with synchronization between the chips, which was enjoyable to put in writing and debug. This little bit of video exhibits how the two talk:

    Utilizing Linux integration for improvement

    There is not a lot to say about this, because of my ArduinoOnPC work talked about earlier on this web page, the very same linux code works on my rPi and my linux laptop computer, so I can write and debug my code on linux, which is a lot quicker. This exhibits an instance of what it seems to be like:

    Wifi and OmEspHelpers

    Ah sure, Wifi, that was a good quantity of code, particularly on ESP32 the place Wifi is extra primary and might trigger crashes in case you get bizarre conflicts between interrupts, Flash (SPIFFS or FATFS), PSRAM, IRAM, and Wifi. After searching for a simple to make use of answer, I settled on https://github.com/distrakt/OmEspHelpers as a result of I might generate the HTML pages from code (saving misplaced time to replace the Flash FS every time, which is sluggish with 16MB, and never having to fret about syncing HTML tags between static HTML pages code). That is the tip end result, the principle display screen permits deciding on which demos run (neopixel strips + major display screen), at which velocity, how vibrant:

    there are over 200 2D demos to cycle through, some are machine generated, some are animated gifs
    there are over 200 2D demos to cycle by, some are machine generated, some are animated gifs

    The prognosis screens give extra data on the gadget, and permit enhancing the config file that selects which demos run by default relying on the display screen measurement, and whether or not 'bestof' is chosen, or not. The config file additionally permits selecting the order demos run, in:


    Demo of wifi:

    Glasses

    I obtained uninterested in the El Wire glasses, they have been unreliable, obtained dimmer over time, required excessive voltage (I actually obtained shocked by that present when wires obtained frayed), so I removed them.
    I did strive laser reduce glass glasses, they give the impression of being sort of cool, however they're large and unattainable to fold. I ended up getting neopixel glasses which had good battery life, however after I dropped them as soon as, a pixel fell out, and that stopped the remainder of the string from working. Fortunately I used to be capable of take a spare neopixel from a strip and exchange the lacking one. I did not have the correct instruments or ability, so I used to be not capable of solder it, however I used glue and that labored too 🙂



    The place is the code?

    It is nonetheless the identical code, and it is nonetheless there: https://github.com/marcmerlin/NeoMatrix-FastLED-IR

    Finish end result

    I obtained all the things considerably working in April 2021 for a primary present (about 1.5 years from after I began), after which labored by a number of electrical and reliably issues (together with serial ttyUSB stability points, and energy points I needed to repair by including a second greater voltage feed to the rPi). Additionally fastened sync points between the chips and different enhancements in graphics and menus. I thought of V5 principally performed and dependable simply in time for ADE 2021, EDC 2021, and Dreamstate 2021 I had the outfit principally working (with a couple of occasional {hardware} points) in time for Creamfields and untold in Aug-Sept 2021:


    This even obtained me on Romanian nationwide TV 🙂
    I had enjoyable at ADE additionally, and add time to make customized shows for particular occasions:





    Source link

    Leave a Reply

    Your email address will not be published. Required fields are marked *