[dorkbotpdx-blabber] another LED array question

[David Frech]

Paul: Well, I _was_ thinking of using SPI, but running to five
parallel chains. I don't think there is much software overhead of
doing this. I guess you have to cycle the strobe lines for each chain
after doing the shift, and using sbi and cbi that's 4 cycles per chain
that needs strobing? OTOH, it is just that much more complicated, and
may not be worth it.

Mykle: the technique I mentioned works for any SPI-connected shift
registers. All the chips we're talking about can be driven with SPI.
Maybe the names of the pins differ, but not their functions.

BTW, I figured out the difference between the TPIC595 and TPIC596. The
595, just like its HC cousin, clocks the serial out pin on the rising
(shift) clock edge. The 596 _delays_ serial out by 1/2 clock cycle, so
instead of having a 1 clock cycle setup time and _no_ hold time, the
following chip's serial in has 1/2 clock cycle setup and hold times.
It's a bit more robust to clock skew.

- D

On Tue, Dec 16, 2008 at 6:30 PM, Paul Stoffregen <paul at pjrc.com> wrote:
>
>> ... If we hook them us as three chains of five
>> chips each, and arrange things so that not all sub-chains need to get
>> updated all the time, it's possible to do things quicker, since you're
>> driving shorter chains.
>
> The SPI port is incredibly fast compared to moving bits around in code.
>  It's very hard to beat SPI's speed with one giant long shift chain, even if
> you break the chain into several shorter ones.
>
> If you write this in C using the "normal" way of accessing I/O pins, and
> looping code, it will be much, much slower than SPI (where such overhead
> tends to happen with the SPI is doing the work shifting the bits).
>
> Even in assembly, single bit I/O writes take 2 cycles for fixed data, and
> best case is 4 cycles for variable data (the AVR does not have any
> single-bit move instruction, only fixed-value set and clear).  If you want
> to change a single bit without disturbing the other 7, the fastest way is
> SBI and CBI, and those instructions take 2 cycles.  If you want to actually
> "move a bit", at least one conditional skip or branch is needed, possibly 2
> if you don't already know the bit's value (or didn't spend 2 cycles setting
> it to a known value).  No matter what you do, if your code manipulates
> single pins, it will be a LOT slower.  The only way to change a pin in 1
> cycle is to write to all 8 on the same port.
>
> A really aggressive assembly optimization (that could beat SPI's speed)
> would be to store the data in a format where the bits are already in the
> positions they need to be on the port pins, and a 0 is stored in the bit
> that connects to the clock pin.  Then you could read the byte from RAM (2
> cycles), write it to all 8 pins on the port (1 cycle), set the clock bit (1
> cycle), and write it to the port again (1 cycle).  Reading from the RAM can
> auto-increment the pointer, and of course you'll copy this code many times
> so there's no looping overhead.  That's only 5 cycles!  With 3 shift
> register chains, that ends up being 1.67 cycles per bit, which is slightly
> faster than using SPI (effectively 2.25 cycles per bit) with all the shift
> registers in one giant long chain.  With 7 chains, you'd actually be putting
> out 1.4 bits per cycle (3.15 times faster than the SPI port).... assuming
> you can arrange to store your bits in this funny 7 bit format and not
> factoring in all the CPU time to accomplish that.
>
> Then again, if you can do crazy assembly optimization, you could probably
> figure out some way to get useful work done when you're waiting for the SPI
> port to shift the bits.
>
>
>
>
> _______________________________________________
> dorkbotpdx-blabber mailing list
> dorkbotpdx-blabber at dorkbot.org
> http://music.columbia.edu/mailman/listinfo/dorkbotpdx-blabber
>



-- 
If I have not seen farther, it is because I have stood in the
footsteps of giants.