|
Forum Index : Microcontroller and PC projects : PIO-Prog for Hub75 display
| Author | Message | ||||
| AlbertR Regular Member Joined: 29/05/2025 Location: GermanyPosts: 86 |
to position 1 "transparent text" In your thread MM-all: Display drivers in Basic in the first post there is the code-part, line 209 else if bcol%<>-1 then 'transparent text if bcol% then to position two "Pio" up to RC12 I use Dim integer Pack PIO make ring buffer Pack,2048*8 'in bytes ... PIO dma tx 1,0,0,Pack(),,,2048*2 '32 bit transfers, do for ever ... now I have to use Dim integer Pack(2049) '2048 + 1 dummy int ... PIO dma tx 1,0,2049*2,Pack(),,,2049*2 '32 bit transfers, do for ever ... |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10646 |
Please try this and report - PicoMiteRP2350 PicoMite.zip |
||||
| AlbertR Regular Member Joined: 29/05/2025 Location: GermanyPosts: 86 |
Hi Peter, thanks for the quick solution. That solve the problem. Greetings Albert |
||||
| AlbertR Regular Member Joined: 29/05/2025 Location: GermanyPosts: 86 |
Hi Kevin, here is a version for the rp2040 with 128x64 leds. There are only RGB222 colors. Hub75User6bit.zip no video Regards Albert |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 693 |
Hi Albert, That's great thank you, I've currently got a problem with the 2350 I was going to attempt to use, but I have several 2040 lying around :-) What firmware version/revision are you testing this with, so I can be sure I'm using the same? Regards Kevin. |
||||
| AlbertR Regular Member Joined: 29/05/2025 Location: GermanyPosts: 86 |
Hi Kevin, you need the rc16 or newer. Regards Albert |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 693 |
Hi Albert, I've got a 2040 running RC17 and the display is wired up and working perfectly with your driver program, I'll have a play now :-) Thank you. Regards Kevin |
||||
| AlbertR Regular Member Joined: 29/05/2025 Location: GermanyPosts: 86 |
Hi together, it should probably be finished by now. I made a generic Userdriver RGB222. You now can config the pixel-parameter by constants. I tested this from 16x32 up to 64x256 with a rp2040 'consts for hub-display Const HubH = 32 Const HubW = 64 Hub75UserGeneric.zip Regards Albert |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 693 |
Hi Albert, I modified your original test program to give a whole screen Red, Green, Blue, so I could check all the pixels, then I ran your new generic test program and you've already added that :-) anyway it works fine, I've also tested it to it's limits and mine workes up to 420MHz, which makes it a bit more zippy. I attempted to change the resolution to 64x64 (obviously my display is fixed at 64x128) just to see what happened, and I got 2 copies of the display, side by side, except the first copy (on left) had a line missing/distorted horizontally in the center, which seems strange, but who knows what it will do? One observation, I've checked my wiring for the HUB75 and on my display the Red and Blue are swapped, so if I use RGB(Red) or RGB(255,0,0) I get Blue and if I use RGB(Blue) or RGB(0,0,255) I get Red? so on my disply the bouncing ball at the start is Blue. I've had a quick look, but is there a way of controlling overall brightness? Regards, Kevin. Edited 2025-11-20 22:19 by Bleep |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 693 |
A video of the display |
||||
| AlbertR Regular Member Joined: 29/05/2025 Location: GermanyPosts: 86 |
Hi Kevin, Thanks for the feedback. The doubling is caused by the shift register. It is not deleted at the end of the line, only the line address is changed. This means that the last line is only shifted by the line length, one line lower. If the display width is appropriate, it is then already pushed out. You can change the colorchannels in function rgb2222 change rgb2222 = rgb222(R,G,B) to rgb2222 = rgb222(B,G,R) because this is allways called if you use User Functions Regarding brightness control: this is not so easy here. The program can only illuminate the last line until the new one has been transferred. This takes different amounts of time depending on the width. I have made a compromise with the parameter here because it is not yet adjustable. It can get a little brighter if the 7 is increased in SM2 .program delay .side set 1 .line next .wrap target Wait 1 irq 3 side 1 'signal from SM-data Nop side 0 [7]'greater val inc brightness max"10"by wide<=64 .wrap 'if more needed-> decrease SM0 with more delays .end program 'list for your 128 wide display, you can also change something in SM1, the "10" is the max value for SM2(actual the 7). If you increase this, you can also increase the value above. .label raw 'output of pixel-data is in SM-data Wait 1 irq 2 side 0 'wait for EOL(EndOfLine) from SM-data Mov pins,y side 1 'Latch out new address(ABCDE) Mov x,OSR side 1 'Latch reload level for the delay of this line .label delay IRQ SET 3 side 0 'max[15]x(10) must be < 150(tested) Jmp x--,delay side 0 [10]'SM-data is working parallel(shift data) Jmp y--,raw side 0 'dec adr for next line Regards Albert |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 693 |
Hi Albert, Thanks for the pointer, RGB now correct on my display and I've found I can set both of those brightness delays from between 1 and 15, so I've set a 'Const br = 10' in my code and use that in both places. :-) Regards, Kevin. |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1312 |
Hi Albert, bin begeistert /I'm thrilled Cheers Martin 'no comment |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 693 |
Hi Alert, I've started to look at your driver, I attempted to create a scrolling message, which works, but as you mentioned is a bit slow, even for a small font. After a brief look it appears that the main culprit for text seems to be the Sub mm.user_bitmap, and for other things Sub mm.user_rectangle, though user_bitmap seems to be the worst, presumably these could do with being converted to C, or have you some ideas for speeding them up? I'll continue to attempt to understand how your driver works, so far it seems to be a bit of a black art (tricky). :-( how did you manage to find out what needed to be done? Regards Kevin. Edited 2025-11-23 06:44 by Bleep |
||||
| AlbertR Regular Member Joined: 29/05/2025 Location: GermanyPosts: 86 |
Hello Kevin, I'll have to take another look at the CSubs. It can be sped up a bit if you use a 2350, which is about twice as fast in the calculations. If you want it to be even faster but don't want to switch to C yet, then write the text function yourself or use one from one of my earlier versions(attention the allway use integer, not bytes for a pixel. They must repacked to 8 after unpack to 1). The fonts used in it are optimized for the “memory unpack” function and make the whole thing faster. Even adapting to the different coordinate system, with the “user functions” starting at the top left (0,0) and the LED matrix at the bottom left, doesn't make it any faster. I've controlled different displays at this low level in the past, but mostly in C. That meant I usually had to worry less about speed. As for this driver here, it didn't just come to me, but grew slowly.For the display there are lots of information in the net, not only for the PIO, but to understand how it works RGB LED Panel Driver Tutorial . Then I slowly ported the handling of fonts, lines, etc. from the WS2812 project to Basic and accelerated it more and more by using MATH and memory functions. In the process, I also created the first PIO program, because the standard output for the Neopixels is blocking and therefore severely limited the number. Assembler is not my favorite, but I have used it in the past, but first time on the Pico-PIO. To quickly process large amounts of data with mmbasic, it is best to use the Math and Mem functions. These can process an entire array in almost the same time as a single command, but they also require a lot of memory. Loops are very slow here, but less memory-intensive. So the whole thing is an iterative process. If you read the thread from begin, there are lots of different versions and those are just the ones I posted.I have tried to keep the comments up to date, but some parts are still from older versions. I apologize for this. I am currently creating a new version that may be easier to understand. If you are interested, I could describe parts of the program in more detail. Regards, Albert Edited 2025-11-23 17:56 by AlbertR |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 693 |
Hi Albert, Yes I frequently use the Math/Memory functions if I can, I used them in my version on Bubble Universe, because they are so fast, I noticed you had used them quite a lot, especially in usr_bitmap, I think you are correct however, the only way to help significantly is a CSub, which could easily be 100 times quicker, but potentially a lot of upfront work to get it compiled and working. I'll wait till you release your new, hopefully 'easier to understand' version, see if I can understand what's happening from that version. Would Peter's CSub, with C source, from a few years ago, for a 64x32 display be any help? and here I imagine it's not driving the display in quite the same way and definitely isn't a Pico. :-( Anyway I'll continue playing and wait for your update, Thanks for persevering. Regards Kevin. |
||||
| AlbertR Regular Member Joined: 29/05/2025 Location: GermanyPosts: 86 |
Hi Kevin, here the new one of the generic "UserDriver" for the HubDisplays. Hub75UserDim.zip To be able to dim the brightness of the display, I made most of the PIO new. I hope it is therefore also easier to understand. For the processing speed, specially scrolling text, you have to use a combination of standard text-functions and self-written code with memory-function. I have implemented a demo for this. A port to CFunction is not currently planned. Possibly a challenge for someone else. Best Regards, Albert |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5485 |
The pico needs to translate every command into a call to ARM code. But after the translation is done, the ARM code runs at CSUB speed. That is why MATH functions are so efficient. A single translate causes a sequence of calculations to be executed. The larger the arrays are you apply the math on, the more calculations are executes, for a single translation of MMBasic command. So do not expect 100x faster execution if it where all C code. For math functions you would be lucky to achieve 10x. But maybe not even that. I estimate 3x is the max you can get. And the PIO driver can be faster than a CSUB can ever be. But the speed is limitted by the speed the data can be send to the display (10MHz ?). Volhout Edited 2025-11-25 06:17 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 693 |
Hi Harm, All the Math functions are for setting up, the slow part is a couple of nested For loops. However Albert has come up with a way of scrolling text by moving strips of the screen sideways left or right using mem copy which is very fast, this potentially reduces the need for a CSub, for basic, simple stuff anyway. :-) Regards Kevin. |
||||
| AlbertR Regular Member Joined: 29/05/2025 Location: GermanyPosts: 86 |
To finish the project here. Just a few minor changes that I noticed when I looked over the source code today. Hub75UserDim_.zip Regards, Albert |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |