#ws2812

Due to my mandatory rest, I haven't had the time to work on something interesting to blog about. Of course this happens every once in a while, and so my usual solution is to just go through my recent Ali Express deliveries, to see if there is something I can either get up and running, or kill with some magic smoke.

Soon I found a suitable candidate: the ATTiny10. This tiny guy contains a 12Mhz 8-bit micro controller with 1024 bytes of flash memory and 32 bytes of ram. Of course a micro controller is a bit boring without any in- or output, so i wanted to combine it with an other recent delivery: A WS2812B addressable RGB led in a 2020 package. Together with some 0.2mm enameled wire this can be a pretty fascinating micro-project.

To make the soldering a bit doable, I put some kapton-tape on my workbench, sticky side up. This allows me to keep both component in place while I try to reach the limit of my soldering skills.

First, let's connect some wires to the ATTiny10. With a macro lens in front of my iPhone's camera, it looks like it's huge. Unfortunately it's still roughly the size of my soldering iron's tip.

Let's start the surgery. Please be quiet, and don't breath to much or else we need to start all over again.

After a few burned fingers, too much soldering flux and to my own surprise I managed to connect wires to all six pins.

And a few minutes later, I managed to solder the WS2812 as well. Just a few more soldering joints and the programming header will be connected as well. This should allow me to program the ATTiny10 using the USBasp programmer.

And here it is! The end result! An illuminated led! Great isn't it?! OK! See you next time!

Ok, ok. I'm going to be honest here. The reason the LED is illuminated is just because I managed to add some "noise" data on the data line when I touched the micro controller while it was powered on. So nothing more than a lucky shot.

Of course I still need to program the ATTiny. But here's the catch: It turns out the ATTiny isn't supported by PlatformIO. So I had to revert back to the dreadful Arduino IDE.

David Johnson-Davies wrote a nice post on how to program the ATTiny10 and even supplied the necessary files needed to do so using the Arduino IDE. But as you can see, in the screenshot above, I ran into an error.

Now, to be honest I don't know what causes this issue. It might be one of the following:

The USBasp I'm using is damaged or doesn't support the necessary TPI protocol. (Unlikely)

The ATTiny isn't connected correctly, maybe do to a bad soldering connection. (Still a bit unlikely)

I overheated and damaged the ATTiny when I soldered the connections. (Sounds a bit more likely)

I'm doing something wrong with the software. (Sounds likely)

I'm still not fully recovered and missing something completely obvious. (99% sure this is it)

Of course I could have spent a week trying to solve this. But that would mean yet an other quiet week on my blog. So, instead I just end this write-up with a big anti-climax.

If I'm able to solve this issue in the coming two weeks, I'll report back in my next blog. If you have any suggestions or pointers to a solution, leave them in the comments down below.

VSCode has been my code editor of choice for quite a while now. Microsoft did a great job in developing a light weight but super powerful code editor. And with the advent of a PlatformIO VSCode extension, this makes for THE perfect Arduino IDE.

That being said, It's time to start working on the final firmware. Or actually: the final firmware for now. Because the Activity Board will probably be a project which will receive some (software) updates over time.

All the board's functionality will be seperated into a bunch of controllers. There is no particular reason why I called them controllers, It just sounds like I know what I'm doing. For now, the code consists of the following 5 controller classes:

InputController: Responsible for reading all the switch states by communicating with the MCP23017 over I2C.

SevenSegmentController: Controls the 7-segment display by communicating with the MAX7219 seven segment display.

NeopixelController: Controls all the WS2812B RGB-LEDs using the FastLED library.

LedController: Controls all the regular LEDs (incorporated in some of the buttons) using the Arduino GPIO pins.

CommunicationController: Sends JSON commands (like the buttons state updates) to a Raspberry Pi using the ArduinoJson library.

All of the controller classes have a setup() method which is called in the main.cpp setup routine, and most of the controllers have an update() method which is being called during the main run loop.

All of the update() methods are non blocking, to make sure the Activity Board stays responsive. Any necessary delays are implemented by using the elapsedMillis library. But every so often, I just simply count the update ticks to check if I need to do something.

