For testing, the Pixif was configured to drive a 144-pixel strand with no update frame synchronization.   As shown earlier, this yields an update rate of ~188 Hz.  Because the STM32 has independent DMA support for its SPI Slave there's no impact on the STM32's core processor other than a trivial ~82 kBytes/Second of memory bandwidth (3 bytes per pixel * 144 pixels per update * 188 updates per second).  This leaves all those core cycles for calculating pretty stuff...and slogging through software floating-point calculations!  :-)

To have something interesting to display on the NeoPixels I ported to the STM32 board one of the algorithms from the PICsellator.  Algorithm 5, the "Sine Springboard", is shown here running with a 1 second sleep interval: 

(That's a PICsellator in the background running inside two crackled-glass votives - my version of a Lava Lamp!  ;-)  So I'd consider this in-depth exercise a total success - a simple, efficient, reliable interface to independently handle all the NeoPixel twiddling while my core processor concerns itself only with what to scribble in a simple vector of RGB values in memory.  The key to the whole thing was good DMA Support for the SPI - there's just no substitute for good hardware!  (Except, of course, pain in software... ;-)

I'm thinking now of the next projects: Maybe a board design to incorporate a few Pixifs (with only the 5V power for the level translation being common among them).  That would make it easier to replace the software-floating-point STM32 with a faster, hardware-FPU processor (probably a DSP) having multiple DMA-supported SPI Slaves and then take the next leap in software to drive it all.  The key to success in this will be to study the Data Sheets to ensure that the Chosen One has good, no-babysitting-required DMA support for multiple SPI Slaves.  Any ideas?

One of my favorite hangouts is the Glowy things forum - comments, questions, and suggestions welcomed!