Difference between revisions of "Led Matrix 32x64"
From Fixme.ch
Line 7: | Line 7: | ||
=== Matrix reference === | === Matrix reference === | ||
− | * size: 64x32 RGB LEDs | + | * size: 64x32 RGB LEDs (127x256mm) |
* organization: 2 blocks (upper and lower) with each 16 lines à 64 LEDs | * organization: 2 blocks (upper and lower) with each 16 lines à 64 LEDs | ||
* (6) 64 bit shift registers | * (6) 64 bit shift registers |
Revision as of 20:52, 4 September 2011
A FPGA-based interface controller for
Limpkin's RGB LED matrices.
Matrix reference
- size: 64x32 RGB LEDs (127x256mm)
- organization: 2 blocks (upper and lower) with each 16 lines à 64 LEDs
- (6) 64 bit shift registers
- input pins:
- R, G, B for each upper and lower: R1, G1, B1, R2, G2, B2; 1 = LED on
- clock (next bit, rising edge)
- latch (latch shifted data to output, rising edge)
- enable (drives LEDs from latched data?, 0 = enable)
- 5V signals
- 40ns period = 25MHz max.
- ~4A with full matrix in white color
- price: ~ 150.- USD
Overview
- FPGA drives 1 or more (up to 4?) matrices
- use block ram or external SRAM for frame buffer storage
- interface with PC
Feature ideas
- double buffering
- larger off-screen buffer + compositing ops?
- character generation
- update only sections
- small CPU core to execute short programs?
Components
Memory
External SRAM needs to be fast enough to handle all reads during one cycle. Per connected matrix we need to read 6 bytes per cycle. Clearly this would require use to run at 150MHz, which is infeasible. If we use a separate chip per matrix block (6 chips or 3 chips with 16bit width), we can still operate with 25MHz.
Concurrent writes need to be possible, but at a lower speed. Either buffer reads and slip in writes when there is slack (complicated), or alternate between reads and writes at higher speed (DDR?).