Big LED Screen: Difference between revisions

From Noisebridge
Jump to navigation Jump to search
No edit summary
Line 4: Line 4:


* 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)
=== History ===


=== Motherboard ===
* 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" has most traces terminating to a socket with a missing chip, so we don't know what happened here.
==== Buffer board ====


BoringBroken. Did I mention boring?
Tonight (2008-12-30) Josh worked from the backend up a bit, but eventually gave upHe then moved to the ISA frontside and worked down, which was far more productive.


=== Buffer board ===
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.  He's not entirely certain where these go, but it seemed like they were going into the RAMs.
 
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.  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 ===
==== 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 66: Line 64:
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 ==
== Current Operation ==


=== Short Term ===
=== Overview ===


The short term plan is complete.
==== LED Hardware ====


The arduino is hooked up to drive one of the chains consisting of two daughterboards on the right half of the sign.  [[Big LED Screen/ledtest.c | The software]] does not use the arduino framework; instead, it compiles with avrgcc.  The arduino framework doesn't have enough processing power to run fast enough for this application.
The sign is currently driven by two boarduinos on a solderless breadboard.  One controls the left half of the sign, and the other controls the right half.
 
The old hardware buffer board has 16 power sources that it cycles through in sequence.  It goes through each cycle of 16 power sources at about 500 Hz(So it changes power sources every 1/8000th of a second).
 
Each boarduino shifts bits out along a serial line controlling 192 shift registers.  These shift registers act as controllable current-limited drains.
 
The LEDs on the display have their anodes connected to the power sources.  Each anode is shared by 192 LEDs.
 
The LEDs on the display have their cathodes connected to the shift registers.  Each shift register pin is shared by 16 LEDs.
 
This gives us 3072 LEDs per half of the display, which are arranged into an array 64 LEDs wide by 48 LEDs tall.
 
The boarduinos have connections to the preexisting circuitry to tell which power source is in use at any time, and send the respective data to the shift registers for display.
 
We also have an xbee wireless chip onboard so we don't have to open up the sign to talk to it.
 
==== Software ====
 
Though we are using arduino compatible hardware, we are using AVR-GCC to compile native code directly for the atmel mega168 chip on the boarduino.  The arduino framework does not perform well enough nor allow us good access to the atmega168 integrated chip features such as SPI and TWI.
 
We are using lady ada's arduino bootloader.  This acts like an atmel stk500 programmer, and allows us to upload software over the wireless connection.
 
The XBEE wireless chip has virtual transparenet pins configured so we can control the reset pins of the two boarduinos independently, and upload new code to each half of the sign at a time.
 
The two halves talk to each other using the TWI interface on the atmega168.
 
=== Pin connections ===


Here are the pins that need to be connected other than power and ground:
Here are the pins that need to be connected other than power and ground:
Line 87: Line 111:


Unfortunately this has very little processor time to spare since it's spending all its time clocking out the serial data.  We're probably limited to very basic patterns on here.
Unfortunately this has very little processor time to spare since it's spending all its time clocking out the serial data.  We're probably limited to very basic patterns on here.
=== 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
We also need to control our own power, since it's really tough to synchronize based on the existing board's power so we get a bit of pixel leakage.
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.

Revision as of 11:41, 5 April 2009

The Big LED Screen

Overview

  • Dimensions (in pixels) are 128 by 48
  • 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.

History

  • 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" has most traces terminating to a socket with a missing chip, so we don't know what happened here.

Buffer board

Tonight (2008-12-30) Josh worked from the backend up a bit, but eventually gave up. He 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. He's 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.

Daughterboards

The daughterboards each have qty 3 UCN5832A (File: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 receive serial based on the following:

  • The long 10-pin pigtails are as follows:
 1 - UCN-40   CLK (serial clock)
 2 - GND
 3 - UCN-4    STROBE (latch driver)
 4 - GND
 5 - UCN-2    SIN (serial in)
 6 - GND
 7 - UCN-3    GND
 8 - 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. The keyed edge of the connector is also on top. The top left pin is pin 1.

Per Josh, the grounds do not need to be connected for now.

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 10-pin ports between the daughterboards (J3 and J2) are wired differently. J3 is:
 1 -
 2 -
 3 -
 4 -
 5 - ground
 6 -
 7 - clock
 8 -
 9 - serial out (j2) / serial in (j3)
 10 -

(The existing logic shifts out 200 bits instead of 192; we don't know why).

Looking at the sign doing STROBE: sequences 130us apart, within each sequence, 5 peaks @+5V, 4us each high, otherwise the signal is low.

Looking at CLK: We do a bunch of lcokign, the strobe, etc. 8 CLKs in 5us, entire process takes 125us, appx 200CLKs. This gives an input rate of 1.6MHz(!)

The shift register is rated for 3.3Mhz, so we could conceivably drive it faster than the 1.5Mhz that it's currently running.

Current Operation

Overview

LED Hardware

The sign is currently driven by two boarduinos on a solderless breadboard. One controls the left half of the sign, and the other controls the right half.

The old hardware buffer board has 16 power sources that it cycles through in sequence. It goes through each cycle of 16 power sources at about 500 Hz. (So it changes power sources every 1/8000th of a second).

Each boarduino shifts bits out along a serial line controlling 192 shift registers. These shift registers act as controllable current-limited drains.

The LEDs on the display have their anodes connected to the power sources. Each anode is shared by 192 LEDs.

The LEDs on the display have their cathodes connected to the shift registers. Each shift register pin is shared by 16 LEDs.

This gives us 3072 LEDs per half of the display, which are arranged into an array 64 LEDs wide by 48 LEDs tall.

The boarduinos have connections to the preexisting circuitry to tell which power source is in use at any time, and send the respective data to the shift registers for display.

We also have an xbee wireless chip onboard so we don't have to open up the sign to talk to it.

Software

Though we are using arduino compatible hardware, we are using AVR-GCC to compile native code directly for the atmel mega168 chip on the boarduino. The arduino framework does not perform well enough nor allow us good access to the atmega168 integrated chip features such as SPI and TWI.

We are using lady ada's arduino bootloader. This acts like an atmel stk500 programmer, and allows us to upload software over the wireless connection.

The XBEE wireless chip has virtual transparenet pins configured so we can control the reset pins of the two boarduinos independently, and upload new code to each half of the sign at a time.

The two halves talk to each other using the TWI interface on the atmega168.

Pin connections

Here are the pins that need to be connected other than power and ground:

  • MOSI (PB3) - this sends serial data to the daughterboard
  • SCK (PB5) - this sends lcock signal to the daughterboard
  • PB1 - this should be connected to the latch/strobe signal from the old buffer board
  • PB0 - this should be connected to the latch/strobe signal going to the daughterboard
  • PD7 - this should be hooked up to the left side of one of the power sources on the buffer board through a voltage divider (and small capacitor to stabilize the signal) to bring the 15 volts down to 5 volts. Do not use the output of the power source, since it's not nearly as stable.

It uses the existing STROBE (latch) signal from the buffer board for timing, and reads the state of one of the buffer board's output powers to synchronize where in the sequence of 16 power sources. It captures the latch signal and re-emits it to the daughterboard.

It ignores the serial clock and serial data from the buffer board.

Unfortunately this has very little processor time to spare since it's spending all its time clocking out the serial data. We're probably limited to very basic patterns on here.