Skip to main content ↑ ↓
Topic: Controller Board for Adafruit's Large RGB Matrix Displays (Read 171348 times) previous topic - next topic

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #30 –
[quote author="EmbeddedCreations"]I wouldn't trust that spec.[/quote]
You're probably right. :)
[quote author="EmbeddedCreations"]The library will support 16x32 (1/8 scan) and 32x32 (1/16 scan) when I release it.[/quote]
Great! That means that a 32x32 P5 (160mm x 160mm) will also work.
On this one http://www.aliexpress.com/store/product ... 05806.html the "D" pin is clearly seen on one of the pictures.

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #31 –
The 32x32 P5 will likely work.  I informally tried P3, P4, and P5 displays with my board.  All worked but on one of them (a P4 in this case) blue and green were swapped.  The silkscreen showed the typical pinout, but the circuitry didn't match the pinout.  That's easily fixed with a header file change.

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #32 –
Quote
I see the 32x32 LED display listed as 1/8 scan. I wouldn't trust that spec.

I stand corrected.  I contacted the supplier and they do indeed offer displays of the same size in both 1/8 and 1/16 scan.  1/8 are slightly more expensive as there are more column driver chips on the board.  Unfortunately I wouldn't expect my library to support that display as is, though it might be possible to modify the code to get it to work.  The tricky thing would be making sure there's enough time to shift 64 updates in the smallest latch cycle.

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #33 –
So, your recommendation is we buy 16x32 (1/8 scan) or 32x32 (1/16 scan), correct?
BTW, thank you for all your efforts!

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #34 –
[quote author="lcunha"]your recommendation is we buy 16x32 (1/8 scan) or 32x32 (1/16 scan), correct?[/quote]

That's correct.  Those are the displays that Adafruit and Sparkfun stock, so that's what I assume most users will have, so I'm supporting just those displays (at least at first).

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #35 –
My 32x32 panel finally arrived. I plan to implement video streaming from a PC via USB or LAN to a Teensy and the panel.

Do you already have some code snippets of your library to share? I would love to test it.

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #36 –
Email me (put together the name and domain in my signature), I have a small group of people that I'll send the beta library to when its ready.  I like the video streaming idea.  Do you know how you might stream over USB?  The VideoDisplay example from the OctoWS2811 library is where I'd start.
http://https://www.pjrc.com/teensy/td_libs_OctoWS2811.html#videodisplay

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #37 –
[quote author="EmbeddedCreations"] I like the video streaming idea.  Do you know how you might stream over USB?  [/quote]

I finished the Arduino version http://http://forums.adafruit.com/viewtopic.php?f=47&t=50115, it allows live streaming from the PC screen. The Teensy version will probably be much cooler, because of the better color depth.

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #38 –
[quote author="MarkusL"]I finished the Arduino version[/quote]

That looks really cool!  I'll make sure to include the backBuffer function in my library.  I didn't realize that function existed until I saw your code.

Are you not using the double buffering to save memory?  The display might look a little better if each refresh contained a full frame.  The Teensy will have enough memory for sure, plus I didn't add a way to disable double buffering.  You'll just call matrix.swapBuffers(false) after receiving all the data for a frame.

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #39 –
An Arduino has barely enough memory for a single buffer. Therefore there is no double buffering. This should not be an issue with the Teensy, as it has 32 times the RAM.

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #40 –
I'm starting to put some actual graphics on the display now that I'm doing less coding and more testing of the library.  I grabbed a weather icon and overlaid a temperature on it, and thought the display driven with 24-bit color did a pretty good job of showing small variations in color on the yellow of the sun and the white fading to black of the clouds.  I loaded in the 12-bit color correction table from the Adafruit library to compare with what the AVR is capable of doing, and you can really see the difference with this sample image.  The camera washes out the white a bit, but you can see the difference along the edges, including part of the image in the upper left that just turns to black at 12-bit.

[attachment=0]

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #41 –
Nice, much smoother gradients!

In the meantime I have also implemented a 24bit version on the Teensy. So far without using DMA. The trick is to prepare correctly interleaved RGB-buffers in advance. Adding DMA should improve this further. The sourcecode is here: http://forums.adafruit.com/viewtopic.ph ... 54#p253154

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #42 –
I could use some feedback!

My "library" isn't a true library yet as the source is just a part of the Arduino sketch.  In packaging the code into an Arduino library, I need to figure out the best way to allocate memory for each display configuration (right now 16x32, 32x32, but in the future more options).  Right now I'm just changing definitions in a header file, but that won't work once it's a library.  Here are the options I can see:

1. User allocates the buffers and passes a pointer as part of the constructor, along with the display size.  PJRC's Octows2811 library is an example of a library that does this.

Here's the user code needed to initialize the library:
Code: [Select]
#include <OctoWS2811.h>
const int ledsPerStrip = 120;
DMAMEM int displayMemory[ledsPerStrip*6];
int drawingMemory[ledsPerStrip*6];
const int config = WS2811_GRB | WS2811_800kHz;
OctoWS2811 leds(ledsPerStrip, displayMemory, drawingMemory, config);
Pros: the user can see the RAM used by the sketch when compiling
Cons: "magic" code needed in the sketch, details that ideally would be tucked away inside the library e.g. "DMAMEM" and "ledsPerStrip*6"

2. Library uses malloc to allocate buffer from the heap inside the constructor.  Simplifying the Octows2811 example:
Code: [Select]
#include <OctoWS2811.h>
const int ledsPerStrip = 120;
const int config = WS2811_GRB | WS2811_800kHz;
OctoWS2811 leds(ledsPerStrip, config);
Pros: it's much easier for the user to initialize the library
Cons: the RAM usage displayed after compilation isn't complete: a significant amount of memory will be on the heap

3. Have a separate library for each configuration.  When packaging the library, create several .zip files like TeensyMatrix16x32.zip, TeensyMatrix32x32.zip that each have a unique header.  The user includes the correct header file in their sketch, matching their hardware.  The library will statically allocate memory based on definitions in the unique header file.  Using the Octows2811 example (configuration is now defined as part of the header file):
Code: [Select]
#include <OctoWS2811_120_GRB_800.h>
OctoWS2811 leds();
Pros: sketch is clean, and RAM usage is complete
Cons: as the library includes more configurations, the user may have to manage many matrix libraries, cluttering up the library list

I'm leaning toward option #3, which can be revisited later on as the number of library configurations increases.  Thoughts?

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #43 –
How about something like option 3, but using #define?
The user places a #define in the sketch and the library header file uses #if defined to branch.
*If* that works only one header file would be needed.

Re: Controller Board for Adafruit's Large RGB Matrix Display

Reply #44 –
Generally, I'd keep it as simple as possible. Most users just want the RGB-Panel to work, and concentrate on other stuff. The few users who have very specific requirements or like to tweak every byte can just modify the library directly. I'd also keep it lean, just adding basic functions like drawPixel(), everything else like drawText() or drawLine() should be in a separate library.

I'd also choose variant 3. Normally it's great to have a library configurable, for example changing the number of pixels. However, in this specific case, there are only two possible options: 16x32 and 32x32. To my knowledge no others exist. And if there were others, they'd have a completely different interface anyway.

Regarding variant 2: I don't think you can guarantee that the memory allocated with malloc() is in the DMAMEM area, so probably this variant is not optimal.

Variant 1: This is great for LED-strips, because users can have a lot of different sizes. However, the panel only comes in two sizes, so this is not really necessary.