SPI (Pixel Data) Splitter / Distributor

[David_AVD]

Some time ago in an ACL chat room not so far away, an idea was discussed. I remember that Phil, Tabor and I took part in the discussion, but there were others that I don't recall (sorry guys).

It came about due to the fact that pixel strings and strips have their data input and output connections at opposite ends. Now this is often a good thing, as you can connect multiple sections together to make longer ones.

For radial display items such as mega trees and fireworks (star bursts), this can make the data wiring more fiddly as you need to wire the "data out" of one section back to the start of the next one. It's true that you can reverse every second segment and zig-zag the data, but that also requires the controller or software to reverse them logically. That may not always be an option.

Anyway, the basic idea was to have a small board that had one SPI (pixel data) input and multiple SPI outputs. You would set this board to distribute the SPI data stream in chunks of "X" channels out to to each segment in turn. Each segment would only see the logical block of data it needed. Thus all segments would effectively have "home run" wiring, connected at just the input end.

At the time we thought it might be implemented as an add-on board to the TP3244. Things got busy towards Christmas (as they do!) and the idea languished out there.

The other night in ACL chat, Andrew (MPH) started talking about an idea he'd had for an "SPI Splitter". This reminded me of the earlier ACL chat discussion, so I thought I'd post here so we can throw it around some more. Hopefully this time it won't be forgotten. I can do a diagram if anyone is unsure of what the hell I'm talking about!


EDIT: I have cleaned up this thread as the replies had nothing to do with this subject. Please note that this thread is not related to Andrew's recent discussion in ACL chat. It merely reminded me of the earlier discussion (over 6 months ago) in chat.

 

[jstjohnz]

Random thoughts...

This splitter would have to know the type of pixels connected to it in order to properly interpret and segment the pixel data. That may or may not be able to be determined by analyzing input data. Would this only be compatible with 4-wire strings (clock and data)? Much harder to do for 3-wire strings. Is it envisioned that this would support multiple pixel types?

It would have to be capable of operating at the fastest data rate the controller could throw data at it.

It would have to be able to buffer at least one output string's worth of data to handle the strings that are reversed. So it would have to be able to send to multiple outputs simultaneously (minimum of 2, more if several consecutive strings were reversed, if that is allowed).

It would have to know the length of the individual pixel strings connected to the outputs (assumption that they would all be equal length).

It would have to know which output strings were to be reversed. This parameter could be eliminated if you make the assumption that every other string is reversed, (or reverse is a yes/no option, and if yes it's assumed that every other string is reversed), that also would minimize the amount of buffering capability needed and minimize the number of simultaneous outputs needed.

As a bare minimum you would have to be able to tell the splitter how many output ports were in use. In theory it could then derive string length by looking at the number of pixels in a full data frame and dividing by the number of active outputs.

 

[David_AVD]

The original idea was for very simple processing where:

• Data format is fixed (preset as WS2801 or LPD6803)
• All outputs had the same (preset) logical length

I don't think the reversing comes into it as the whole idea of this unit is to eliminate the need for reversed segments.

I'm sure it could be done with a small (but fast) micro, a small PLD or similar logic.

 

[fasteddy]

Haved you considered support for the 180x IC as well as they have become very popular with many people now using them

 

[David_AVD]

The reason I left out the 180x series is that they don't use a conventional clock line like the others. Having the separate clock line is why implementing this would be relatively straight forward.