Mechanical Ideas for Wearable Panel


#21

I don’t think you need to. If you take an array of RGB24, it doesn’t matter how it was generated. People can already use FastLED::NeoMatrix, define an APA102 as the LED backend, and they’re done. No need for you to support anything special.

yes,it’s ironic, I agree, but it’s mostly about reusing existing code as well as being able to write code that can be run on multiple backends.

It does to some extent, but it’s not very hard to just give a 2GB image that is ready to dd with no extra work. sdcard wearing I’m not sure but I’m guessing they’ve mostly taken care of that. It should otherwise be easy enough to turn off any cron job and syslog in the image. That said, yes, there is still a boot time of maybe 5 seconds or a bit more depending on the image.
Form factor: rPi0w is not that big, even if a bit bigger than an ESP32. Power supply, nothing extra needed with a Pi0, it runs with the same power than an ESP32.

It can, the code just tells you not to run faster than 50ns. I took that check out in the code and ran as fast as 8ns before it stopped working. It was simply a command line parameter check based on the fact that the old (i.e. current for most folks) chips don’t work faster than 50ns


#22

8ns -> 125 MHz I assume, that’s blazing fast! I think the ESP32 is limited to 40MHz output through I2S

5 second boot up isn’t bad at all

Have you thought about how to move data quickly from the micro to the Pi? It’s not as easy as it might seem. Teensy 3.6 seems limited to 1MB/sec throughput over USB, which is only enough for 20FPS RGB24 at 128x128 resolution.

If you use an ESP32 which has no native USB it’s even more bandwidth limited. I don’t recall what rate the usb-serial chip and associated UART on the ESP32 can handle, but it’s not great.

Most micros can drive SPI signals with a fast clock, but can’t receive signals as fast. The RPi is probably no exception, and there doesn’t seem to even be a SPI slave driver.

I think best bet for a generic solution after brief research is to use DMA reading of parallel GPIO pins to receive data. You can use shift registers and a counter to convert SPI signals into parallel, I’m prototyping this for my ESP32 adapter circuit. I don’t know if the Pi will struggle with high speed DMA-GPIO both in and out.

Thinking about bandwidth more: RGB24 isn’t enough information in my opinion to send to the Pi if the Pi is refreshing the panels at a >24bpp color depth. I guess the Pi could apply color correction mapping the 24bit color into a larger depth space, but in order to get smooth fades avoiding stepping it would need to interpolate colors for the intermediate frames between the let’s say 30-60 FPS generated frames and the 300FPS refresh the Pi can do (I’m borrowing these ideas from Fadecandy). I don’t think the hzeller project is set up to do that already, but it’s open source and seems possible. (And might already be done, I haven’t studied its features) I think the APA102 protocol with its extra byte per pixel containing a Global Brightness Control value is enough to communicate greater color depth and allow for lower overall brightness without sacrificing color depth. Using that has the advantage of compatibility with existing libraries like FastLED, which I believe already has some limited GBC support and hopefully will have better support in the future.

BTW I ordered the Electrodragon board (cheap shipping option), and I’m giving the RPi a bit more consideration as you might be able to tell, though I’m still leaning toward the ESP32. I think what we’re doing can complement each other so even if we diverge at some point I’m happy to trade ideas here.


#23

This doc from hzeller seems to say the max observed DMA-GPIO speed is around 65MHz, so maybe 8ns is the pulse width not clock rate? Still, faster than ESP32.


#24

rPi 3 is quad code 1.2Ghz vs 240Mhz, so i will be faster :slight_smile:

But the biggest thing is that it can output 3 RGBPanel channels in parallel, tripling the effectiving output on top of having a clock that’s 5 times faster. In theory that means 15 times more panels than an ESP32 can drive (putting aside the totally inadequate amount of RAM on ESP32 for that amount of panels anyway)

Good question. I briefly considered it, and I think right now my plan is to use an arduino layer library to compile my code on linux, and then run it on rPi as if it were an arduino. It’ll then output a FB that I need to pipe into the rPi library which would be running on another core.

You make good points, but honestly this is beyond where I’m thinking right now. I’m not trying to display high quality video, but just colorful demos. If the colors are off by just a bit, not the end of the world.

Your general idea of providing this as an interface is still sound if you can indeed get enough throughput to support bigger panels. I’d say it should support at least 128x256. Is that too much BW in 32bpp? Quick math shows it’s 1Mbit of data per frame. 100fps would be 100Mbit/s…
Or if you want to stick to 128x128 which can be done right now on teensy depending on the panel type, it’s still 50Mbit/s

Totally agreed, please do not let my ideas/plans detract you from what you’re trying to do. There is always a benefit from having multiple solutions, especially if one of them doesn’t succeed as well as planned (which could very well be mine :wink: ).


#25

I’m excited to learn more about that in time!

Probably, I think 128x128 is a reasonable target. I suppose you could chain two adapters together to get 128x256, as you would chain two APA102 matrices. Updating using the APA102 protocol at 30FPS would require using 30MHz SPI. I’m not sure even an ESP32 could generate that much pixel data. Anyway, I’ll start with 128x128, and see what can be done after that.


#26

yeah, that’s a fair point, FastLED::Neomatrix actually makes this trivial, you’d treat each 128x128 as a square tile and let neomatrix do the rest for layout.