[Noisebridge-discuss] Big LED Screen - potential upgrade?

[nils at shkoo.com]

On Sat, 11 Apr 2009, d p chang wrote:
>>>> nils at shkoo.com writes:
>>>>> If you're interested in more of the technical details you can check
>>>>> out the wiki page:
>>>>>
>>>>> https://www.noisebridge.net/wiki/Big_LED_Screen
>
> the wiki made it seem that there was something downstream of the shift
> registers that you're not using. this got me into the mode of thinking
> of the whole shebang as 'controller'.

Yeah, it's kinda tough to explain with just text.  Hopefully the pictures 
help some.  If you have any ideas for how the text can be improved, please 
go ahead and edit it.  It *is* a wiki after all. :)

>>> w/ your dma idea, are you thinking of building a controller in front of
>>> the existing controller or replacing the shift register stuff completely?
>>
>> It would be a lot of work to replace the shift register stuff
>
> yeah, but 'simpler' on the control side for dma :-).
>
> something still has to the toggling of the shift registers, the work is
> moving from the initiator to the target. that's the only reason i was
> wondering about what was going be the dma target.

The DMA would run between the RAM and be the SPI controller within the ARM 
chip.  The SPI controller could then clock out all the bits at 2Mhz and 
the CPU doesn't have to get interrupted to do a context switch 250,000 
times a second to write out a new byte.

>> If you're asking as to whether I'd want to replace the boarduinos with
>> an ARM, then yes.
>
> gotcha.
>
> unless i missed something else in the pictures (thanks for that) two spi
> on an arm isn't going to replace two boarduinos since you have to change
> the spi chipselect for the halves. spi seems fast enough though

The halves don't actually talk full SPI; they just have a data line, a 
clock line, and a strobe/latch line. (Though conceivably we might be able 
to point the chip selects at strobe/latch).  So we would have to put in 
some simple logic to interpret the chip select and send the serial clock 
to the right half, which is just a couple of transistors that we can wire 
by hand.  We need to add voltage translation anyways since the shift 
registers are all 5V logic.

If we were to use the beagle board with the two SPI interfaces, we would 
not actually have to use the chip select pins since there wouldn't be 
anything else hooked up to that SPI bus that we would need to worry about. 
We would just use the SPI interfaces for their ability to push serial data 
on one pin with a serial clock on another.

> (although maybe not for nice refresh).

I think you misunderstand. The refresh speed is fixed at about 500Hz.  We 
have to have the new bits shifted in before the circuity that came with it 
cycles over to the next power source.  Otherwise the next bank of LEDs 
will get lit up without the right data in them, which manifests itself as 
vertical streaking.  We can not control the refresh speed unless we 
replace the old buffer board, so we *have* to clock out fast enough if we 
want to display anything coherent at all.  This timing requires us to 
clock out at least at 1.5Mhz (with an upper bound of 3.3Mhz, since that's 
the maximum the shift registers are rated for).

I also uploaded a schematic to the wiki in case you're interested in what 
all is connected to what with the 2 boarduino solution.  (I think I missed 
the pull-up resistors on the TWI bus, but the schematic should be at least 
mostly correct).

-nils

> in another message on this thread:
>
>> On Fri, 10 Apr 2009, Andy Isaacson wrote:
>>> On Thu, Apr 09, 2009 at 09:49:14PM -0700, nils at shkoo.com wrote:
>>>> Does anyone have any input relating to this stuff or ideas of good boards
>>>> to use?  Does anyone want 99 of those sparkfun SAM9-L9260 boards so we can
>>>> get the bulk discount? :)
>>>
>>> I think this is a cheaper way to get an AT91:
>>>
>>> http://www.opencircuits.com/Linuxstamp
>>>
>>> (haven't looked if its SPI ports are reasonably configured, though.)
>>
>> The at91rm9200 only has a single SPI port.  However, it does make the
>> pins available.  And, as far as I can tell, the only thing the
>> linuxstamp uses SPI for is the flash
>
> one thing to look out for is that arm parts have a small number of boot
> options and sd/mmc usually isn't one of them. i'm not sure which would
> be easier to either of these boards: 're-route' spi after boot or attach
> some other boot source (i2c or dfu or 8bit flash).
>
> \p
> ---
> If everybody is thinking alike, then somebody isn't thinking.
> 		--- George S. Patton, Jr.
> _______________________________________________
> Noisebridge-discuss mailing list
> Noisebridge-discuss at lists.noisebridge.net
> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss
>