User avatar
PeterO
Posts: 6095
Joined: Sun Jul 22, 2012 4:14 pm

Two Pi Toys

Sat Jul 26, 2014 2:03 pm

I've got a couple of new toys recently...

a 32x32 LED array (from SKPang) and a camera board...

Here's a video (Original quality was much better of course) of the first one taken with the second one :-)
http://www.peteronion.org.uk/PiPics/LEDarray2.mpeg

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

tvjon
Posts: 810
Joined: Mon Jan 07, 2013 9:11 am

Re: Two Pi Toys

Sat Jul 26, 2014 2:54 pm

That array looks useful. Are you going to use it as a display for some of your radio software?

Any particular reason you chose mpeg2?

There's even an audio track :)

User avatar
PeterO
Posts: 6095
Joined: Sun Jul 22, 2012 4:14 pm

Re: Two Pi Toys

Sat Jul 26, 2014 3:18 pm

tvjon wrote:That array looks useful. Are you going to use it as a display for some of your radio software?
Unlikely as they are really difficult to drive. They are designed for large outdoor TV screens where they are driven by FPGAs as they need to be continuously scanned/refreshed.

Any particular reason you chose mpeg2?
I've just "upgraded" my desktop machine from Mint 14 to Mint 17 and as a consequence my favourite video editor/format convertor (kino) has stopped working so I had to find something else. openshot seems to be the prefered tool but it is unstable and keeps crashing so I ended up exporting in the first format that actually worked !
There's even an audio track :)
I know !

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
Burngate
Posts: 6453
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: Two Pi Toys

Sat Jul 26, 2014 4:03 pm

PeterO wrote:... a 32x32 LED array (from SKPang) and a camera board...
Any details on the array? How is it driven - what have you connected it to?

User avatar
PeterO
Posts: 6095
Joined: Sun Jul 22, 2012 4:14 pm

Re: Two Pi Toys

Sat Jul 26, 2014 4:19 pm

http://skpang.co.uk/catalog/rgb-led-pan ... -1329.html
http://skpang.co.uk/catalog/32x32-rgb-l ... -1344.html

Sample driver code from here:
https://github.com/hzeller/rpi-rgb-led-matrix

To be honest the software is hard to understand because it's written in C++ which somewhat hides what is actually going on. I think it runs a couple of threads, one to create 32x32 array of pixel data and one to "continuously" scan that array and convert it into bit patterns to bit-bang onto the interface.

I might try to recode it in plain C which will make it much clearer as to what is actually happening. I find that using OO for this kind of low level bit twiddling software results in code that can only be understood by the original author :-( You can't see the bit banging wood of the object oriented trees !

PeterO

PS: I've taken the Axe to the OO trees and now I think I understand how the bit-banging works !

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

Re: Two Pi Toys

Sun Jul 27, 2014 12:12 am

Pretty. Now you just need to add http://www.raspberrypi.org/amys-game-of-life/ ;)

User avatar
PeterO
Posts: 6095
Joined: Sun Jul 22, 2012 4:14 pm

Re: Two Pi Toys

Sun Jul 27, 2014 7:20 am

AndrewS wrote:Pretty. Now you just need to add http://www.raspberrypi.org/amys-game-of-life/ ;)
Way ahead of you on that one :-) But 32x32 is not big enough to do anything really interesting...

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

Re: Two Pi Toys

Sun Jul 27, 2014 12:46 pm

LOL, you always end up wanting more LEDs... ;)

User avatar
PeterO
Posts: 6095
Joined: Sun Jul 22, 2012 4:14 pm

Re: Two Pi Toys

Sun Jul 27, 2014 2:55 pm

AndrewS wrote:LOL, you always end up wanting more LEDs... ;)
Too many is never enough !
Anyway I now have a small C program (~300 lines) that has a display driver thread in it, and simple set/clear pixel functions.
It does not do any PWM to give varying intensities so pixels are only 8 colours Black,Red,Green.Blue,Cyan,Magenta,Yellow,White.
The display thread is taking ~9% CPU time, so plenty left for some game logic in the main thread :-)

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
Burngate
Posts: 6453
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: Two Pi Toys

