#ws2812b

My first guess was that the tiny wires I used to connect the ATTiny10 to my USBasp flasher weren't working, or I damaged the ATTiny10 in my amateur micro soldering attempts.

To test if these were the causes, I soldered an ATTiny10 and a WS2812 2020 to SOP16 breakout board. This allows me to do some testing on a breadboard. It also made the soldering much simpler, lowering the risk of overheating the components.

Unfortunately, this didn't solve the issue. I still wasn't able to upload firmware to the ATTiny. Time to shift the focus to the next suspect: the USBasp flasher.

To program the ATTiny10 I tried using the USBasp flasher I bought from AliExpress. I used this Flasher to program my Electrocards, so I know it works. The only difference between the electrocard's ATTiny85 and the ATTiny10 is that the latter uses TPI protocol in stead of the ISP protocol to be programmed.

After a small Google session, I found the USBasp project website. Besides some interesting technical details, this website also offers the Firmware downloads. And that's where I noticed that TPI support was only available in the newest firmware. Maybe my cheap chinese USBasp included some old firmware? Time for an update!

To allow the USBasp to be updated, JP2 needs to be closed. In this case, the JP2 is on the back of the PCB. Soldering a short wire between these connection points is enough to enable self programming mode.

Next, I used an Arduino Uno as the programmer. To do so, I uploaded the ArduinoISP sketch to the Uno. This sketch is available in the Examples sketches section of the Arduino IDE. Next I connected the USBasp to the Arduino using the following pin configuration:

ARDUINO --- USBasp 5V ------- 2 (VCC) GND ------- 10 (GND) 13 ------- 7 (SCK) 12 ------- 9 (MISO) 11 ------- 1 (MOSI) 10 ------- 5 (RESET)

(Note that the blue led of the USBasp will not turn on after connecting it. I'll get back to this later ...)

To check if the connection is working, I used the following command in my macOS terminal:

avrdude -c avrisp -P /dev/cu.usbmodem14201 -b 19200 -v -p m8

avrdude is a utility to download/upload/manipulate the ROM and EEPROM contents of AVR microcontrollers.

The -c flag specifies which programmer whe are using. In this case the Arduino usni which is configured as an avrisp programmer.

Using -P I specify to which port the Arduino Uno is connected. In my case this is the /dev/cu.usbmodem14201 port, but in your case it might have a different name/path.

Next, I specify the communication speed using the -b flag. In this case 19200 baud.

To get some feedback, I enable the verbose mode using -v.

And last but not least, I specify the type of AVR I want to program. Since my USBasp has a ATMEGA8A, I specify part m8 using the -p. If you omit the -p flag you'll get a list of all supported AVRs.

After running this command, avrdude will try to communicate with the USBasp's microcontroller using the Arduino avrisp.

Great! This works! Time to do the real work: flashing the USBasp with the new firmware. First I downloaded the latest firmware at: http://www.fischl.de/usbasp. In this case the latest firmware was usbasp.2011-05-28.tar.gz. After downloading and extracting the file (by simply double clicking it in the macOS finder) I navigated to the usbasp.2011-05-28/bin/firmware folder which includes the firmware I need: usbasp.atmega8.2011-05-28.hex.

Uploading the firmware to the USBasp is almost the same command as before:

avrdude -c avrisp -P /dev/cu.usbmodem14201 -b 19200 -v -p m8 -U flash:w:usbasp.atmega8.2011-05-28.hex

In this case I've added the -U flag to do a memory operation:

I want to do an operation on the flash part of the micro controller.

I want to write, so I specify the write flash with the w flag.

And most important: I define the filename of the flash hex file (which is in the current folder)

Let's press enter, and hope for the best ...

Yes! It seems it has worked! :) Since the blue led has turned on after flashing, it really feels like something good has happened. LEDs always make thing better, right?!

Now, most important ... don't be like me: don't forget to open/disconnect that self programming jumper JP2 on the back of the USBasp! When it's connected/closed, the ESPasp won't be able to function.

So, after reconnecting the ATTIny10 to the USBasp, it's time for the most exciting part. Will the Arduino IDE, be able to flash the ATTiny10 using the ATTiny10Core?

How about we just select the USBasp programmer and smash that Upload button?

YEAH! It worked! :)

If you want to read more about this flashing process, make sure to read Roger Clark's great post on this subject...

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: