Difference between revisions of "StrichLux"
From Hackstrich
(Adding POWERCTL instruction, updating status.) |
(Status update.) |
||
Line 2: | Line 2: | ||
== Project Log == | == Project Log == | ||
+ | * 2012-07-14: Connectorized the rest of the channels, tests successful on one channel at a time. Still only have one [[StrichLux/IO-SPI|IO-SPI]] module built, so can't test more than one channel at once yet. | ||
* 2012-07-13: Regression testing at the lab was successful, but only have channel 1 connectors mounted, so couldn't test more channels. Will test today, hopefully. | * 2012-07-13: Regression testing at the lab was successful, but only have channel 1 connectors mounted, so couldn't test more channels. Will test today, hopefully. | ||
* 2012-07-12: Completed the 4x4 crossbar that should allow multi-channel fanout mode via TAKEOVER command. Will test next time I'm at the lab. | * 2012-07-12: Completed the 4x4 crossbar that should allow multi-channel fanout mode via TAKEOVER command. Will test next time I'm at the lab. |
Revision as of 04:19, 15 July 2012
The StrichLux Modular Lighting Controller will control various kinds of lighting via various protocols/interfaces, or convert between two of the supported protocols/interfaces without directly controlling any devices.
Project Log
- 2012-07-14: Connectorized the rest of the channels, tests successful on one channel at a time. Still only have one IO-SPI module built, so can't test more than one channel at once yet.
- 2012-07-13: Regression testing at the lab was successful, but only have channel 1 connectors mounted, so couldn't test more channels. Will test today, hopefully.
- 2012-07-12: Completed the 4x4 crossbar that should allow multi-channel fanout mode via TAKEOVER command. Will test next time I'm at the lab.
- 2012-07-07: Full system is working end-to-end in one-channel mode. Next up is implementing multi-channel fanout mode.
- 2012-07-04: Read/write on CORE now works, IO-ETH successfully takes Art-Net packets and writes to the framebuffer, and it can be read back via SPI. IO-SPI not successfully reading yet, still working on it.
- 2012-07-02: Integration testing started, IO-ETH initializes properly and negotiates with CORE. Read/write still not working, more troubleshooting tomorrow.
- 2012-07-02: Firmware mostly functional, integration testing starts today on Core board, IO-ETH, and IO-SPI .
- 2012-05-27: Core board, PWR-DC5, and IO-ETH all sent off for PCB manufacturing.
- 2012-05-20: IO-DMX module is transmitting, core board is finished being designed/laid out and will go to manufacturing next week. PWR-DC5 Power Module is being designed and will go out for manufacturing at the same time as the core board.
- 2012-04: Status updates for individual I/O module are being tracked on each module's page.
- 2012-03-17: Completed BOM, schematic, and layout for DMX I/O module and I/O Breakout module. Both submitted to Laen for PCB manufacturing.
- 2012-03-13: Defined I/O Link connector pinout, started putting together BOM/schematic for DMX I/O module.
- 2012-03-12: Chose connectors, laid out basic core board interface components/defined sizes.
- 2012-03-06 - 2012-03-11: Defining specs, searching for appropriate parts.
Project Ideas
- Core Board, lets you plug in up to 4 input modules and 4 output modules plus an optional Power Module
- Each of the 4 would be up to one DMX universe worth of channels (512)
- SPI slave to each I/O module, 8 SPI slave transceivers total
- RS232 for troubleshooting and configuring the core board itself
- Local framebuffer memory
- Dual-port memory would be best so the output and input sections can both deal with it independently
- 8 bits per frame * 512 channels per universe * 4 universes = 16kbit (2kbyte) of framebuffer memory required
- Twice that for double-buffering would be awesome, so 32kbit/4kbyte of dual-port memory wanted
- Split into 4 channels, so each block would be 8kbit/1kbyte
- Reading/writing needs to happen in parallel for each block
- CPLD/FPGA seems a great fit for this
- Lattice LFXP2-5E-5TN144C or Xilinx XC3S50-4VQG100C both seem like good fits
- Since this will likely be the most powerful chip in the whole system, we could do transforms here to to take the load off the I/O modules
- HSV->RGB
- Input splitting (one input channel goes to two or more output channels)
- Input combining (two or more input channels get combined via some function and go to a single output channel)
- Scaling/offsetting (0-255 in = 32-64 out or such)
- Power Modules
- Stack underneath the Core Board, provide high-power busses for directly powering lighting from the system.
- Location makes sense because it doesn't block hot-swapping the I/O modules, but may be a thermal problem as it will get hot and heat up the Core Board
- Input-Only Modules
- Analog input channels (not 512 though, likely)
- Output-Only Modules
- LPD8806 LED strips
- Other LED strips
- Discrete power switches (relays/FETs/whatever)
- I/O Modules
- DMX
- Art-Net over Ethernet
- Art-Net over WiFi
- Dimensions
- Core board will be 3.95" x 6.25" (max limits of EAGLE Standard, purchased for this project)
- Modules will be 1.525" x 1.925" (2x4 layout on the board for input/output x 4 channels)
Protocol
- Modules are SPI masters, Core Board is SPI slave (x8)
- Simple read/write commands compatible with SPI SRAMs for easier testing/bring-up
- Commands
- 0000 0000 - NOOP - Do nothing
- 0000 0001 - Reserved - Write STATUS on SPI SRAMs
- 0000 0010 - WRITE - Write data to active "control" framebuffer
- Argument 0 - Starting address
- No return value
- Further clock cycles auto-increments the address pointer and continue shifting in new data
- 0000 0011 - READ - Read data from active "control" framebuffer starting at a set location
- Argument 0 - Starting address
- Further clock cycles auto-increments the address pointer and continue shifting out data
- 0000 0100 - READNEXT - Read data from active "control" framebuffer at the next pointer location
- No arguments
- 0000 0101 - Reserved - Read STATUS on SPI SRAMs
- 0000 0110 - GETLOC - Get data about the location of this module
- No arguments
- Return value: XXXX SSST
- T = Slot type (0=input, 1=output)
- S = Slot number (1-4 currently)
- X = Reserved (ignore)
- 0000 0111 - SETPTR - Set the address pointer used for READNEXT
- Argument 0 - Address to set pointer to
- No return value
- 0000 1000 - GETVER - Get CORE version information
- No arguments
- Return value 0: Protocol version (starts at 1, increments by 1 every significant change in protocol)
- Return value 1: Firmware version high-byte
- Return value 2: Firmware version low-byte (starts 1, increments by 1 every release
- Return value 3: Hardware revision (0 if unavailable)
- 0000 1001 - TAKEOVER - Take over another channel's framebuffer
- Argument 0: Channel number to take over (0 = back to native channel)
- Return value 0: Result (0 = success, nonzero = failed to take over)
- 0000 1011 - POWERCTL - Turn on/off the high-power busses
- Argument 0: Power control byte: XXXX XXSB
- B = Bus (0 = A, 1 = B)
- S = State (0 = Off, 1 = On)
- Argument 0: Power control byte: XXXX XXSB