9/17/2015, Neopixels, Get Off My Back

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.

Advertisements

2 responses to “9/17/2015, Neopixels, Get Off My Back

  1. It’ll be cool if you get RGB working efficiently and simple. I don’t like the sound of the bus getting clogged with lighting data, a pinball has enough to do already (keeping score, playing sounds, firing solenoids).

  2. The first generation boards run their serial ports at 19.2 Kbps, while Gen 2 will run at 115.2 Kbps. That gives a nice 5x bump up in speed. As you say, I don’t want to clog the data bus with a whole bunch of lighting data which I view as non-critical. During most of the time, the small board will control all of the lights without any interventions from the master controller. (Much like how the solenoids are currently working). It will only be changes that will need to go across the serial link, and I’m pretty sure that I’ve come up with a good method to minimize the amount of that data.

    At 19.2 Kbps, the original boards were plenty fast for the reading input and solenoid status over 20 times a second. Even adding the new lighting information, the new boards should be just as fast if not faster.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s