I’ve finally gotten to dig in to a major rewrite that the FastSPI_LED library has been needing for a while.  The goal is to simultaneously make the library smaller, faster, more flexible, more portable, more maintainable, more easily extensible, and more.

I know at one point I railed against software bitbanging, and for the highest performance, that is still the case.  The new version of the FastSPI_LED library pushes the hardware SPI port up to over 6.6Mbps (up from 5Mbps).  However, if you want to use the SPI port for something else, the library will silently fall back to a bitbanging mode.  Of course, this wouldn’t be my library if it wasn’t fast – and it can push data out at 3.1Mbps when bitbanging.  This is faster than some other code can manage their hardware SPI!

The new library is also more split out into components.  Doing something where you’re writing data out to SPI, but not using LEDs?  You will be able to use the high performance SPI code independently of the rest of the library for your SPI data output (I will add support for reading over SPI in time), and this version of the SPI library will use channel select lines (though you may need to add some hardware to make it all work).

Yes – that was lines plural, up there.  Another feature of the new library is the ability to support multiple chipsets and multiple sets of output simultaneously.  Want to drive a WS2811 strip and a WS2801 strip on hardware SPI and an LPD8806 on software SPI at the same time?  You can.

The chipsets that have no clock line (TM1809, WS2811, UCS1903, etc…) have also gotten some love.  The timing for these chips is not rock solid and consistent.  Even better, I’ve made it dead simple to add support for new chipsets in this style in the future.  I simply instantiate a template with 3 pieces of timing info in nano-seconds et. voila!  Support for new chipset.  By using ns timing values for tuning the code, it also means supporting different clock rates is automatic (avr’s run at 8Mhz, 16Mhz, 20Mhz, and the teensy 3.0 can run at 24Mhz, 48Mhz, or even 96Mhz – now, I don’t need to change code at all to support a new clock speed with a new chipset!)

The library also includes a high-performance pin access library.  Set a pin in as few as 2 clocks (1 clock if you do some setup work beforehand, useful in tight loops, like, say, when bitbanging SPI output!).  Here’s what a simply blink app will look like:

void setup() { Pin<13>::setOutput(); } 
void loop() { Pin<13>::hi(); delay(20); Pin<13>::lo(); delay(20); }

The core code is written and undergoing testing now on the various arduinos I have access to (uno, mega, nano, pro-mini), as well as some arduino derived platforms (have both a teensy 2.0 and teensy 3.0 handy).  I still have some high level support code to make things easier to work with, and then it should be all wrapped up and ready to go.

In addition, over the next few weeks I hope to write up a number of posts describing the various ways that I squeezed nearly every last clock cycle out of the arduino to give you more CPU time to spend coming up with interesting things to paint your LEDs with.

About these ads