#attiny10

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.

To check if I was able to control pin 4 of the ATTiny10, I hooked up my Rigol oscilloscope.

So far, so good. I was able to send some pulses. Unfortunately, the WS2812 leds have a pretty strict timing protocol. Since the leds are controlled over one wire, and don't have a clock pin, the data is transferred by a strict timed pulse pattern.

I could go into depth on how these data pulses are built up, but back in 2014 Josh Levine wrote an in depth blog post on how to control the WS2812. This post helped me a lot to figure out what data I needed to send.

To make sure the generated pulses are at the required speed to transfer a bit of data, I needed to fall back to raw assembly code. If this scares you, don't worry. It was my first dive in assembly as well.

Eventually I ended up with the following function to send a bit of data to the WS2812:

void sendBit( bool bitVal ) { if (bitVal) { asm volatile ( "sbi %[port], %[bit] \n" "nop \n nop \n nop \n nop \n nop \n nop \n" "cbi %[port], %[bit] \n" "nop \n " :: [port] "I" (_SFR_IO_ADDR(PORTB)), [bit] "I" (PIN) ); } else { asm volatile ( "sbi %[port], %[bit] \n" "nop \n " "cbi %[port], %[bit] \n" "nop \n nop \n nop \n nop \n nop \n nop \n" :: [port] "I" (_SFR_IO_ADDR(PORTB)), [bit] "I" (PIN) ); } }

It might look a bit scary at first, but it simply turns on the correct pin using the sbi command, waits for a specific amount of operations by using nop (no operation), then turns the pin off using the cbi command, and waits again using the nop command.

The difference between sending a 1 or 0 is the duration of the on and off state:

1: on for 6 processor operations. off for 1 operation.

0: on for 1 processor operations. off for 6 operation.

I figured out these durations by measuring the pulses with my scope, and comparing them to te required durations. In other words: a lot of trail and error.

The WS2812 pixels expect 24 bits per pixel: 8 bits green, 8 bits red, 8 bits blue.

And after a lot of fiddeling, I managed to turn the WS2812 on. Bright green light confirmed my sketchy code worked.

But there was one weird issue: the led didn't respond to the first 24 bits I sent, but to the second 24 bits. In other words: I needed to address led 1, if I wanted to control led 0.

To see if it was just this specific WS2812 that behaved weirdly, I created my own "strip" of WS2812 2020 leds using a piece of 1.27mm breakout board. This way I could hook up 4 more WS2812s to my ATTiny10.

And than the mystery got even bigger: it turned out the WS2812 2020s I was using skipped every 24 bits I was sending. To confirm this, I hooked up a standard strip of WS2812s (5050) in parallel with the 2020s. And indeed, the 2020 pixels seem to skip every 1 pixel index, as seen in the animation above.

I checked to see if this was caused by my own bit banging, or caused by the ATTiny10. But when I hooked them up to a simple Arduino Nano using the Adafruit Neopixel library, the results were the same.

Maybe I just have a faulty batch of 2020s, or I just discovered a glitch in the Matrix. Who knows.

Anyway, since my end goal was to just control the tiny 2020 I soldered directly to a ATTiny10, I could simply address pixel 0 and 1 by sending the 24 bits of data twice. A dirty workaround, but if it works, it works. A few extra lines of wheel code allow me to show a cool color fading effect.

It works ... Awesome!

The combination of the AtTiny10 and the WS2812 2020 gives me a lot of cool ideas. I'm sure I can find something tiny on my dad's model train tracks to illuminate!

If you are interested in the full code I used, check out the gist on GitHub. Keep in mind that this is specifically written for the AtTiny10, so it might not work with other AtTiny models due to different timings.

And if you have any idea why the WS2812 2020s skip every 24 bits, let me know in the comments down below and win the internet!

PS Ibiza, hoop to see you again soon!