if (tick++ % 100 == 0) { // do something every 100th cycle. }

Most of the controllers are pretty straight forward, and are just there as an easy to use wrapper for the respective libraries. The only controller that is a bit more exotic, is the InputController. To be honest, this controller gave me some headaches.

Don't interrupt me!

The MCP23017 I2C IO expander is capable of firing interrupts whenever one of the inputs changes. Because of this, I connected the two interrupt outputs of the MCP23017 to the Arduino interrupt pins (Pin 2 & 3). It turned out I only needed to connect one, since the MCP23017 can mirror the interrupt signal on both pins. Luckily this was just resulted in a redundant connection, and didn't caused any issues.

Unfortunately there was a bigger problem which I didn't forsee. While the MCP23017 is capable of triggering the Arduino's interrupt pin(s), I'm not able to read out the pin states in the interrupt service routines, since I2C uses interrupts itself, which aren't available in the interrupt service routines.

This means I can set a flag to request an update in the main loop, but I can never act on any input change in the service routine itself. Now for most of the inputs this is absolutely no problem, but for the rotary encoder I really need to check the state for both pin A and B. Now, if these two pins were both connected to the two different MCP23017 registers, I could have solved this with the two Arduino Interrupt pins. Or better yet. If I would have just connected the Rotary encoder directly to the Arduino's interrupt pins, it would have been even easier. But of course ... I didn't.

So after a lot of grumbling, I decided to give up on the interrupts for the rotary encoder (for now), and simply read out the MCP23017 data every run loop. I might mean the encoder wouldn't react as expected, but I could always make some hardware modifications later.

And with taking this easy route, reading the MCP23017 state was pretty straight forward, using Mizraith's fork of the Adafruit MCP23017 library:

// Initialize the library. Adafruit_MCP23017 mcp; // Configure the MCP23017. mcp.begin(); // Use default address 0. mcp.setGPIOABMode(0xFFFF); // All ports input. mcp.setGPIOABPullUp(0xFFFF); // All ports pull up. // Read out the 16 bits. unsigned int newState = mcp.readGPIOAB();

And then it turned out I spent way to much time in overthinking it. Since non of my other controllers is blocking the main run loop, fetching the current state up the buttons every loop is easily fast enough to handle any rotary encoder input. Once again, it turns out KISS is the best approach: Keep It Simple, Stupid!

And with that issue out the way, it was a matter of hooking up all the controllers in my main.cpp file. Whenever an input change, execute an action for that specific input.

This setup really enables me to easily add more actions to any of the buttons. Now and in the future.

And by sending any input change as a json object over the serial port, I can continue using the inputs in my future Raspberry Pi implementation.

For now, it just resulted in one awesome looking activity board with a lot of light effects!

Enjoy the show!

Now, if you are interested in all the fine detail of the code, you can check out the full source code on GitHub. Of course it's fully supplied with unit and integration tests (NOPE!). And it's fully and well documented (NOPE!). Check it it out in the ActivityBoardController repository!

Read all posts in this series:

Now I must admit, this project is inspired by the awesome, incomparable Mission Control Desk by Jeff High Smith. But since both my budget, space and time is a bit more restricted, I'm going for a more compact solution.

In our living room, we have a Ikea Kallax cabinet with 25 square compartments. My goal is to build a control box, the size of one of these compartments. This way, it has a nice dedicated place in our living room, and doesn't take up too much space.

The control box will be made out of plywood. The front, however, will be made of acrylic sheet. In addition to the holes for the controls, the acrylic will be engraved with his name and decorative linings. With the help of some NeoPixel LED's, I hope to get a cool illumination effect.

Of course the wood will eventually get a paint job, and the inner backplate will get some cool looking decorations as well.

Luckily, my preferred supplier was able to help me source all the necessary parts for this project. It really felt like I was shopping in Charlie's chocolate factory!

To get an idea of the space I have, I took a piece of paper of the approximate size of the acrylic front and layed out the parts I want to incorporate. And although this composition isn't set in stone, it really helps me to visualize the end result.

To give you an idea of the parts I want to incorporate, let's review them left to right, top to bottom:

In the top left you see the main toggle switches. These are the big boys! They have an integrated LED and are protected with a spring loaded cover. Enzo better knows what he's doing when he flips these switches!

Below the big boys, I'll add a rotary encoder. Unlimited rotation and a button press. Of course, we need to get some visual feedback, so I'll add a 12 pixel NeoPixel LED ring around it.

Next up are the simple flip switches. You know, for the casual stuff. In addition to these switches, I'll add 3 female cinch plugs. I'm not sure if I will make these functional, but adding them won't hurt anyone.

The top middle will be prominently occupied by an 8 digit 7 segment display. Besides the count down to the next nuclear launch, it might be able to countdown to Enzo's next birthday.

Of course, a real control center has it's own screen. I'm not sure what I will use to drive it. But this Raspberry Pi screen might be a perfect solution for some serious data representation!

We need some sliding action as well. And this slide pot will make sure Enzo will! Once again, the Neopixels will give the appropriate visual feedback.

The three big push buttons in the top right are tipped as the main contenders to become Enzo's favorites. By default they include a white led, but of course these will be replaced by NeoPixels. Allowing me to make them light up in every color possible.

And last but not least. A bunch of rocker switches allow Enzo to turn off the thrusters, enable the backup power supply and engage the flux capacitor.

Of course, building a serious control board needs a lot of well-thought-out planning. How will I drive and handle all the I/O. How will I incorporate the led lights around the acrylic. What will drive the display? And do I need NASA's approval? A lot of questions to be answered ...

And with one of these questions, you can help me! Because as said, the name of my son, Enzo, will be incorporated into the design. But for the fun of it I want this to be an applicable abbreviation. Something like: Electronic Native Zone Operator. If you have a better suggestion, leave a comment down below and reap that eternal fame!

Read all posts in this series: