Marc's Public Blog

thanks Vic for clueing me in about the event

John is known for always having a great time when playing with a big smile :)

my LED googles were pretty popular

wee :)

People were having fun, we've been caged up for too long ;)

Thanks for John for taking picturs with us at the end

Video summary:

Sure, you can also bike up (and it's a tough ride), but it's a fairly long bike ride back in the dark, so driving was easier.

Beautiful hike with sunset views, we'll have to do it again.

We were early, and had the club to ourselves for a short while :)

Video summary;

The crowd had lots of energy and the nigh was truly enjoyable. Thanks to Pure for the night:

Video summary;

Well, the 5th (and maybe last?) edition of my LCD outfit was a lot of work compared to the previous ones, it took 1.5 years of work during covid to make it happen. Version 4 was described here.

end result after 1.5 years of work

Move to Raspberry Pi

So, easy, I just have to port all my code from arduino/ESP32 to rPi/linux, right? Damn, that's actually a lot of work, and I didn't want to do this, so I was able to do something better, I found ArduinoOnPC, and was able to fork and modify it to add Framebuffer::GFX support and added 3 display outputs:

This combined work allows running my arduino code on linux, mostly unmodified, which means it runs on rPi. Then, the FastLED_RPIRGBPanel_GFX glue driver I wrote to make rpi-rgb-panel compatible with FrameBuffer::GFX, allows running all my 2D code, unmodified and have it sent to RGBPanels through the rpi-rgb-panel driver, I'm glad I didn't have to write :)

So, this is what the prototype looked like now 2 years ago:

I ended up writing this page explaining how others can do the same (run their arduino code on linux). On the way there, I took a small detour, built some RGBPanel frames with "excess panels" (those cost $50 a piece, I have over $1000's worth, ouch), and wrote this page about it: RGB Panels, from 192x80, to 384x192, to 384x256 and maybe not much beyond

ok, that was a nice distraction :)

In the process, I fixed a lot of bugs in all the 2D code I had when I went to a 384x256 panel which obviously overflowed all code that relied on x and y being smaller than 256, and also blew up FastLED code that assumed that there could only ever be 64K pixels :)

While this was a big milestone and proved that my crazy idea running arduino code on rPi using my same 2D library, was possible, there was a lot of work left to do for my outfit, including changing all the code to deal with a much higher resolution, and days (yes days) of work finding close to 200 animated GIFs in the higher resolution, and rescaling them for my non standard 128x192 resolution. Also, all the fonts had to be changed, and a bunch of other stuff, which took months and months of work (all in all over a year):

So, this is what it looks like, ESP32 SmartMatrix 64x96, compared to rPi rpi-rgb-panel 128x192, triple channel. Some gifs, I found the exact one in higher resolution:

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

Other gifs, I found a much better one:

Here is a good video showing the resolution difference between the 2 chips:

Hardware

For wiring reasons, I had a nice trick with the front panels would shift out bits, and I would send them to the back panels with ribbon cables. If you know how RGBPanels work, it does mean that a BCM plane meant to be displayed for an interval t1 in the front, ends up being displayed for an interval t2, when shifted to the back. Because of random luck of the order of BCM planes, it happened to work well enough with SmartMatrix, so it saved wiring for me (no need to splice the output to go to front and rear panels). Unfortunately with rpi-rgb-panel, the BCM planes are displayed in the opposite order it seems, so the output shifted on the rear panels, is visibly not good:

Unfortunately, there is no good fix to this outside of splicing cables, which I didn't want to do, so instead I slightly hacked the rpi-rgb-panel library to shift output bits twice. This is a bit wasteful for refresh rate, but things were fast enough with 3 channels, that I could afford the software hack and losing half of my refresh speed.
Another issue with the ribbon cables is that the active 3 board is wired to have the cable stick up (i.e. towards my belly). I worked with the nice folks at electrodragon to get bare boards without the connectors soldered and looked at how to best make it work for minimal height footprint. Bottom in blue is the original which sticks up the wrong way, upper right is what I would love to have but isn't possible because the traces on the board would have to be rewired (pin order is wrong when the plug is put underneath), so I had to settle with upper right, some angled connectors and I had to move the key hole from one side to the other for the cable to go in the right way.

I really wish I could have done this, but the wire order would be wrong

Then, I also had to protect the panels with my kitchen cutting board sheets that I've been using. It's not perfect, but they act as diffusers and protect the pixels a bit, because the P2 pixels are so small that they fall off if you look at them wrong:

Battery Use

ESP32 - rPi Integration

The rPi can also back-control the ESP32, so when I test at home, I ssh into the rPi, and the rPi uses the serial connection to the ESP32 to tell it what to do, or I can use the web server on the ESP32 and tell it what to do directly.

