P2 Driver for HUB75 LED Matrix Panels
Stephen Moraco
Posts: 321
I presented a bit of my personal project during our get together today.
This will ultimately become a driver in the P2 Object Exchange after it's working well enough that many of us can use it.
I'm posting this here so anyone can comment.
My git repo ironsheep/p2-LED-Matrix-Driver will be where I publish the status of the project as I make progress.
Once you visit the repo page (which has detailed pictures, project intent, and findings...) you'll see that it also involves a HUB75 hardware adaptor board for our P2 eval board or the new P2 Edge eval board.
No, I'm not sure yet how I'll make these boards available for purchase but it will eventually happen.
This will ultimately become a driver in the P2 Object Exchange after it's working well enough that many of us can use it.
I'm posting this here so anyone can comment.
My git repo ironsheep/p2-LED-Matrix-Driver will be where I publish the status of the project as I make progress.
Once you visit the repo page (which has detailed pictures, project intent, and findings...) you'll see that it also involves a HUB75 hardware adaptor board for our P2 eval board or the new P2 Edge eval board.
No, I'm not sure yet how I'll make these boards available for purchase but it will eventually happen.
Comments
http://www.rayslogic.com/propeller/Programming/AdafruitRGB/AdafruitRGB.htm
I've been hoping to find time to get this going with P2.
I'm sure can do a lot better...
I don't think I needed any extra chips for interfacing with P1...
To be clear, my goal is different than yours and Stephen's. I only wanted to create a simple driver for the 32x16 panel that I ripped out of a pink plastic purse to help a friend with her DEF CON 2021 backpack. I have no need to write a sophisticated driver that will work with any configuration of display. What I want to do is write a very simple driver that newcomers (like my friend) can understand and play with to get excited about programming the Propeller.
This is how simple the Spin2 code is for driving that display (3-bit color) with overall brightness control. Note that I had problems with ghosting until I disabled the output while shifting line bits. Seems odd, but that's what I had to do with my panel.
pri panel_driver(hz, duty) | control, hz1, hz2, t, idx, row, col, signals control := R1 addpins 8 ' colors and scan line pinl(control) pinl(CLK) ' initialize sreg pins pinl(LAT) pinh(OE) hz := (clkfreq / hz) >> 3 ' divide hz by 8 for rows hz2 := hz * gc.gamma(duty) / 255 ' split for brightness control hz1 := hz - hz2 t := getct() ' sync loop timing repeat idx := 0 ' reset to beginning of buffer repeat row from 0 to 7 ' 8 rows per top half and bottom half pinh(OE) ' kill leds while updating repeat col from 0 to 31 ' 32 columns per row signals := row << 6 ' row # signals |= panel[idx+256] << 3 ' bottom half color for column signals |= panel[idx++] ' top half color for column pinw(control, signals) pinh(CLK) ' clock the colors pinl(CLK) pinh(LAT) ' latch new data waitct(t += hz1) ' hold while off pinl(OE) ' enable leds pinl(LAT) waitct(t += hz2) ' hold while onNote that this is still an early WIP and I will most certainly change it before releasing an object for the panel.@Rayman yes I know! I was looking for a project I could use to dig deep into the P2 language, I saw my stack of panels in my "stuff" that will make future projects pile and when I started researching how to drive them I found your code at the AdaFruit site. Thank you!
(1) Emulation of Mechanical Seven-Segment displays
The graphics are being generated in 24-bit color frame by frame. There's an additional 20ms wait between frames so the timing looks reasonably correct. (Could always be better)
In the end, I'm getting pretty good rates for PWM'd screens.
And (2) just the basic start on a highly animated binary clock:
These are just stops along the way to getting to full video frame-rate playback.
Meanwhile, there was excitement yesterday, the adapter PCBs arrived! (everything else kinda stopped...):
The Logic Analyzer shows all the signals looking much, much better than my flying leads...
I'll have to take a look at your code.
Bean
It works, as the levels are sufficient to pass logic reliably for experimentation. However, I suspect it is going to be dependent on the actual hardware on the HUB75 module in question. There seem to be very many out there by this point.
I really would like a couple of these adapters. That would give me some breadboard space back and avoid any concerns about poor-mans voltage conversion. Are you going to make the PCBs or assembled boards available for purchase?
Just a note to others who are playing with import LED panels: The panels are *FRAGILE*. I highly recommend you 3D print a protective frame for them unless you are permanently mounting them in their intended location. I used a basic "box shape" which extended a safety wall around the LEDs by a couple millimeters and wrapped around the back with screws.
Why, yes! ;-). I'm working on sourcing them now. More news in a couple of weeks or so.
Regards,
Stephen
P.S., re levels are sufficient. You are not the only person to report this. However, my driver is running them at ~1000 FPS (3-bit) and that makes for pretty unstable clocking without the level shifters. ;-)
Doc
I got the panels you linked in the live forum call this week, was wondering if you knew when your board will be available for purchase?
I believe they are appearing in the Parallax Store sometime next week.
The panels I have right now are the 64x32 ones you linked, I also have a couple of the larger number of pixel panels on order, but they will be a week or more shipping.
The larger panels are all 1/32 scan instead of 1/16 scan.
I'm getting weird doubled up text. You code prints two lines "Iron Sheep" & "ScrollDemo", but what I see is both those messages on line 0, and also on line 1 (both messages overlapping on both lines). Also the scrolling part below, starts out with both messages overlapping eachother, but eventually I end up with "2nd shorter --" scrolling across both lines 2 and 3.
I get those results if I plug into pins 0-16 or pins 32-48, if I plug into pins 16-32 then it sort of does the same thing except the pixels are oddly garbled like they are bit flipped every few pixels.
The driver chip on the panels is numbered MBI5124GP.
I tried all 3 chip options in the software. The Unknown and FM6124 ones work as described above, the FM6126A one doesn't work much at all just get some random static display of garbage.
Mike
Yep, I can no longer count how many times I've seen displays look strange in some way now...
I reviewed the datasheets for the driver chips on your panels. I have to review the specific timings more deeply but it looks mostly like you need to configure the address width.
The initial driver currently supported only ABDC (4 address lines.)
The new driver, the current "release candidate" on the develop/ branch in my repo supports ABC, ABCD, and ABCDE forms. Please ensure your configuration sets the ABCD form. I think the lines would double, as you see if the ABC form was being used.
Also, the pixels being oddly garbled is a known issue for which I only put in the fix in this latest code. Within the last week, I was able to attribute the issue to the connector being used. That should now just go away with the latest driver version.
Does this help? Please feel free to contact me directly as you work through these initial configuration issues.
Stephen
--
I grabbed the develop version and tried all the combinations of CHIP options, and nothing fixed the issue.
As we run into new chips the display issues that @"Roy Eltham" is seeing may happen. However, as we get most of the common chips identified we'll only experience this on the tails (less popular chips that we haven't yet seen.). So please expect some of this at first.
I will work as fast as I can to get this driver working with the panels this community decides to use. So please contact me directly and I will focus on helping you get your new hardware on the air.
I now have three different board types/chips and all are working well. Every chip type I've encountered I've gotten working including the 64x64 panel (which should now allow the 128x64 panel to work as well. This code is currently on the develop/ branch in the project repo. I have a tiny bit more clean up of the code before I push a single panel release that handles 64x64 and 128x64 (untested, who will be first?) panels.
The driver is fat timing-wise... I have at least three points for enhancing the performance of the pasm code. The first of which is removing all configuration tests from the driver and just configuring code paths during driver startup. Then I think I'll be using the FIFO to read hub ram into the cog buffer, and there is much improvement to be made to the screen to PWM routine (also pasm) notes are already in the code. The first of these improves the line display rate and the last two improve the frame display rates (remove delays between frames.). None of these are as important as just getting us up and running, tho' so this is where my focus has been.
I'm a day or three away from having multi-panel signaling working... it's on my test bench now. But I have two different chip types to check out and it appears both are experiencing different issues preventing multi-panels from working. One symptom affecting both seems to be me just overlooking a clocking issue for which I just need to add a couple of lines of code.
So, my plan, unless this community wishes otherwise, is to awaken multi-panel, then go back to working on timing improvement (outlined above), then move on to better color/grayscale control.
This sound ok?
Regards,
Stephen