Editing Big LED Screen
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
= The Big LED Screen = | |||
=== Overview === | === Overview === | ||
* Dimensions (in pixels) are 128 by 48 | * Dimensions (in pixels) are 128 by 48 | ||
* Originally controlled by a 386; mobo is shot. | |||
* The 386 connects via ISA to a "buffer board" which looks to be a memory buffer and power conditioner. | |||
* The buffer board stores data into a couple memory chips, which are then accessible to the daughterboards which drive the actual LEDs. | * The buffer board stores data into a couple memory chips, which are then accessible to the daughterboards which drive the actual LEDs. | ||
* There are four daughterboards, in two chains of length two. Each of these daughterboards is connected to a single "section" of LEDs (ie: there are four big "sections" of LEDs). Each daughterboard runs a section of 32 by 48 pixels. | * There are four daughterboards, in two chains of length two. Each of these daughterboards is connected to a single "section" of LEDs (ie: there are four big "sections" of LEDs). Each daughterboard runs a section of 32 by 48 pixels. | ||
=== | As of 2009-01-28 I am potentially leaving things connected inside it as I work on it. If you want to work on it, please make sure you either check with me or disconnect the things I added before turning it on. Thanks! --[[User:Shkoo|Shkoo]] 10:04, 28 January 2009 (PST) | ||
=== Motherboard === | |||
Boring. Broken. Did I mention boring? | |||
=== Buffer board === | |||
Tonight (2008-12-30) | Tonight (2008-12-30) I worked from the backend up a bit, but eventually gave up. I then moved to the ISA frontside and worked down, which was far more productive. | ||
The device appears to sit at ISA IO ports 0x180 through 0x183. The addresses are decoded by U51 (74688 comparator), which then hits the OE2 on U52-19 (74541 driver iirc). This is then used to feed U53 and U54 (both 74574 D-flip-flops). These appear to be there to combat fan-out. | The device appears to sit at ISA IO ports 0x180 through 0x183. The addresses are decoded by U51 (74688 comparator), which then hits the OE2 on U52-19 (74541 driver iirc). This is then used to feed U53 and U54 (both 74574 D-flip-flops). These appear to be there to combat fan-out. I'm not entirely certain where these go, but it seemed like they were going into the RAMs. | ||
The low bits of the ISA address selection sit on the rightmost two pins on the top row of the header, SA1 and SA0, in that order (Just hook the connector up and use the multimeter if that's nonsensical). I haven't traced them through yet; I was in the middle of it when my time ran out. They look to run over to the empty chip socket on the right side of the board. Most traces tend to terminate at this chip socket, so most likely we won't be able to use the display logic on the buffer board. | The low bits of the ISA address selection sit on the rightmost two pins on the top row of the header, SA1 and SA0, in that order (Just hook the connector up and use the multimeter if that's nonsensical). I haven't traced them through yet; I was in the middle of it when my time ran out. They look to run over to the empty chip socket on the right side of the board. Most traces tend to terminate at this chip socket, so most likely we won't be able to use the display logic on the buffer board. | ||
=== Daughterboards === | |||
The daughterboards each have qty 3 UCN5832A ([[Image:Ucn5832.pdf]]) 32-bit shift registers (for a total of 96 bits) which drive an array of 32 by 48 pixels (for a total of 1536). The theory is the other end of the LEDs are connected to 16 different power sources, making all the LEDs addressable (96 * 16 = 1536). (The shift register does a current sink) | The daughterboards each have qty 3 UCN5832A ([[Image:Ucn5832.pdf]]) 32-bit shift registers (for a total of 96 bits) which drive an array of 32 by 48 pixels (for a total of 1536). The theory is the other end of the LEDs are connected to 16 different power sources, making all the LEDs addressable (96 * 16 = 1536). (The shift register does a current sink) | ||
Line 49: | Line 40: | ||
9 - GND | 9 - GND | ||
Pin 1 is marked red. When looking into the end of the connector, when the red-marked wire is on the left, odd pins are on top. | Pin 1 is marked red. When looking into the end of the connector, when the red-marked wire is on the left, odd pins are on top. So, the top left pin is pin 1. | ||
The serial is daisy chained together. There are two sets of two daughterboards (four daughterboards total) with 3 shift registers on each daughterboard. So, each chain of shift registers includes 6 shift registers for a total of 192 bits per chain. | The serial is daisy chained together. There are two sets of two daughterboards (four daughterboards total) with 3 shift registers on each daughterboard. So, each chain of shift registers includes 6 shift registers for a total of 192 bits per chain. | ||
(The existing logic shifts out 200 bits instead of 192; we don't know why). | (The existing logic shifts out 200 bits instead of 192; we don't know why). | ||
Line 75: | Line 52: | ||
The shift register is rated for 3.3Mhz, so we could conceivably drive it faster than the 1.5Mhz that it's currently running. | The shift register is rated for 3.3Mhz, so we could conceivably drive it faster than the 1.5Mhz that it's currently running. | ||
== | == Plan of Nils == | ||
=== Short Term === | |||
Hook up arduino to drive one of the chains (two daughterboards, half of the sign). | |||
Use existing STROBE (latch) signal from the buffer board for timing. I'm assuming the STROBE signal indicates when the power shifts to the next of the 16 power drivers. | |||
Ignore serial clock and serial data from buffer board; instead, generate it directly from the arduino. This is possible using the USART on the atmega168 chip. I'll use avrgcc instead of the arduino framework, since the arduino framework won't work fast enough to do this. | |||
The USART on the atmega168 will run in SPI mode, generating both a serial clock and unframed serial data. | |||
Possibly we can connect another pin on the arduino to one of the 16 power driving wires, and run it in input mode. This will allow us to synchronize to the power driving sequence. | |||
Then we can drive a test pattern of some sort to try to figure out how the shift registers and power driving channels map to LEDs, assuming they actually do. :) | |||
=== Long Term === | |||
Get an atmel xmega based solution. It has 4 UARTs that we can use 3 of as following: | |||
* Drive daughter board 1 | |||
* Drive daughter board 2 | |||
* Drive XBEE wireless chip for communication with the outside world so we don't have to deal with running wires through the case | |||
The xmega does DMA to its UARTs so we don't have to waste quite so much CPU time copying bytes out. | |||
Unfortunately none of the atmel xmega series have DIP packages, so it's a bit tougher to breadboard them. TQFP 100 seems like the way to go. | |||
[[ | If anyone wants to mess around with etching a pcb to support this solution (assuming tests on the short term solution go well), let me know. Otherwise I'll send it off to batchpcb, but that takes a few weeks. -[[User:Shkoo|nils]] |