I've learned quite a bit about NeoPixels through developing Madison's NeoClock and the PICsellator but I wanted to take a step up in processing power.  The PIC was certainly an incredible platform for those projects but I also wanted to work on something a bit more "forgiving" (from a floating-point calculation perspective).  Finally, I wanted to have a simpler interface to the NeoPixels that didn't require as many bit-twiddling babysitting processor cycles.  I've studied a number of different approaches (fancy SPI and DMA tricks with specially encoded memory to create the WS2812 bitstream, etc.) but my little brain craves simple.  So the challenge became, as ever, to use what I've learned to create something I need.  The gauntlet is thrown...

To help develop a wire-wrap MC68000 system I used an STM32-based board (another story for another time) and had studied it enough to feel pretty comfortable using it for my "next step up" in processing power.  The STM32 family has some very nice features, I had already been down the tool-chain cobbling path, and the price was right (already owned!) so the question became how to get from here: 

to here:

I need some sort of simple interface to NeoPixels...a pixel interface...a Pixif!  I had a name!  That's the hardest part, right?  ;-)

The PICsellator showed that I could efficiently drive NeoPixels and have a nice, clean interface in the PIC's memory (basically just a vector of RGB values for the pixels' colors).  How could I now have that simple interface appear in another processor's memory with minimal impact to that processor's (calculation and memory) bandwidth?  My first thoughts were to use the DMA-supported SPI Main in the STM32 to drive a modified PICsellator as a SPI Secondary.  That certainly seemed workable but possibly a bit limiting (no pun!) if I wanted to expand - the prospect of babysitting multiple SPI Mainss and their DMA engine(s) wasn't overly appealing.  How would it go if the pixel interface (the Pixif!) was the SPI Main, ran independently and retrieved its pixels' color data autonomously?  Sometimes it can be very enlightening to turn over a problem and work it backwards...  For me, this was one of those.