Hi,

I wrote a new display-program for a led-matrix. This time for a Hub75 interface.
I think there is none for the Picomite, or am I wrong?
The firmware "PicoMiteV6.01.00b14" is needed, because Peter made some changes for PIO out. Thanks again for that.
All PIO-implementations I found(C,Python..), uses two Pio's. This use only one.
It is a KISS (keep it stupid simple) prog with only 6bit color.
Possible it may be useful or an inspiration.

source and video of a little simple demo in zip.  


Hub75.zip


Albert

Hi Albert,

That is quite impressive work. I learned some new things. What I am not clear about is the synchronisation between PIO and MMBasic.

You are using "autopull" and that means that new data in FIFO is automatically transferred to OSR. It is unclear to me how that is synchronized with the PIO program. Where does it "wait" for the new data to arive ? It needs to sync since you are combining 4 pixel data elements in each fifo word.
Is it waiting at the instruction where you get the last 8 bits from the OSR ?

Similar question to your comment that PIO is stopped at end of the DMA. How ? I know PIO can be started (re-started) by the PIO DMA. But how is it stopped ? Or do you mean that the PIO program is "halted" waiting for FIFO data.

I thank you for your publication of this code. It is good to see, and learn from others.

Volhout

Hi Volhout,

thanks for the recognition.
I think I have learned so much from your explanations about PIO. I am pleased that I can give something back.

In

the OSR will be empty, and here the "autopull" will be done or wait, if no data is present, I think. But that doesn't matter, because the DMA will always fill the FiFo until the number of 32bit words are reached. Then the DMA TX interupt will be fired.

About the "Stop" by triggering the interupt is also a question for me.
When I made a PIO with DMA for WS2812, I have discovered that.
In my thread  

  Quote  

Question about PIO DMA TX interupt

I discuss this with Peter. The trigger is FiFo-empty, although if PIO is working. Now I use there a precalculated Tic. If I could stop it myself in the IRQ-sub, I would be able to spend some time, but it stops alone . PIO stop is not needed.
Here I spend some dummy-data at the end.

They will be never shown, because they contain no EOL.

Albert

Hi ones more,

I expand the program for 128x32 pixel. The PIO-prog need no change, only the arrays must be doubled and the EOF-pos updated. Therefore only a new video to show the possibility of MMBasic and the Pico.
Pico @ CpuSpeed 150000, every 4ms two new rectangels are drawn and packed for the PIO.

Hub75_128x32.zip

Albert

Hi Albert,

I am really impressed with this.

It looks beautiful and is so fast.

I might buy a couple of panels.

Are all/most of those Chinese 64 x 16 panels compatible or do I need to look at specific models?
How is the wiring connected from the Pico to the panel? Ie. pinout.

I have had a look at the code and I am bewildered with it all but then I am pretty simple.
Will you be adding the ability to send text messages and rudimentary graphics to the display?

Once again, well done.

Regards,

Mick (The big one)



.
Edited 2025-09-27 11:23 by bigmik

The comments at the start of his code show its socket pins and the model to search for.

Hi Phil,

Thank you,

That makes sense, I read the bas file on my iPad and the screen looked like this.




Which wasn’t obvious as a pinout.. your view is very clear.

Regards,

Mick



.

Hi Mick,

yes, I will try adding "the ability to send text messages and rudimentary graphics to the display". I just found the thread
uM2(+): 64x32 RGB LED matrix display
from Peter from 2016.
For that I'll have to look at CFunctions and "Loadable Drivers" more closely.
My design for the PIO looks a bit different from that of Peters implementation.
At the moment I only use MMBasic-functions
The "init dispaly" will be no problem, but I use about 3 displaybuffer.
One 64bit-buffer to have the possibility using the optimized array-functions from the MATH-module, then two 8bit-buffer, one used by the PIO-DMA to continuously generate the signals for the display(600Hz could be lower I think) and one waiting for the next "Flush/Update" from "Pack4Hub". Making a "Flush" after every "DrawRectangle" even if it is only a pixel, looks a little bit oversized for me at the moment.

For the clarity of the code, I could made more descriptions if anyone want. I am always up for a discussion about it. As you see in my status, I am a "Newbie" here, in MMBasic and RP Pico.

Greetings
Albert

Hi Mick again,

if you only want some scrolling text or Bmp's, the implementation would be easier.
I then could reuse code from my WS2812-program, shown in the thead
WS2812B LED with picoMite questions  
If you look at the last video, it is a little bit slow and only 48pixel wide, because without PIO at that moment.

Albert

A new version with RGB332 1byte 256 colors, therefore an other connetion plan
prepared for greater displays with 1/32 scan
with a 16er proportional font for text, from my ws2812-project.


Hub75_256.zip

Regards,
Albert

I think the last version.
The Hub75-PIO is unchanged, only the application is expanded to show what is possible with MMBasic.
If the fantastic math and memory functions are used, you get really useful results, still without the need of CFunctions.

Hub75TwoLines.zip



Regards

Albert

Very nice !!
How large is this display actually ? License plate size ?

Volhout
Edited 2025-10-03 23:31 by Volhout

BTW: I love my HUB75.   Thanks for this.

The ones I have a 8" x 8" (20.32cm x 20.32cm)

There are multiple sizes available.  Not expensive if you take the AliExpress route.
Edited 2025-10-03 23:33 by pwillard

Hi Albert,

That is a thing of beauty..

I am still procrastinating over buying a couple of screens, every place I look want more for postage than the screens themselves.  

What is your estimation of the maximum number of pixels that can be supported before either mmbasic reaches its useful limits?

Regards

Mick



.

The shown display are two of the 'ES-P2.5-I Pin2dmd' led panel. As shown in the name it has a 2.5mm Pitch, with 128x32 pixel -> 320mmx80mm.

How many pixels can be displayed usefully by MMBasic?
That is a question what you want. The PIO is extremely fast, also the displays. In the first demo I draw 500 rectangles a second and the displayrefreshrate, the PIO show pixeldata 3 times for the differnt bits of the color, was 600Hz @ 9.7MHz of the PIO. To reduce flicker in the video, I increase that some times to 60MHz. The PIO is not the bottleneck. That seems to be the memory and the calculationtime for the data.
At the moment I use an integer for every pixel. This is useful in order to be able to use the math-functions. They are much faster then loops where you calculate one by one pixel. Unfortunately there are no Byte-Arrays.    
Do you want more layer to program an background to move over or a grid in the front, you need the display-memory doubled or tripled.
How many updates are needed a second. In my application the displaydata for the PIO is double buffered for output. Ones calculated, it will be displayed as long as the PIO run. This contains only 3 bytes for 2 pixel.
But you will display changing data i thing.
The preparing for 4096pixel(128x32) takes about 1.7ms with a RP2350  @200MHz. This must be done after new data are filed in the Work-Array.

I think 128x128 pixel are possible if not all content is complely new arranged. Scroll by only moving the screen could be more.

Regards
Albert

This time a little smaler,
a first little application, or usefull demo for the display-driver (32x64) and only 6bit color.
Inspired by the "Morphing Clock" for this Hub75-panels, I ported it to MMBasic. I have no idea if this has ever been done before.
The animation is not from me, see header in the source. I only changed the code from C and adapt it to my display driver. Very simple and not optimized, I thing for playing with it.

MorphClock.zip



Regards
Albert

Nice !!! I like animations...

Volhout