This means the rPi can work on its own without the ESP32 being needed, except for: - IR input (it's not really necessary, and linux IR code is very different, so it would be a full rewrite) - Wifi commands (none of Wifi code works on linux and would have to be entirely rewritten) - FastLED output would not work well on rPi since it's timing dependent, and also there are no IO pins left on mine with 3 channel output

If I were to re-write a lot of code to make wifi work on linux, that would make the rPi independent and not need the ESP32 anymore (except for the neopixel strips), so I just didn't bother. Also I can brag about having a dual CPU system with synchronization between the chips, which was fun to write and debug.

This bit of video shows how the 2 communicate:

Using Linux integration for development

This shows an example of what it looks like:

Wifi and OmEspHelpers

This is the end result, the main screen allows selecting which demos run (neopixel strips + main screen), at which speed, how bright:

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

The diagnosis screens give more info on the device, and allow editing the config file that selects which demos run by default depending on the screen size, and whether 'bestof' is selected, or not. The config file also allows choosing the order demos run, in:

Demo of wifi:

Glasses

I ended up getting neopixel glasses which had good battery life, but after I dropped them once, a pixel fell out, and that stopped the rest of the string from working. Thankfully I was able to take a spare neopixel from a strip and replace the missing one. I didn't have the right tools or skill, so I was not able to solder it, but I used glue and that worked too :)

LED Shoes

Where is the code?

End result

I got everything somewhat working in April 2021 for a first show (about 1.5 years from when I started), and then worked through multiple electrical and reliably problems (including serial ttyUSB stability issues, and power issues I had to fix by adding a second higher voltage feed to the rPi). Also fixed sync issues between the chips and other improvements in graphics and menus. I considered V5 mostly done and reliable just in time for ADE 2021, EDC 2021, and Dreamstate 2021

I had the outfit mostly working (with a few occasional hardware issues) in time for Creamfields and untold in Aug-Sept 2021:

This even got me on Romanian national TV :)

I had fun at ADE also, and add time to make custom displays for specific events:

Solarstone looks better than his picture, haha

I have some early code that allows me to send text from my phone for special occasions, need to improve the interface:

Future

530€, that might be the highest yet

nice view from our table

Then, finally getting ready for dessert:

original old equipment, not used anymore

a cool artifact is they had an original KG prototype #17, used to verify that the main one, wasn't losing weight

movie that showed how coins are made today

Really cool thing is they showed how coins and medals were made:

an artist was working on this big model

big models

the big model goes on the right, and is used to make the target size small coin model on the left

More rooms:

golden version of the former french coin

5000 Euro coin!

Plenty of more pictures here

Give me the code

Introduction

Later, I found out about Arduino_GFX from Leung CHAN, which is a unified driver for a lot of TFTs of much better quality than the adafruit drivers. There is support for: GC9A01, GC9106, HX8347C, HX8347D, HX8352C, HX8357A, HX8357B, ILI9225, ILI9341, ILI9341, ILI9342, ILI9481, ILI9486, ILI9488, ILI9488, ILI9806, JBT6K71, NT35310, NT35510, NT39125, R61529, SEPS525, SSD1283A, SSD1331, SSD1351, SSD1351, ST7735, ST7735, ST7735, ST7789, ST7789, ST7789, ST7789, ST7789, ST7796
all with a single driver, a single interface, and better speed than Adafruit drivers. Good job Leung, thanks.

Now, why would you use my FastLED_ArduinoGFX::TFT layer, especially when Arduino::GFX has some support for Canvas (equivalent to FrameBuffer?)

See the Framebuffer::GFX that explains support

So, this is why FastLED_ArduinoGFX::TFT is here. If you want more APIs than just Adafruit::GFX, and you want your code to also work on all other supported backends (FastLED Matrix, SmartMatrix, RGBPanel on rPi, or even running directly on linux to write/debug your arduino code on linux with gdb or ASAN memory sanitizer)

This same LEDMatrix demo now works a lot faster thanks to Arduino_GFX copying data to the TFT faster:

This is 24bpp FastLED/LEDMatrix code running on a 16bpp TFT via Framebuffer::GFX

Basic code example

Running Framebuffer::GFX code on a TFT, FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos and neomatrix_config.h

#define ILI9341
#include "neomatrix_config.h"

If you think the file is way too big and hard to understand, you can look at the shorter TFT only version: https://github.com/marcmerlin/FastLED_NeoMatrix_SmartMatrix_LEDMatrix_GFX_Demos/blob/master/neomatrix_config_tftonly.h

Running Framebuffer::GFX code portions of a TFT

This is the end result, you can see that the ILI9341 is spilt in two, the top half is mapped to a framebuffer, the 2nd part uses direct adafruit::GFX rendering through Arduino_GFX:

Multiple TFTs and multiple framebuffers

Arduino_DataBus *bus_[TFTCNT];
Arduino_TFT *tft_[TFTCNT];
CRGB *matrixleds_[TFTCNT];
FastLED_ArduinoGFX_TFT *matrix_[TFTCNT];
uint16_t mw_[TFTCNT];
uint16_t mh_[TFTCNT];
uint16_t tftw_[TFTCNT];
uint16_t tfth_[TFTCNT];
uint8_t gfx_scale_[TFTCNT];
const char *tftname_[TFTCNT];

As a hint:

End result

Video result:

Have Fun!