So multiple people have asked me about Neopixels and do I support them. I was so busy looking at other stuff, I simply did not have the bandwidth to look into Neopixels. As the work on SS3 was winding down this Summer, and I started to look into the next generation boards, I thought that I should do some research to make sure that I didn’t preclude their use. In July I did read about them, and even included a wing board to make interfacing with them as simple as possible.
I was originally hesitant about Neopixels because it adds one more layer of difficulty to programming a pinball machine. Right now, the OPP hardware only supports turning on and off lights (either incandescent or LED bulbs). The framework supports turning the bulbs on or off, or blinking the lights slowly or rapidly. The blinking happens automatically in the framework so the user doesn’t have to bother with changing the lights all the time. If I switch to using Neopixels, they are not simply on/off, but now they can support different colors which will be even more difficult to use.
I spent a couple of days trying to figure out the best way to command a “smart” Neopixel controller. One would be to continuously send the color for each pixel, and that would provide all the features. That would use a lot of the bandwidth of the serial links between the boards and is very inefficient.
Instead, I decided to use a byte for each of the pixels. The byte contains a command (turn pixel on, blink quickly, blink slowly, fade quickly, or fade slowly), and a color index which looks up the pixel’s color using a color table. The color table contains 32 possible colors, and of course there will be commands to change the color table as necessary. (Each entry in the color table contains the 8 bits for red, green and blue parts of the color). The blink commands simply turn the pixels on and off with the chosen color in a synchronized fashion. The fade commands go from dark to bright, then back to dark to allow the pixels to pulse.
I’m planning on trying to get the Neopixel code up and running on the PSoC 4200 board this weekend or next. (It really depends on how quickly I can bring up the debugger). I’ll use short button presses to change the color, and long button presses to change the commands to demonstrate that it is working properly.
Here is a concrete example why using the simple generic code that Creator provides will not work and why such code should be avoided. To talk to the Neopixels, the processor uses the SCB SPI bus component to stream the data. The SPI bus will be running at 2.4 MHz to meet Neopixel timing specs (3 SPI bits for every 1 Neopixel bit, matching the Lady Ada Uberguide specs). Every 20 ms the Neopixels will be refreshed. (This is so things such as automatic blinking and fading can happen automatically). That boils down to 9 bytes of data/neopixel * 64 max neopixels = 576 bytes of data/20 ms. (It will support more Neopixels, but 64 seems like a good starting point). The standard functions created by the tool are blocking calls. Blocking calls wait in a busy loop if they can’t put all the data on the Tx buffer. If a solenoid needed to be fired at that time, it couldn’t happen because the processor would be busy updating the Neopixels. Not very efficient at all. Instead, the code will watch for the FIFO empty interrupt and when that happens toss another 8 bytes of info onto the FIFO, and then go back to normal processing. This means that the processing of the Neopixel data is distributed over the 20 ms time period, and latencies for other processing will be reduced.
So why is the name of this post “Get Off My Back.” I’m hoping that either this weekend or next weekend I will have the code up and running, and be able to hand off a demo unit to allow Dave to play with it and see its capabilities. He currently makes replacement backbox lighting mods for Stern machines and does a really nice job. This should give him a very low cost solution so he will be able to make his backbox mods that much more exciting.