Memory Segment Communications Design
Areal Person
Posts: 197
Hi,
I’m building a large LED modular billboard system. I’ve got 1ft.
square panels that will plug together based on the desired size of the
billboard sign. I’m trying to determine how I should implement memory
communications so it’s fast enough to do full static images at least.
I would like to do motion video segments but I’m not sure if I’ll be able to do that.
Each panel has a propeller MCU controller board that controls all the 768 leds which are at 19mm dot pitch spacing. I have 3 leds per pixel One red one green & 1 blue. (That’s 256 pixels)
My thoughts were to build a different style Propeller based Master Controller Board
Which has all the memory for the sign. Each panel would have an address & ID and
Would communicate with the master controller to obtain it’s memory segment address.
It’s clock would then be synchronized by the master controller and the panel would begin to read and display based on the contents of its memory address range.
Before a panel could do anything the images would need to be downloaded to the master controller and loaded into SRAM/FRAM memory.
QUESTION:
Because the master controller could be several feet 10 or more from a specific panel.
I’m concerned that memory image/data transfer would be to slow.
What would be the best design strategy for this type issue? Is there a more
efficient way of doing this ?
and/or
How should I approach designing this ?
Or
Maybe this design is ok? I'm just not sure.
Thanks for the help,
-Areal
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I have a tree growing out of my head, but
what do you expect ? I'm a programmer.
I’m building a large LED modular billboard system. I’ve got 1ft.
square panels that will plug together based on the desired size of the
billboard sign. I’m trying to determine how I should implement memory
communications so it’s fast enough to do full static images at least.
I would like to do motion video segments but I’m not sure if I’ll be able to do that.
Each panel has a propeller MCU controller board that controls all the 768 leds which are at 19mm dot pitch spacing. I have 3 leds per pixel One red one green & 1 blue. (That’s 256 pixels)
My thoughts were to build a different style Propeller based Master Controller Board
Which has all the memory for the sign. Each panel would have an address & ID and
Would communicate with the master controller to obtain it’s memory segment address.
It’s clock would then be synchronized by the master controller and the panel would begin to read and display based on the contents of its memory address range.
Before a panel could do anything the images would need to be downloaded to the master controller and loaded into SRAM/FRAM memory.
QUESTION:
Because the master controller could be several feet 10 or more from a specific panel.
I’m concerned that memory image/data transfer would be to slow.
What would be the best design strategy for this type issue? Is there a more
efficient way of doing this ?
and/or
How should I approach designing this ?
Or
Maybe this design is ok? I'm just not sure.
Thanks for the help,
-Areal
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I have a tree growing out of my head, but
what do you expect ? I'm a programmer.
Comments
The more bits you run in parallel the faster it goes, but the more wire and interface pins/drivers you use.
If you are interested mostly in static images there is a real good shortcut you can take. Slow the interface down to 10 KHz or so (don't laugh speed freaks, I'm serious) and take all the time you want to get everyone updated, but don't display the new data -- just have each panel keep displaying the old data while you upload the new image to all your boards, then send them all a command that says "OK, update now!" From the standpoint of viewers you have a static image that snaps to a new one all at once at whatever interval the interface can sustain.
Unfortunately, it is the largest systems with the greatest bandwidth requirements that will force you to the lowest speeds because of interference, capacitance, common mode voltage differentials, and so on. Fortunately, with the prop doing everything in software, you can crank the speed up until it breaks and then back off to a reliable point. There are tricks like the twisted-wire thing, driving into a resistance at the far end to make it a current signal, multisampling the received bits to reject noise, and so on, but these are a lot of work compared to just lowering the bit rate, and it can be hard to troubleshoot why things still aren't working.
As for the project; it sounds similar to something BTX (I think) did some years ago. I can't find his post at the mo', but here's a video of his screens in use: www.youtube.com/watch?v=1Ki8SUTulV8
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
“Before you criticize someone, you should walk a mile in their shoes. That way when you criticize them, you are a mile away from them and you have their shoes.” - Jack Handey.
Post Edited (simonl) : 5/27/2009 11:04:49 PM GMT