Sun Jul 27, 2014 4:54 pm

For what it's worth, I've done something similar-ish for Adafruit's 32x16 panel, which seems to be a half-size version of SK Pang's 32x32 panel, using RISC OS.
I managed to get a full 8-bit-per-colour (so 24 bits per pixel) PWM working, which pleased me no end. And using RISC OS's spritefile meant that I could cycle round a set of images quite quickly.

The first (actually more like the 3149th) version had a problem which showed up as a ghost image one line up from the real one, which appeared to be caused by the addressing hardware not changing quickly enough.
The next version (second? or maybe 3150th) cured that by making sure there was a black display line as the first after an address-change. What it meant, though, was that I had to go through each display line 256 times before moving on to the next. What surprised me was that there appeared to be no frame-rate flickering - so it was going faster than 25Hz or so.

There were two drawbacks to it, though.
It's just a non-wimp program, so nothing else can run at the same time. Also, it's running full-tilt - cpu at 100%
Worse, though, is that there's noticable flickering as the OS takes time out to do stuff - lines stay on for longer than they should.

So I'm looking at interposing a dual-port ram to interface between the Pi and the panel, to offload the refresh.
If anyone wants a look, this should work on RISC OS on the Pi
new-16.zip
(20.77 KiB) Downloaded 47 times

User avatar
PeterO
Posts: 6095
Joined: Sun Jul 22, 2012 4:14 pm

Re: Two Pi Toys

Sun Jul 27, 2014 6:37 pm

Burngate wrote:For what it's worth, I've done something similar-ish for Adafruit's 32x16 panel, which seems to be a half-size version of SK Pang's 32x32 panel, using RISC OS.
I managed to get a full 8-bit-per-colour (so 24 bits per pixel) PWM working, which pleased me no end. And using RISC OS's spritefile meant that I could cycle round a set of images quite quickly.
The example code linked to from SKPANG's site is written in C++ and has some slightly undesirable c++ code in the heart of the display driving loop. I've stripped out all the unneeded class structure and I'm now driving what is effectively a 1 bit PWM (on/off) takes ~5% CPU. So several passes through the image data to perform PWM should be easily do-able.

The first (actually more like the 3149th) version had a problem which showed up as a ghost image one line up from the real one, which appeared to be caused by the addressing hardware not changing quickly enough.
Yes, I've had similar problems. It seem to revolve having the bank bits set correctly when clocking in the data though I would have though they only need to be valid for the strobe. :?

The next version (second? or maybe 3150th) cured that by making sure there was a black display line as the first after an address-change. What it meant, though, was that I had to go through each display line 256 times before moving on to the next. What surprised me was that there appeared to be no frame-rate flickering - so it was going faster than 25Hz or so.
Looking on my scope it looks like I'm getting ~20mS frame time (50 frames/second) with the frame draw taking ~8mS. Assuming most of that is being taken by the inter-line delays, then 8 bit PWM should need ~16mS. (8+4+2+1.....) Sounds do-able but I'm not sure how much of the time is fixed and how much I can pair back some of the delays I'm using.
There were two drawbacks to it, though.
It's just a non-wimp program, so nothing else can run at the same time. Also, it's running full-tilt - cpu at 100%
Worse, though, is that there's noticeable flickering as the OS takes time out to do stuff - lines stay on for longer than they should.
Running the display driver in a separate thread with high priority and SCHED_FIFO seemed to make a big difference to flickering.

So I'm looking at interposing a dual-port ram to interface between the Pi and the panel, to offload the refresh.
If anyone wants a look, this should work on RISC OS on the Pi
new-16.zip
I guess it depends on what you want to do with the display. TBH as a simple 32x32 display for some simple games (tetris comes to mind) it seems ideal.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

Return to “General discussion”