Framebuffer design for big LED matrix

[RFZ]

Hi,
I recently got a 144x36 LED matrix display. It is built of three 48x36 modules wired in series and stacked next to each other. Each module has 12 shift registers controlling 96 colums and a demultiplexer controlling 18 rows. So, physical row 1 and 19 are actually the same virtual row. Shift registers are connected in such a way that the first clock cycle / data gets clocked into the left top LED.
After clocking in one complete row for the whole panel (288 bit), the first bit ends up on the right end on the display at the top led of the bottom half of the panel. The last bit clocked in controls the left top LED of the panel. I tried to visualize that in a picture attached
Now, since I've managed to multiplex this LED Matrix properly with an arduino, I've designed a simple framebuffer to properly put data on the display.

My Question now is, how do I design such a framebuffer? Usually, a framebuffer represents the physical design of a display, right? In my case, the framebuffer should be a byte array containing (144/8)*36=648 bytes. framebuffer[0] to framebuffer[17] representing the top row from left to right of the display and framebuffer[630] to framebuffer[647] the bottom row of the display.

So far so good, sounds reasonable to me...

However, I'm completely clueless if I should send these bytes MSB first or LSB first....

If I send 0x01 MSB first, the top left LED is lit. If I send 0x01 LSB first, the 8th LED of the first row is lit. Now, what should I prefer? 

This is my first experience with displays ever... I want to be able to use third party libs with my display without having to transform the framebuffer they use to the bit layout of my framebuffer. So, is there a "standard" way to do this? I havent actually found much information about how to layout a framebuffer...
Also, if someone knows a ui library for arduino just modifying a framebuffer instead of controlling a specific physical display, I'd be happy If you drop me a link

Thanks!

[Cliff Matthews]

FWIW, I've repaired power supplies inside some panels from Adaptive Micro Systems. They use FPGA's from Altera's Max 7000 series, but programming that is beyond an old fart like me, so I found a tutorial http://bikerglen.com/projects/lighting/led-panel-1up/ so maybe you can see how someone else explains it...

[uncle_bob]

Hi

I think you may have this backwards.

First find the graphics software you want to use. Get it set up and running. It most likely has fixed frame sizes (but maybe not). If it is a fixed frame, your display will be "sitting" in a sub portion of the whole buffer. They already will have a very specific idea of how the buffer should be organized and which bit means what. Your driver code will simply take their buffer and shift it out in a way that your cards can make sense of it.

Bob

[desy2820]

How are you wanting to use this display?
How quickly do you need to change what is displayed?
Do you have any idea how quickly you need to clock the data for a stable display?
How slowly can it be run without flickering or other problems?

Since you have it working with an Arduino, can you use it as your framebuffer/controller?
DATASTREAM--->Arduino--->Displays   Kind of like an smart controller for an LCD display?

I hope this helps.

[RFZ]

Sure, if I plan to use a specific library, like u8glib, I can just have a look how it organizes its own framebuffer and design mine the same way. (but I haven't come so far yet, I just found u8glib but have no idea how its internal framebuffer is used).

But since the arduino already is low on free resources with writing/multiplexing the framebuffer to the matrix fast enough, I may just use it as dedicated display controller and generate the actual data on a different µC and just send it to the Arduino via Serial or I2C connection.

I've already implemented a simple routine writing each byte received on the serial interface to the internal backbuffer and then swapping the frontbuffer/backbuffer once the backbuffer is filled completely... There is no sync at the moment, it relies on error-free communication. It works pretty good.

Maybe I should just look at a popular I2C display and try to implement its command set into my arduino?

And yes, I'm really doing it backwards I have no idea what I actually want to display on the panel, so I thought writing a simple universal controller for it, would be the best thing to do

[Godzil]

What is important is not how to design the framebuffer as it would just bit a bitfield of the whole thing, but how you send this data to the panel.
I strongly recommend to not use segmented framebuffer or the drawing code will need complex math, and you pass more time updating the framebuffer, than sending it to the panel.

So, I would do the complex of transfomation of the framebuffer to how the panel accept data only on the send function.
One good thing by doing that is if your hardware change, you only have the sending to the panel to change and not how your framebuffer is working.

This is an important thing to think about.