Marc's Public Blog - Arduino Hacking


All | Aquariums | Arduino | Btrfs | Cars | Cats | Clubbing | Dining | Diving | Electronics | Exercising | Flying | Hiking | Linux | Linuxha | Monuments | Museums | Public | Rc | Sciencemuseums | Snow | Solar | Trips



Table of Content for arduino:

More pages: April 2019 March 2019 January 2019 July 2018 May 2018 April 2018 January 2018 June 2017 April 2017 January 2017 February 2016 January 2015 September 2013 January 2012 December 2011 May 2011 January 2011




2019/04/08 Clubbing, EDM Festival and Burning Man LED Pants and Shirt v4 on ESP32 with RGBPanels and SmartMatrix::GFX
π 2019-04-08 01:01 in Arduino, Bm, Clubbing
Show me the code:
  • https://github.com/marcmerlin/NeoMatrix-FastLED-IR (same code than my previous shirt, but upgraded for the higher resolution)
  • https://github.com/marcmerlin/SmartMatrix_GFX (API on top of SmartMatrix from Louis Beaudouin, without which this new shirt wouldn't have been possible)
  • https://github.com/marcmerlin/AnimatedGIFs (also original from Louis Beaudouin).
  • https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos (includes Aurora from Jason Coon, and Table code from Mark Estes)
  • Related pages:

  • Shirt V2
  • Shirt V3
  • SmartMatrix GFX I had to write (including Teensy with SmartMatrix v4 shield vs ESP32)
  • Using FatFS on ESP32 to store Animated GIFs
  • Diffusers for RGBPanel
  • Details: After version 3 of my shirt with a neopixel matrix, I had good fun, but was hoping to do more. Its resolution was only 24 x 32 pixels, enough to display fun patterns, but it's really not a lot of pixels.


    After months and months of work, here is version 4:


    Video demo:

    Sadly, going up in resolution with addressable pixels, is not that easy. While in theory you should be able to fit at least 2 addressable pixels per centimeter (aka P5). Currently my premade panels are P10, which is the only thing I could buy pre-made.

    What allowed me to switch were those flexible P4 RGB Panels from Azerone: https://amazon.com/gp/product/B07F87CM6Y


    With their P4 resolution, I'm able to fit 96x64 on my body using 3 panels of 64x32 chained together. The 3rd panel is then chained to the 2nd set of 3 panels in my back:


    On the old shirt, I put the rear panel inside the shirt, using the shirt as a diffuser, but with the RBGPanels, they were too thick for this to be practical, so I had to put them on top of the shirt. As a result, I ended up uing a black shirt which matches the color of the panels. I had to attach velcro to the new shirt, and confirmed that supergluing them was so much faster than sawing, and worked just as well:


    I unsoldered the power connectors that were too thick, and used small metal wire to connect the panels together (see top middle of the picture). Turned out those metal wires were a mistake as they can cause shorts on the LEDs on the other side of the board:


    Another thing I learned was that the holes I was using to put a metal wire to carry the panels over my shoulders, can't actually take the load, and the wire can cause damage to the copper trace that is just next to the hole. As a result, I replaced the metal wires with fishing wire and didn't use the bigger holes for load bearing:


    Speaking of removing thickness from the board, I removed the top of the ribbon connectors to make them a bit thinner. Sadly, RGBPanels still require 15 wires to send the video signal:


    I then took one panel and covered it with defusing foam (the rear panel, so that it's not too sharp and blinding to people behind me), while the front panel only has the plastic cover to protect the panels and offer a bit of extra diffusion:




    you can see the difference between the diffusion levels
    you can see the difference between the diffusion levels

    I then protected the rear of the panels given how much electronics were exposed:


    Small details had to be solved, like making sure I had enough amps going through the wires (use thicker wires). Without that, my brightest pattern that uses 8 amps, didn't quite make it:


    For fun, I made a pattern that scrolls my C++ scrolling code on the screens:


    As for the CPU that runs it, I picked the ESP32 since it's dual core and can do refreshes on one core while running code on the other core. My SmartMatrix::GFX page has more details on using ESP32 with SmartMatrix


    I went from a breadboard prototype to Jason Coon's ESP32 level shifter board, much more tidy
    I went from a breadboard prototype to Jason Coon's ESP32 level shifter board, much more tidy

    This video shows how things are wired from the ESP32 to the panels:

    Here is what the whole power system looks like:

  • 2 4S Lipos, 5Ah, 80wh, giving a total 160Wh of energy
  • Amp meter in line with the lipos and cell tester with low voltage warning buzzer
  • On off/switch
  • Amp gauge with timer to know how much energy flowed from the batteries (you can't run lipos down or they'll die)
  • Tobsun DC-DC converter to take voltage down to 5V
  • 2nd voltage regulator to bring the voltage further down to 3.3V for the El Wire glasses
  • 5V goes to RGBPanels via separate thick wire to carry the amps
  • ESP32 with level shifters from 3.3V back up to 5V for the RGBPanels (6 channels for the colors to level shifters, 4 address lines to do 16 scan line refreshes). CPU runs SmartMatrix::GFX and NeoMatrix-FastLED-IR
  • 16th data line is used for the Neopixel strips on my arms and legs, running the same code than the previous shirt
  • Walk through video:

    I have around 60 demos running on the panels, including some Animated Gifs on ESP32 FFat with the library I was able to improve:





    You can see a demo of the outfit being worn:

    If you don't have time for all this, and are ok with 64x64, you can try this backpack from gearbest with everything built in and a very thin board. Just not fun for me because I can't run my own code on it:



    2019/04/01 SmartMatrix, SmartMatrix Shield v4 for Teensy, ESP32 shield with level shifter, and SmartMatrix::GFX
    π 2019-04-01 01:01 in Arduino

    Less blah-blah, more code

    Sure, there you go: https://github.com/marcmerlin/SmartMatrix_GFX

    What is it?

    https://github.com/marcmerlin/SmartMatrix_GFX is a zero copy, zero extra buffer frontend to Smartmatrix, which is the best arduino API driver for RGB Panels.
    It supports these 4 APIs seemlessly and concurrently in the same code:
  • Adafruit::GFX https://github.com/adafruit/Adafruit-GFX-Library
  • FastLED https://github.com/FastLED/FastLED
  • LEDMatrix https://github.com/Jorgen-VikingGod/LEDMatrix
  • SmartMatrix https://github.com/pixelmatix/SmartMatrix
  • Give me Examples

    Sure: https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos

    This page that shows how I built my EDM Festival and Burning Man LED Pants and Shirt v4 on ESP32 with RGBPanels and SmartMatrix::GFX using this library.

    More blah-blah & rationale for SmartMatrix::GFX

    Last year, I wrote FastLED::NeoMatrix to let me run Neopixel Matrices made out of pre-made panels arranged as a bigger panel. This was the end result: http://marc.merlins.org/perso/arduino/post_2018-04-23_FastLED_NeoMatrix-library_-how-to-do-Matrices-with-FastLED-and-Adafruit_GFX.html

    This allowed me to do my Party shirt v3 based on a NeoPixel Matrix

    However, the main problem I had was the limited pixel density of those neopixels and the price per pixel given that each pixel has a very small computer chip attached. My shirt was only 768 pixels per side (32x8x3) which cost $80 per side. While my shirt looked cool (i.e. better than nothing), 32x24 resolution isn't that much to display cool stuff. I made the best of it, but I knew that I wanted more pixels.
    While it's technically possible to get 0.5cm pitch (i.e. P5) with nepixels, there is no such panel I could buy today and I wasn't really interested in fabbing my own, so I switched to RGBPanels.

    What allowed me to switch were those flexible P4 RGB Panels from Azerone: https://amazon.com/gp/product/B07F87CM6Y


    RGBPanels are a totally different technology based on row scan technology, pretty much like the 8x8 matrices I wrote a scanning driver for but with a built in shift register to load up all the column for each color, multiplied by 2 as for historical reasons you can update 2 halves of the panel separately.
    With 32x64 panels, or even 64x64 panels, that's a lot of pixels to push serially via shift registers and address lines to select the line you've currently pushed all those columns for. The LEDs need to be refreshed very quickly to avoid visible flickering.
    This limits the list of reasonble CPUs for higher resolutions to teensy 3.6 and ESP32, which also removes the multiple slower and/of inefficient drivers out there. Options I looked at and weren't suitable:

  • https://github.com/adafruit/RGB-matrix-Panel/ (the adafruit driver is actually efficient, and recently got ESP32 support, but does not support panel chaining past very basic chaining)
  • https://github.com/mrfaptastic/ESP32-RGB64x32MatrixPanel-I2S-DMA/ (not well tested for larger chained panels, but efficient with DMA and offers Adafruit::GFX API. It also supports page level refresh instead of line level, so flickering is more manageable on it)
  • https://github.com/2dom/PxMatrix ( supports ES8266, but is 6 times slower than normal drivers by shifting all 6 colors onto a single wire ( https://community.pixelmatix.com/t/has-anyone-used-https-github-com-2dom-pxmatrix/384 ) ).
  • https://github.com/NeoCat/ESP32-P3RGB64x32MatrixPanel is an alternate driver with DMA support and apparently unsupported. I have no idea why this driver even exists when
  • This leaves us with the most complete driver of them all, Smartmatrix. The main pluses are:

  • Great support from the author on https://community.pixelmatix.com
  • Best support for chaining panels (up to 128x128 on teensy, and maybe 64x128 on ESP32 before it runs out of DMA RAM)
  • High color depth 24bpp or higher (which honestly is more than I need, 24bpp is more than most panels can probably reasonably show and 16bpp would likely be enough for my use). I still wouldn't mind if SmartMatrix offered 16bpp in exchange for a higher refresh rate or lower resource and memory utilization (also allowing for a higher resolution on a given CPU)
  • Support for the 2 fastest common arduino like microcontrollers: teensy 3.6 and ESP32 (teensy 3.1/3.2 is not fast enough to refresh 64x64 well enough, and teensy 3.5 is slower than 3.6, so no reason to buy one)
  • Very powerful API with multiple layer support (great if you can use it, although I'll admit that I only need drawpixel thanks to Adafruit::GFX)
  • So, SmartMatrix is great, but I have all this code that relies on one or more of those APIs:

  • Adafruit::GFX https://github.com/adafruit/Adafruit-GFX-Library
  • FastLED https://github.com/FastLED/FastLED
  • LEDMatrix https://github.com/Jorgen-VikingGod/LEDMatrix
  • I have a reasonble collection of demos I've gathered (a few I wrote myself), here: https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos and they use a combination of those 3 APIs.
    The goal was for me to be able to re-use that code and make it work on both FastLED backends and SmartMatrix backends, which why I wrote SmartMatrix::GFX
    https://github.com/marcmerlin/SmartMatrix_GFX offers a GFX compat layer that is virtually identical to my FastLED::NeoMatrix library and allows you to run the same code onto of either FastLED or SmartMatrix supported panels.

    Hardware, Teensy 3.6 and SmartMatrix Shield v4

    The easiest way to use SmartMatrix is to use the SmartMatrix Shield v4 from Louis Beaudoin.
    If you are going to drive 64x64 and above, skip the teensy 3.0/3.1/3.2 and go directly to teensy 3.6. It costs more, but you'll want the extra CPU speed (teensy 3.1 can barely run 64x64 with an ok-ish refresh if you overclock it, if you must use the older chip).

    Here is what the SmartMatrix shield looks like with a small patch I made to take USB power and send it to the panel (my laptop can output 2A over USB). Note that this is not safe with teensy v3.1/3.2 as it's not meant to pass that much current from its USB connection, but teensy 3.6 can do it fine as its fuse is located after the V+ connection on the chip:

    Originally I used the APA connector to send power to the panel
    Originally I used the APA connector to send power to the panel

    2x 32x64 chained P4 panels with a sad cable extension I had to make, vs pre-made 64x64 P3 panel
    2x 32x64 chained P4 panels with a sad cable extension I had to make, vs pre-made 64x64 P3 panel

    SmartMatrix basic demo
    SmartMatrix basic demo

    The main problem with RGBPanels is that if the refresh rate isn't fast enough, they look bad on pictures. This is the main reason I switched to ESP32 which is dual core and can push a higher refresh rate via DMA than teensy can:


    Chained panels giving mirrored output on a total display of 128x96:


    Hardware: ESP32

    As mentioned above, ESP32 is dual core, so it can update the panel on one core using DMA, while the other core can run your code. It is more efficient, however, it runs out of DMA memory around 64x128 resolution (I run 64x96 myself and had to optimize code to make things fit)..

    Here are shots of what it looks like with Jason's shield:

    it's reasonably compact, 15 IO's for SmartMatrix (14 are really required), IR connected to port 34, and IO 16 connected to a NeoPixel strip
    it's reasonably compact, 15 IO's for SmartMatrix (14 are really required), IR connected to port 34, and IO 16 connected to a NeoPixel strip

    This shows my flexible P4 96x64 panels I bought on amazon from Azerone, 3 tied together, one shown upside down for scale, a blank shield from Jason Coon, how I cut a 16 pin IDC ribbon cable and made it an in line row of pins I can connect into Jason's shield after having added a riser, and a patched board with IR connector on the back, and a yellow wire to redirect the pin Jason's board connected to RX which I use for debugging, to unused pin 27 instead:


    While Jason's board is not perfect for this use, it's much better than my self made protoboard full of wires to connect the 74hc245 level shifters:


    Here's a quick video summary that shoes the wiring and layout:

    Tips for ESP32 and memory:

  • Do not use arrays, ESP32 does badly with array allocation for complicated reasons and bugs ( https://github.com/espressif/arduino-esp32/issues/2567 )
  • See also https://community.pixelmatix.com/t/esp32-runs-out-of-some-ram-when-using-64x96/394 for more background
  • And how SmartMatrix will crash if it can't allocate enough DMA RAM at startup (again, switch your code to use malloc and allocate after you've ran SmartMatrix init): https://community.pixelmatix.com/t/cant-get-enough-dma-memory-on-esp32-assertion-matrixupdateframes-1-null/406/19
  • SmartMatrix.begin(xxx) lets you force SmartMatrix to use less RAM and use more lsbMsbTransitionBit which makes display worse but can help
  • More details on what memory is available on ESP32: https://github.com/espressif/esp-idf/issues/1934#issuecomment-389087100
  • Another ESP32 corner case bug I found if you use global static arrays: https://github.com/espressif/esp-idf/issues/3211
  • Do not even think about using local arrays in functions, that's worse as they go on the stack and will smash the stack (I think you're limited to around 8KB)
  • ESP32 has SPIFFS to use its flash to store data like Animated GIFs. You will find it unacceptably slow if you store 1MB or more and seek across a bunch of files, Instead, use FatFS as explained here:

  • http://marc.merlins.org/perso/arduino/post_2019-03-30_Using-FatFS-FFat-on-ESP32-Flash-With-Arduino.html
  • https://github.com/marcmerlin/esp32_fatfsimage
  • Make sure you use FFat.begin(0, "", 1) to save RAM
  • SmartMatrix Support:
    Louis Beaudoin added ESP32 support in this branch https://github.com/pixelmatix/SmartMatrix/tree/teensylc .
    You'll want to look at this file for how to wire your ESP32: https://github.com/pixelmatix/SmartMatrix/blob/teensylc/src/MatrixHardware_ESP32_V0.h#L62
    While you can apparently get away with no using a level shifter (at least with some panels), I chose to use one. First, I did it the hard way with a protoboard and level shifter chips, and then I switched to Jason Coon's 16 output ESP32 shield.
    I then used a HUB75 ribbon, cut the end, and made a straight connector that went directly into the IO pins coming fromthat shield

    Here are pictures of what it looks like:

    Hopefully in the near future, one will be able to buy a pre-made ESP32 SmartMatrix shield.

    End result

    Here are some demos of https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos and https://github.com/marcmerlin/NeoMatrix-FastLED-IR on top of SmartMatrix with 2 chained subpanels of 64x96 (each made out of 3 64x32 panels):













    As a side note, RGBPanels look better when you have a diffuser sheet in front, so here is a page on that.

    2019/03/30 Using FatFS FFat on ESP32 Flash With Arduino
    π 2019-03-30 01:01 in Arduino
    FatFS on ESP32 wasn't well documented, or usable, so I learned about it, and made some changes to the esp32-arduino core:
  • https://github.com/espressif/arduino-esp32/pull/2623/files
  • https://github.com/marcmerlin/arduino-esp32
  • https://github.com/espressif/arduino-esp32/blob/170d204566bbee414f4059db99168974c69d166e/tools/partitions/noota_3gffat.csv
  • ffat,     data, fat,     0x111000,0x2EF000,

    If you pull https://github.com/espressif/arduino-esp32/ master and select esp32-dev, you will see easy to select partition splits for code vs FFat.

    More details here: https://github.com/marcmerlin/esp32_fatfsimage/blob/master/README.md , and at the top level, there is a pre-generated fatfsimage that lets you build a fatfs image:

    # replace 3004 with the size of your partition. In the 1/3MB split, the fatfs partition is 
    # 0x2EF000 = 3076096 .  3076096/1024 = 3004
    fatfsimage -l5 img.ffat 3004 datadir

    Once the image is built

    esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 write_flash  0x111000 img.ffat

    Example

    I put together some code you can run to verify the partition list and get a file listing: https://github.com/marcmerlin/esp32_fatfsimage/blob/master/arduino/ffat/ffat.ino .

    Here is the output:

    partition addr: 0x010000; size: 0x100000; label: app0
    partition addr: 0x009000; size: 0x005000; label: nvs
    partition addr: 0x00e000; size: 0x002000; label: otadata
    partition addr: 0x110000; size: 0x001000; label: eeprom
    partition addr: 0x111000; size: 0x2ef000; label: ffat
    

    Trying to mount ffat partition if present File system mounted Total space: 3018752 Free space: 1429504 Listing directory: /gifs64 FILE: /gifs64/ani-bman-BW.gif SIZE: 4061 FILE: /gifs64/087_net.gif SIZE: 46200 (...)

    More details and code here: https://github.com/marcmerlin/esp32_fatfsimage

    Memory Use

    The FFAT module uses 8KB plus 4KB per concurrent file that can be opened. By default, it allows 10 files to be opened, which means it uses 48KB. IF you want to reduce its memory use, you can tell it to only support one file, and you will save 36KB, leaving you with only 12KB used.
    if (!FFat.begin(0, "", 1)) die("Fat FS mount failed. Not enough RAM?");

    AnimatedGIFs

    I've then improved AnimatedGIFs to add support for FatFS/FFat which nicely fixes the short hangs I was getting with SPIFFS, which was ruining the animations:
  • https://github.com/marcmerlin/AnimatedGIFs
  • https://github.com/marcmerlin/AnimatedGIFs/commit/4356c81a5da76677d34c60d6dde74c5693870552
  • 2019/01/24 Linux.conf.au 2019: Using Open Hardware from my shirt to OS testing for Google's Fuchsia
    π 2019-01-24 01:01 in Arduino, Electronics, Linux
    I've been going to linux.conf.au for 18 years now (since 2001), and presented a fair amount of linux talks related there, but the big change for me was the open hardware miniconf that started in 2010. Thanks to its projects every year, I got to learn a lot about microcontrollers and some about electronics.
    This talk was my first non linux talk which detailled everything I learned from those miniconfs and projects I worked that stemmed from them. I presented it at LCA 2019 Christchurch.

    you can find the talk pdf here: http://marc.merlins.org/linux/talks/Using_Open_Hardware/Using_Open_Hardware.pdf (you'll want this one to get all the clickable links in the slides)
    you can view the talk slides in html here or below:

    Talk video below:

    I arrived the sunday before the conference and helped out the open hardware organizers with a bit of last minute setup. I also got to do some last minute testing and tuning of my panels:

    hacked up ESP32 with level converters on breadboard to run 3x 64x32 SmartMatrix panels with SmartMatrix::GFX
    hacked up ESP32 with level converters on breadboard to run 3x 64x32 SmartMatrix panels with SmartMatrix::GFX

    64x64 P3.8 SmartMatrix::GFX panel vs 3x 64x32 SmartMatrix::GFX P4 flexible panels vs 4x 16x16 FastLED::NeoMatrix P10 panels
    64x64 P3.8 SmartMatrix::GFX panel vs 3x 64x32 SmartMatrix::GFX P4 flexible panels vs 4x 16x16 FastLED::NeoMatrix P10 panels

    After finishing the code tuning and demos just in time, gave a 20mn miniconf talk on the history of linux.conf.au hardware miniconf. I went through how much I learned from those confs and what I was able to achieve as a result. I sure got to learn a lot about microcontroller and driver programming:




    I wasn't able to bring my burning man 4096 neopixel matrix, it doesn't even fit in my car, but the irony is that my small 64x64 rgbpanel has the same resolution and fits easily in my backpack
    I wasn't able to bring my burning man 4096 neopixel matrix, it doesn't even fit in my car, but the irony is that my small 64x64 rgbpanel has the same resolution and fits easily in my backpack

    The 64x64 compact display is showing the hand X-ray here
    The 64x64 compact display is showing the hand X-ray here

    A few days later, I gave the longer version of my talk at the main conference. By then it had grown to over 160 slides in a 45mn slot, or 16 seconds per slide. Ooops...

  • The full talk went into details on what I learned in the hardware hacking field, a lot of it was simply electricity, U=RI, wires, pre-made components (small inline volt/amp meters, DC-DC converters, and so forth).
  • I also gave a is a quick summary of my hacking an arduino board to turn it into a sleep analysis machine, a longer talk I gave elsewhere in 2012.
  • There is a section on what I learned from Tridge and RC planes with ardupilot
  • I had to mention microcontroller hacking and driver writing for IoTuz on ESP32 given how much I learned from it
  • And IoTuz got me to write a primitive Neopixel driver for ESP32, a very slippery slope that led me to many LED projects
  • http://marc.merlins.org/perso/arduino/post_2015-01-06_Driver-for-direct-driving-single-to-3-color-LED-Matrices-with-software-PWM.html
  • http://marc.merlins.org/perso/arduino/post_2017-04-03_Arduino-328P-Uno-Teensy3_1-ESP8266-ESP32-IR-and-Neopixels.html
  • http://marc.merlins.org/perso/arduino/post_2017-04-24_Adafruit-GFX-on-NeoMatrix-and-RGB-Matrix-Panel-Demo.html
  • http://marc.merlins.org/perso/arduino/post_2017-06-02_LED-Pants-and-Shirt-Programmed-With-Arduino-on-ESP8266.html
  • http://marc.merlins.org/perso/arduino/post_2018-04-23_FastLED_NeoMatrix-library_-how-to-do-Matrices-with-FastLED-and-Adafruit_GFX.html
  • http://marc.merlins.org/perso/arduino/post_2018-05-29_EDM-Party-Shirt-powered-with-FastLED_NeoMatrix-and-Adafruit_GFX_-plus-160Wh-_10Ah-4S_-worth-of-lipos.html
  • http://marc.merlins.org/perso/arduino/post_2018-07-13_AnimatedGIFs-for-SmartMatrix-or-NeoMatrix-_Neopixel-WS2812B_-from-SDcard-or-SPIFFS_-on-Teensy-3_x_-ESP8266_-or-ESP32.html
  • http://marc.merlins.org/perso/arduino/post_2018-07-30_Building-a-64x64-Neopixel-Neomatrix-_4096-pixels_-running-NeoMatrix-FastLED-IR.html
  • https://github.com/marcmerlin/SmartMatrix_GFX
  • and for good measure the talk ends with how I was able to apply some of that knowledge to design simple solutions for hardware testing racks for Google's Fuchsia on arm platforms.


  • Hopefully the talk and/or slides are useful to you. Links:

  • http://marc.merlins.org/linux/talks/Using_Open_Hardware/Using_Open_Hardware.pdf
  • http://marc.merlins.org/linux/talks/Using_Open_Hardware
  • http://marc.merlins.org/perso/arduino
  • https://www.youtube.com/watch?v=YqeBXCCabo0
  • 2019/01/21 Donkey Car with Tensorflow Video Analysis at Open Hardware Miniconf at Linux.Conf.au 2018
    π 2019-01-21 01:01 in Arduino, Linux
    This year, the Open Hardware Miniconf team designed a donkeycar for us at LCA 2019 Christchurch. It's a car that navigates by itself using its onboard camera connected to a Raspberry Pi using training video data gathered and analysed offline by tensorflow. That sure was an ambitious project!

    I arrived the day before to help finish up the kits for the next morning:



    the cars were eager to perform :)
    the cars were eager to perform :)

    Andy and Jon who ended up working all night to make sure the kits would work the next morning
    Andy and Jon who ended up working all night to make sure the kits would work the next morning


    The next morning, we showed up to build the kit:




    rPi with custom last minute hat for the donkey car
    rPi with custom last minute hat for the donkey car

    done!
    done!

    Jon gave a talk about the car design
    Jon gave a talk about the car design

    Nice way to support 5V neopixels on 3.3V microcontrollers
    Nice way to support 5V neopixels on 3.3V microcontrollers

    We then had a few talks:



    Including mine on the history of linux.conf.au hardware miniconf


    After the miniconf, we had a few tries at getting our own cars to self drive after training:


    I decked out my car with neopixels, because bling! :)
    I decked out my car with neopixels, because bling! :)


    2018/07/30 Building a 64x64 Neopixel Neomatrix (4096 pixels) running NeoMatrix-FastLED-IR
    π 2018-07-30 01:01 in Arduino
    You want the code? Sure, it's here: https://github.com/marcmerlin/NeoMatrix-FastLED-IR

    What's the end result? This:

    Full story and build

    I inherited 64 strips of mostly 64 neopixels per strip (some were as low as 61, and some as high as 66).


    not all the same lengths
    not all the same lengths

    64 strips is run as 16 lines of 4 strips of 64 pixels (256 pixels), were tested 4 by 4, as the line of 256 pixels that they were with a Neopixel tester that sends test patterns:


    the neopixel tester I'm using, along with a 5V 10A DC converter outputting 8A into the controller (testing full white)
    the neopixel tester I'm using, along with a 5V 10A DC converter outputting 8A into the controller (testing full white)

    The first 16 lines took a long time (almost 2 full days due to the time to measure everything including the cardboard, cutting it carefully, marking where all the LEDs will go, and then testing as I go along to make sure I'm not repeating something that will have to be undone:


    A bit of test from my MatrixGFXDemo.ino code
    A bit of test from my MatrixGFXDemo.ino code

    Then comes the issue of attaching all of this. I decided very early to remove the IP67 protection as the silicon is resitant to virtually all glues, making it very hard to work with. I also had to splice broken LEDs in the strips I inherited, so it's much easier to do without the protective casing. I simply attached the bare pixels with those very stick glue dots:


    After about 3 days of work, got 50% done:



    Power delivery: getting the wire sizes right is important, but turns out you don't need huge wires for 64 pixels. What I did was connect power from each of them at the end and therefore spread the maxium 10A they can draw to 4 times 2.5A, which can go fine over smaller wires as pictured below. The green wire goes between the Data Out to Data In pins of the strips (3 short green wires only for 4 strips)


    The 64x64 array was meant to be 2 arrays of 32x64 for ease of transport, each with their own 60A 5V power supply (when actually 40A would have been enough for each set of 2048 LEDs even if their maximum is around 80A in theory). I used thick 10 gauge wire to make sure the power bus could support 100A or so if needed, even if in real life, it'll never really much more than 20-30A:


    power testing, this can replace a small sun ;)
    power testing, this can replace a small sun ;)

    Once 50% was verified to be working fine, the other 50% was still a lot of work, but I didn't have to stop for testing of the power, layout, and design. It took another day and a half to do the other 50% at much higher pace, getting all the little wires cut at the right length in advance, gluing all the strips in one fell swoop (still hours or work), and then all the soldering, with validation at the end:

    looking better
    looking better

    yeah!
    yeah!

    For anyone contemplating that work, most of the work was:

  • cutting the cardboard backing to the right size, and marking where the strips were going to go
  • cutting/fixing all the strips (they were second hand, some were broken or the wrong length)
  • 320 glue points for the strips, one by one :)
  • cutting lots of little wires to the right length, stripping them
  • only then does soldering come in
  • then test each set of 4 strips (64x4) with a special neopixel tester
  • build the 10 gauge power bus
  • the hardest thing has been to solder all the little wires to the 10 gauge power bus turns out. They don't like staying together due to size and thermal issues.
  • and all the twisted pair and wiring on both sides (seemed trivial but it was more work than I thought) to connect to the microcontroller
  • End result:



    ESP32, why not something else like Teensy?

    So, my shirt that drives 24x32 uses ESP8266. ESP8266 can do up to 4 lines of parallel output, which is not sufficient for a proper frame rate on 4096 pixels. ESP32 does allow up to 24 lines of parallel output (untested) and can easily do 16 lines of output (110 frames per second for 4096 pixels).
    Teensy would would have worked too, but I've had too many problems with teensy, namely:
  • the hacked up build environment patched on top of some version of the arduino sdk. Recently I've had 30 second pauses before compiles even happen if I'm using the serial port (reported the bug, never heard back, never got fixed). This made sense years ago, but not anymore today that arduino supports other hardware boards "the right way"
  • newer sdk patch that's supposed to fix things, working even less for me (1.42 beta worked even less than 1.41 when I tried it).
  • serial output just stopping randomly after outputing X lines, making debugging impossible. This was a big deal for me, I reported it, but never got a fix.
  • no hypervisor like task that catches crashes and gives you a traceback with line numbers like you get on ESP chips (which really helps for debugging problems). This is also a big plus of ESP chips
  • no onboard flash usable for an SPIFFS filesystem (like the 4MB of flash on ESP32). Now, I'll have to admit that SPIFFS starts falling in performance due to how it's written when you reach 1MB or more of data, but it could be fixed with a better driver and beats no onboard filesystem at all on teensy (you need the 50-ish dollar teensy 3.5 to get an sdcard reader)
  • closed bootloader that prevents better debugging, and maintained by a single person who is very helpful, does a lot of work, but cannot compete with more open chips maintained by multiple people. It pains me to say this, because Paul Stoffregen does an incredible amount of work for one person, but he remains one person with a closed bootloader design and a hacked up SDK (sorry to say it). Compare with ESP32 which has near real time support on https://gitter.im/espressif/arduino-esp, plus https://github.com/espressif/arduino-esp32/ .
  • and not that it really matters to me, but despite all these issues, teensy costs at least 2 to 3 times the price of ESP32.
  • Hardware-wise from https://www.pjrc.com/teensy/techspecs.html vs https://en.wikipedia.org/wiki/ESP32

  • Teensy 3.6 is 32 bit 180/240 MHz ARM Cortex-M4 single core vs 32-bit LX6 microprocessor, operating at 160 or 240 MHz dual core
  • Teensy 3.6 is 1MB of flash vs 4MB of flash for ESP32 (which can be segmented for OTAs via Wifi and SPIFFS filesystem)
  • Teensy 3.6 has 256KB vs usually 520MB of SRAM on ESP32 (although not that much more than teensy's memory amount is usable for code).
  • ESP32 is dual core (although that adds complexity), adds Wifi and BT vs built in sdcard on teensy 3.6
  • Teensy has more pins but requires an expensive breakout board to use them all
  • I think teensy 3.1 (now 3.5/3.6) was the best chip around for many years, but honestly ESP32 seems like a better solution for most needs, especially debuggability. This is not to say that Teensy 3.6 is a bad offer, it does a few things better than ESP32, but at a much higher cost, and its SDK and problems explained above, make it a less desirable solution for me.

    Why not use those premade 32x32, 32x64, or even 64x64 RGBpanels?

    This is a very good question. First, they don't exist for neopixels, they exist for a different lower tech solution that requires a lot of work to drive.

  • It's a lot easier to get a lot of pixels for not much work on those RGB panels: https://www.adafruit.com/product/2276 , but they are thicker, don't bend at all, and driving them is a lot more work than neopixels. Sadly, because they require row scanning (like an old CRT TV), they also don't look good if you move them, move your head, or take a picture unless you drive them at very high speed, which is harder to do with microcontrollers.
  • Turns out that those panels can be made bendable too now: https://www.adafruit.com/product/3803 but still, they don't seem to come in bigger pitch sizes, and still have the persistence of vision problem I just described.
  • In the case of a big display, neopixels that usually require too much space (high pitch), actually come out ahead if you want your display to be 1m^2. RGB panels come out ahead for smaller displays with high resolution, you can go as low as 2-3mm pitch, which beats all existing neopixels: https://www.adafruit.com/product/2279 .
  • If you want to go higher sizes with those RGB panels, it gets more complicated as you need to drive them even faster. An ESP32 can reasonably drive up to 96x64 pixels while a tensy 3.6 can almost drive 128x128 with a bad refresh rate. You need a raspberry pi or an FPGA for bigger matrices.
  • My point here is that neopixels cost more, but they're a lot easier to drive, despite the timing issues you start running into when you're driving a lot (the more you drive per line, the lower the refresh rate, putting a reasonable limit for a single MCU around 10,000 LEDs if you're ok with a 35Hz refresh rate).
    I personally wish for Neopixel matrices that ship in 32x32 or higher, potentially with the option to inject a new data line every 256 or 512 pixels (so you can drive them as one big slower array, or cut the data line in the middle and inject parallel data lines for faster refresh rates.

    ESP32 8 or 16 Parallel output and driver

    First, 4096 pixels without parallel output, I would only get 7fps, which is quite slow.

  • With Sam's driver: https://github.com/samguyer/FastLED , you can use the RMT driver in ESP32 which allows for 8 parallel outputs. This can be used for more than 8 pins, I used it with 16 and the driver can switch RMT back and forth between the first set of 8 pins and the 2nd set of 8 pins.
  • Yves' driver https://github.com/hpwit/fastled-esp32-16PINS uses software bit banging and allows around 24 pins to be used in parallel
  • Yves' driver obviously gives you better FPS, but taxes the CPU a lot more by doing all the bit banging. Also, in my testing, it did not work reliably until I added level shifters, while Sam's driver actually produced better waveforms that worked at 3.3V without level shifters.

    The 2 drivers don't get setup the same though, see those differences:

  • https://github.com/marcmerlin/NeoMatrix-FastLED-IR/blob/e8b910ec81ca69a15ac63af5a23202ce48c7f32f/config.h#L32
  • https://github.com/marcmerlin/NeoMatrix-FastLED-IR/blob/e8b910ec81ca69a15ac63af5a23202ce48c7f32f/config.h#L68
  • https://github.com/marcmerlin/NeoMatrix-FastLED-IR/blob/e8b910ec81ca69a15ac63af5a23202ce48c7f32f/config.h#L234
  • https://github.com/marcmerlin/NeoMatrix-FastLED-IR/blob/e8b910ec81ca69a15ac63af5a23202ce48c7f32f/config.h#L273
  • Which driver is best for you? I'd say it depends but if you are ok with up to 8 parallel pins, use Sam's driver with RMT, and if you want more pins (up to about 24), use Yves' driver.

    Wiring and Level Shifters

    I first did it wrong by wiring directly to ESP32. This was doubly a mistake because there is sadly no standard pin numbers between ESP32 boards, meaning that I had to re-wire my plugs if I changed chips:


    My other problem was that while 3.3V output worked ok enough, when using Yves Basin's 16 line parallel output code, the software built waveforms didn't work well enough at 3.3V. I had to add level shifters, which also nicely added a level of indirection between my cat5 twisted pair cables and the pin numbers on the chip:


    Later, I changed one more thing which was to reomve the bidirectional level shifters that were unnecessary and caused issues at boot on ESP32 by messing with some IO pins. Turns out I had go make sure GPIO2 and GPIO12 were low at boot or flashing and reboots would fail (hence the resistors in the picture). However, I ended up replacing them with simpler 74HC245 unidirectional level shifters which don't mess with I/O pins and removed the need for the resistors

    Software

    Thankfully I was able to leverage the weeks/months of work I put on https://github.com/marcmerlin/FastLED_NeoMatrix and then demos I wrote for it, or shamelessly borrowed from more talented programmers :)
    I then spent a lot of time on my https://github.com/marcmerlin/NeoMatrix-FastLED-IR code that ran my Neopixel shirt and adapted it so that its demos would work on a 64x64 matrix while skipping the handling of neopixel strips that are on my pants and arms. I then did a recording of the entire set of demos, including 64x64 animated gifs I found and liked, and ended up with 41mn:


    Conclusions

  • The build was a lot of work, no fun at all: over 4 days of solid work... If you do this, strongly consider getting pre-built matrices that are ideally at least 32x32. Sadly most of the ones for sale today are 16x16 which still means getting 16 of them for about $500, laying them out and soldering them. It's not trivial work either if you re-inject power in them in more than one place, but clearly less work than laying 64 strips by hand like I did.
  • Get power right. I had some experience there, so I did my math beforehand and verified as I went along. It's not so hard to change a power supply, but it sucks if you have to replace all your power wires you spent so long to cut and solder.
  • Software is key of course. Running 16 strips in parallel requires some work from a small embedded CPU. Doing Infrared at the same time is not trivial. You can look at my code on how I got it to work, including this bug I found: https://github.com/espressif/arduino-esp32/issues/1781
  • The RMT driver on ESP32 is great doing doing DMA to 8 lines and either doing infrared without interrupts (sadly I found no IRRemote compatible RMT driver for arduino), or for outputting 8 lines of neopixels at once without big banging from the CPU (this is the FastLED Neopixel driver that Sam Guyer wrote). 8 lines only gives 55fps for 4096 LEDs, while 16 lines gives a nicer 110fps and leaves the RMT driver free for IR Receiving (putting aside that there is no driver at the moment).
  • I couldn't have done this without plenty of great work from others, be it the FastLED authors and contributors, Yves who offered his suport since he did a bigger build than mine, and his 16 line parallel driver, Jason Coon and others for the Aurora SmartMatrix demos I was able to use, and Mark Estes for even more LEDMatrix demos he wrote and that I was able to use too. Thanks all.
  • Burning Man

    Oh yeah, I built this for Burning Man and despite being hard to transport due to its size, it made it there ok and survived the playa dust for a week:

    due to lack of skill and lack of time, I used my protoboard and taped it on the reard of the display. Not professional, but it works
    due to lack of skill and lack of time, I used my protoboard and taped it on the reard of the display. Not professional, but it works


    running matrix demo
    running matrix demo

    animated GIFs are fun
    animated GIFs are fun

    somehow my protoboard and ESP32 survived the playa dust for the week
    somehow my protoboard and ESP32 survived the playa dust for the week

    Enjoy and have fun!

    2018/07/13 AnimatedGIFs for SmartMatrix or NeoMatrix (Neopixel/WS2812B) from SDcard or SPIFFS, on Teensy 3.x, ESP8266, or ESP32
    π 2018-07-13 01:01 in Arduino
    This is about https://github.com/marcmerlin/AnimatedGIFs (which recently added FatFS support)

    Louis Beaudoin published a gif decoder for arduino, which was designed for SmartMatrix and Teensy, and used for the Aurora Project. It also required an sdcard since Teensy does not have onboard flash usable for an onboard filesystem (unlike ESP8266/ESP32).

    With his encouragement, I took his code, and ported it to my FastLED::NeoMatrix library which allows using neopixels as matrices. I later added Smartmatrix::GFX Support to allow using the same GFX API to talk to both NeoMatrix and RGBPanel backends
    I also added support for SPIFFS and FatFS on ESP8266 and ESP32 (built in flash memory filesystem on ESP chips, which allow working without any sdcard at all).

    Here is the resulting code: https://github.com/marcmerlin/AnimatedGIFs

    You can look at AnimatedGifs for the keys that are supported over serial port.

    If "I just want to to display a GIF on my NeoMatrix", then I direct you to SimpleGifAnimViewer.ino which is a mere 60 lines of code if you remove the comments.
    If you are ok including one more file, you can do it in 10 lines of code instead, see SimpleGifAnimViewer2

    If you'd like to use the faster FatFS (over SPIFFS) there is a Makefile to generate img.ffat. See Using FatFS FFat on ESP32 Flash With Arduino for how to generate a FatFS image on your linux computer.

    Here is an example video and pictures of NeoMatrix 32x32 and RGBPanel 64x64:








    Here is a version running on a 64x64 RGBPanel backend with 2 different kinds of diffusers:


    Enjoy, Marc

    2018/05/29 EDM Party Shirt powered with FastLED::NeoMatrix and Adafruit::GFX, plus 160Wh (10Ah/4S) worth of lipos
    π 2018-05-29 01:01 in Arduino, Clubbing, Electronics



    After I figured that my previous shirt was getting a bit stale, I wanted to design EDM Party Shirt v2, which both had to be easier to wash (the previous one had LED strips all over it that were too much work to remove, making the shirt not really washable), and I also wanted it to be more special.
    I had been playing with Adafruit::NeoMatrix and figured it would be cool to have a NeoMatrix on my shirt (also it would be easier to remove a whole panel to wash the shirt).

    So, in the great tradition of yak shaving, I first decided that I should be able to use FastLED instead of Adafruit::Neopixel. This was mainly at the time because FastLED allows parallel output and therefore allows updating a screen by segmenting it in smaller pieces that are updated in parallel. With Adafruit::NeoMatrix, my 768 pixel panel would have taken about 30ms to refresh, or only 33 frames per second, which is not a lot. With FastLED, I was able to trivially segment it in 3 and get 10ms/100fps, which is a whole lot better for animations.
    Turns out, switching to FastLED also gave me access to LEDMatrix, an alternate library which while lacking Adafruit::GFX primitives, offers another nice API including better text and basic sprite support.

    So, I started a port of Adafruit::NeoMatrix to FastLED and wrote FastLED::NeoMatrix. It was actually a non trivial port, which took much longer than I thought, but I got it working in the end:


    by then I was already able to display with 3 data lines, one for each 32x8 panel
    by then I was already able to display with 3 data lines, one for each 32x8 panel

    In the process, I managed to plug the wrong power into the panel and blew a pixel. Thankfully I was able to borrow another pixel from a strip and soldering it in place to fix it:


    Once the port was done, came time to get the panels together. Wiring was a bit challenging because I had to ensure that power was injected at a mostly equal value in 9 different points (3 per panel) due to voltage sag at higher amps. I then quickly found out that with 3 data lines at high frequency, there is cross talk between the wires, so I switched to a CAT-5e cable where each data line is twisted with its ground and the remaining 2 wires are used to bring VCC (5V). Technically my 3 panels can use up to 60A at 5V at full power. Obviously many things will melt before that, and I'm using a power converter that tops out at 10A. Even 10A is too much for the wiring, but thankfully my displays don't use that much brightness (it would be blinding to people):


    two 5Ah 16V lipos give about 160Wh, just enough to run 2 panels 10 to 12H
    two 5Ah 16V lipos give about 160Wh, just enough to run 2 panels 10 to 12H

    the fancy energy meter keeps track of how much time I used and how many Ah came out of the batteries. Useful to know how much time I have left. The blue meter is amps at 5V (after the power converter) and the red one amps at 16V (straight from the battery)
    the fancy energy meter keeps track of how much time I used and how many Ah came out of the batteries. Useful to know how much time I have left. The blue meter is amps at 5V (after the power converter) and the red one amps at 16V (straight from the battery)

    on the right, I have a backup ESP8266 if the main one fails, a backup BEC (5V converter) that's technically 10A capable but not meant to do more than 5A continous, and bottom right is my older 3A BEC with in line amp meter
    on the right, I have a backup ESP8266 if the main one fails, a backup BEC (5V converter) that's technically 10A capable but not meant to do more than 5A continous, and bottom right is my older 3A BEC with in line amp meter

    the new tobsun 5V converter is bulky but does 10A without issues
    the new tobsun 5V converter is bulky but does 10A without issues

    For the back of the shirt, I got some fabric and created an inside pocket to hold the panel:




    it then mirrors the front
    it then mirrors the front

    All this crap goes into a fanny pack, and gets wired to my shirt, pants, and glasses:



    the cool part is that my back also has a panel inside the shirt that uses the shirt as a diffuser
    the cool part is that my back also has a panel inside the shirt that uses the shirt as a diffuser

    You can get the code I wrote for the shirt here: https://github.com/marcmerlin/NeoMatrix-FastLED-IR

    This video shows an early version of the code working on a desk:

    This video shows the animations:

    While this video shows the tech a bit more:

    2018/04/23 FastLED::NeoMatrix library: how to do Matrices with FastLED and Adafruit::GFX
    π 2018-04-23 01:01 in Arduino
    I've been a fan of Neopixels and Adafruit's Neomatrix library since last year. Why is Neomatrix special? It allows you to create Neopixel matrix displays and treat them like a panel display on which you can apply Adafruit::GFX primitives.

    The problem is that https://github.com/adafruit/Adafruit_NeoMatrix only supports the https://github.com/adafruit/Adafruit_Neopixel backend which in turn only supports neopixels, and only in a serialized fashion. Serialized means that if you have 1024 pixels (32x32 matrix), it takes about 35 to 40ms to send a single frame, which means you can only update at a 25fps rate, which is not that good.

    https://github.com/FastLED/FastLED fixes this by offering support for a lot of different kinds of LEDs, but also for offering parallel output on multiple MCUs, allowing you to get up to 16x faster updates by segmenting the strip to update sequentially. It also offers much nicer primitives like automatic fading, and the ability to have multiple independent strips of different lengths that can display different patterns.

    Neomatrix is aweseome since it offers access to the GFX library primitives (circles, lines, rectangles, and fonts), but since it didn't work with a FastLED backend, I ported it to FastLED.

    You can get the code here: https://github.com/marcmerlin/FastLED_NeoMatrix
    You can also see my NeoMatrix Shirt on this page


    Hello world
    Hello world

    Thanks to Adafruit::GFX, it's easy to display fonts and bitmaps
    Thanks to Adafruit::GFX, it's easy to display fonts and bitmaps

    32x32 is slightly better to display bitmaps
    32x32 is slightly better to display bitmaps


    This will be the display on my shirt
    This will be the display on my shirt

    GFX allows drawing lines, circles and all
    GFX allows drawing lines, circles and all

    Fonts can be of any size
    Fonts can be of any size

    2018/01/22 Lolibot, FPGA Primer, MicroPython for ESP8266/ESP32 and Protocol Analysis at Open Hardware Miniconf at Linux.Conf.au 2018
    π 2018-01-22 01:01 in Arduino, Linux
    Got to play with a lot of hardware at LCA 2018:
  • ESP32 micropython programmed robot
  • Learned the very basics (and pains) of how to program an FPGA
  • MicroPython programming and handling
  • Protocol Analysis (1wire) with a USB protocol sniffer.
  • Definitely worth the time I spent, even if some miniconfs made me miss a bunch of talks, but it was worth it :)

    Lolibot:







    our fearless team was honest about how they do the work every year :)
    our fearless team was honest about how they do the work every year :)

    The next day, I went to the FPGA training/miniconf:


    Bunnie Huang was one of the attendees
    Bunnie Huang was one of the attendees

    FPGAs are definitely 'interesting', you can use some of the gates to emulate a CPU, and others to run bare metal code
    FPGAs are definitely 'interesting', you can use some of the gates to emulate a CPU, and others to run bare metal code

    It was useful to learn more about MicroPython the next day, definitely a faster way to work on ESP8266/ESP32 SOCs:


    ESP32
    ESP32


    Tim nicely setup a hardware rig to flash the little TOMU boards that fit in your USB slot:


    The last day, we learned how to use a USB logic analyser to debug 1wire timing issues:


    protocol analysis is what Tridge eats for breakfast ;)
    protocol analysis is what Tridge eats for breakfast ;)


    More pages: April 2019 March 2019 January 2019 July 2018 May 2018 April 2018 January 2018 June 2017 April 2017 January 2017 February 2016 January 2015 September 2013 January 2012 December 2011 May 2011 January 2011