No support for panels stacked up high instead of wide?

[marcmerlin]

With 12 panels, with 3 chains of 4 panels of 128x64, I need the chains to be 128x256 (4 panels of 128x64 on top of one another) I'm not sure the mapper function allows this, and if I go 4 panels wide, I get 512x64 x 3 = 512x 192 when I'd much rather have 128x256x3 = 384x256. Is that possible at all with existing --led-pixel-mapper options ? (it didn't seem like it) If so, am I stuck having to write my own mapper as per https://github.com/hzeller/rpi-rgb-led-matrix/tree/master/examples-api-use#remapping-coordinates ?

[marcmerlin]

[hzeller]

Yes, writing a pixel-mapper would be the way to go https://github.com/hzeller/rpi-rgb-led-matrix/tree/master/examples-api-use#writing-your-own-mappers

Ideally, we had a generic mapper that parses some configuration string describing the layout; something like a newline separated format describing the physical layout with each line with panels represented as square-bracket enclosed <parallel-pos>:<chain-pos> text in it, possibly with a modifier (one of <, ^, v, '>') to describe in which direction the data cable is plugged in; so your layout could be something like

[0:0<][1:0<][2:0<]
[0:1<][1:1<][2:1<]
[0:2<][1:2<][2:2<]
[0:3<]]1:3<][2:3<]

I've not implemented such mapper yet, I'd like to leave that as an exercise to whoever needs it first :)

[marcmerlin]

@hzeller thanks for confirming, and smart man about leaving this as a programming exercise to the reader :) I'll see if I can con myself in yet another rabbithole / yack shaving (I have enough for a few sweaters by now). If you are curious, this all started with:

• a 24x32 neomatrix array (neopixels). To get more speed, I had to port Adafruit::NeoMatrix to FastLED, and wrote FastLED::NeoMatrix
• needed "a few" more pixels, so I had to switch to SmartMatrix, but the API was all different, so I had to write SmartMatrix::GFX to put the same API on top of SmartMatrix
• I'll save you what I learned and had to work around on, regarding ESP32 memory management
• 96x64 was nice, but maybe a few more pixels would be better, so I had to switch to your driver, but of course, the API was all different still, and didn't work on arduino, so I had to port the arduino environment to rPi so that the same code could be run
• and then a new glue driver FastLED_RPIRGBPanel_GFX, to allow the same API and arduino code still with your driver

• you are here <

It's actually a bit more complicated if anyone is interested somehow, just wrote this for someone else:

Low Level Drv|Glue Driver for FrameBuffer::GFX
FastLED     - FastLED_NeoMatrix  -------------\     FastLED CRGB Array 
SmartMatrix - SmartMatrix_GFX -----------------\    24bit FB storage        API Support
ILI9341 \                                       \   CRGB methods like
SSD1331  |--- FastLED_SPITFT_GFX ----------------\  scale8/fadeToBlackBy   ,FastLED API
ST7735  /                                         |        |              / (XY 2D to 1D mapping)
                                                  |        |             /
ArduinoOnPc-FastLED-GFX-LEDMatrix arduino         - FrameBuffer::GFX------ Adafruit::NeoMatrix +
emulation for linux / Raspberry Pi:               |        |             \ Adafruit::GFX APIs
----------------------------------               /    Adafruit::GFX       \ 
rpi-rgb-led-matrix - FastLED_RPIRGBPanel_GFX ---/   LEDMatrix (optional)   `LEDMatrix API
ArduinoOnPC X11/linux - FastLED_TFTWrapper_GFX /
FastLED_SDL (linux)   -  FastLED_NeoMatrix   -/                        

I still have a fair amount of work left in the arduino port to rPi, including porting the file API somehow. This will probably have to come first.

[hzeller]

Ah, and you need to support http://spixels.org/ of course :)

[marcmerlin]

@hzeller nice, I didn't know about that. So, I already have a fully working ESP32 which likely costs less than your board, and does neopixels without problems (there is actually an impressive driver that can do 80 parallel lines of neopixels doing multiplexing on pins using DMA I2S output), and it also does IR. Given that those are non trivial on rPi (or at least more work), I'll probably keep the ESP32.
That, and also the fact that the active3 board with 3 chains of ABCDE panels uses every single IO pin except serial input, doesn't it?

[marcmerlin]

@hzeller I was looking at a more basic issue. If I have 3 panels of 128x64, and make a chain of 3, your library decides that I mean 384x64 and not 128x192. In theory U mapper should work for this. Instead of >>> I could get

>
<
>

but it looks like U-mapper wasn't really meant for this, was it? Without worrying about the shortest cable length, it would be easy/helpful to have the library take an argument for "stacking" which would default to horizontal: >>> And the argument could change it to vertical

>
>
>

But if not/in the meantime, Z-mapper referenced in https://github.com/hzeller/rpi-rgb-led-matrix/pull/980 might (without the parallel support just mentioned) might work

I'm just trying to find where the default mapping is done when not overriden by pixel-mapper.cc

[hzeller]

The U-mapper maps each chain forward-backward, so the display is half as long but double as high (also with parallel). The size of the final matrix is adjusted accordingly, so your program then sees the new pixel size.

The place where that is applied happens here: https://github.com/hzeller/rpi-rgb-led-matrix/blob/master/lib/led-matrix.cc#L271

[marcmerlin]

@hzeller Thanks much for the pointer to the right place.

Also, U-mapper indeed gives me a clue that it won't work a U-mapper for 1 column wide: root@rPi3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-row-addr-type=0 --led-chain=3 --led-show-refresh --led-slowdown-gpio=1 --led-pwm-bits=7 --led-panel-type=FM6126A --led-parallel=1 -D0 --led-pixel-mapper=U-mapper U-mapper: Chain (--led-chain) needs to be divisible by two

It works for --led-chain=4, but given that it doesn't take a geometry input, it guesses that I want 2x2 and not 1x4. Anyway, that's a reminder that I need to look into making my own mapping, short of having to write the multi-mapping parser you eluded to.

[hzeller]

There is only one arrangement that satisfies the U-ness of a chain of a particular lengh: it will be half long and double high; this is why it does not need more geometry input. You could add a parameter 'folds' (default 1 for 'U-ness') which would go back and forth number of fold times.

There are some pull requests (#657) which are roughly like that (but they contain some unrelated changes and do a non-backward compatible naming). If you keep the U-mapper name and add some fold-parameter to it, that could be a winner.

[marcmerlin]

Ok, there you go: https://github.com/hzeller/rpi-rgb-led-matrix/pull/1009

I didn't quite get sucked into modifying U-Mapper since that was more work and currently my panels are wired with longer cables with everything pointing in the up direction, so U-Mapper would have broken me anyway

[marcmerlin]

[marcmerlin]

@hzeller I made another matrix, which as luck would have it, was 15 (number of free panels I happened to get donated by the nice folks at Azerone). Looks like this:

The natural orientation for them was 3x5, which meant another set of 3 parallel chains with 5 panels going up, but to use the very short cables I had been stocking and never use it, every other panel is upside down. I'll need to make a Vmapper that's either called Vumapper, or find a good way to give a parameter to say that every other panel is upside down.

Do you have a preference?

[hzeller]

It sounds like a parameter to the V-Mapper might be more natural.

[marcmerlin]

https://github.com/hzeller/rpi-rgb-led-matrix/pull/1014 ready for review: added Z configuration of vertically stacked panels.