ATtiny1634: My ATtiny is bigger (smaller) than yours

The ATtiny1634 microcontroller has an interesting combination of features:

  • 16K of flash memory, the most of any ATtinys (And matching the ATmega168 used in older Arduinos).
  • Up to 18 digital I/O pins (close to the 20 you’d get on an Arduino).
  • Two hardware UARTS (optionally usable as SPI ports), vs. 1 each on an ATmega328 / Arduino.
  • 12 analog inputs (vs 6 on an ATmega328).
  • 4 PWM outputs (vs 6 on an ATmega328).
As opposed to the commonly used ATtiny85 / ATtiny84, the ATtiny1634 is only available in SMD packages. The SOIC package is a bit smaller than an ATtiny84 PDIP package, but if you want a truly small package, the ATtiny1634 is also available as a WLCSP package, squeezing its 20 pins into a 2mm*2.38mm ball grid pac (this could get slightly finicky to handle).

I’ve modified the arduino-tiny core to add support for the ATtiny1634 (Edit: Moved from Google code to Github in 2015). Additionally, you also need an upgraded avr-gcc toolchain. On the Mac, I recommend AVR-Crosspack, which can also be retrofitted into the Arduino IDE. 


Domo Arigato, XBotMicro

From the last Boxtec Freaky Friday, I brought home a purchase I was particularly eager to unwrap: The XBotMicro, a small, Swiss-made robotics platform.

First Impressions

The XBotMicro comes fully assembled, with a set of jumper wires, a handful of plastic standoffs and screws, and a manual in passable, though not always entirely idiomatic, English.

The hardware appears to make a really excellent beginner’s platform:
  • Motors and motor drivers built in, just require two microcontroller pins each side to drive.
  • Front equipped with solid mechanical bumper sensors.
  • LEDs for motors (green/red for forward/backward indicator) and bumpers.
  • Built-in LiPo battery, reportedly good for 2 hours’ driving. Very simple charging circuit—if the + pin sees a 5V voltage, the battery gets charged, otherwise, the battery voltage gets applied to the + pin to drive the installed microcontroller.
  • Easily accessible power switch—one would think this is a complete no-brainer, but some robotics platforms, e.g. the SparkFun ProtoSnap Minibot Kit, require removing the battery to stop the motors. 
  • Separate motor switch: This is a really clever feature allowing a dry run of the programming by observing the LEDs, without powering the motors.
The battery comes pre-charged, and the manual contains a sketch to make the XBotMicro drive forward without needing a controller (although the included jumper wires are too short to implement this sketch).

Adding a Microcontroller

Naturally, for any nontrivial task, one would want to install a microcontroller. At first glance, I thought that pretty much any Arduino board would do—the XBotMicro certainly looks mechanically compatible with them. However, the devil is in the details: When operating in battery mode, the microcontroller has the LiPo battery, typically about 3.7V, available.

The manufacturer of the XBotMicro makes the Diduino, a rather neat Arduino clone with a built in breadboard. While the Diduino works with 5V, it does not have a built-in voltage regulator, which makes it unsuited to input voltages greater than 6V, but gives it much more flexibility toward LOW input voltages, so the Diduino would work well with the XBotMicro. There are also a variety of 3.3V based Arduino boards, most of which should also work.

Update: It’s been pointed out to me that 5V Arduino boards should also work, as long as the input voltage is applied to the 5V pin, not the VIN pin, thus bypassing the voltage regulator.

However, none of the Arduino boards I currently own are 3.3V based, so I had to think of another alternative. I ended up putting a self mini breadboard on the XBotMicro and installing an ATtiny84 on it. Since I already hard the Arduino-Tiny core installed, it was quite simple to adapt the demo code to the ATtiny84 and program it using ScratchMonkey. The breadboard has enough room to even implement a dual-ATtiny84 controller solution if I were to need more processing power.

A Minimalist Controller

Once I had this running, I could not leave well enough alone: Why waste the 12 I/O pins of an ATtiny84 on running the XBotMicro if I could save several cents and use an ATtiny85 instead? The ATtiny85 has just the 6 I/O pins needed to drive the XBotMicro (4 outputs for the motors, 2 inputs for the bumpers), provided the RESET pin gets disabled. This requires programming the ATtiny85 using the High Voltage Serial Protocol, but ScratchMonkey handles this just fine, and indeed, the ATtiny85 is perfectly capable of driving the XBotMicro:

Room for Improvement

It would be quite unreasonable to expect a brand new product like the XBotMicro to already be perfect in every way, so here’s a few minor suggestions for improvement:
  • The language of the manual is not always 100% clear, and there are some typos.
  • I was a bit confused about the A0/A1/A2 pins, initially thinking they were alternate pins for the bumper sensors. The schematics in the documentation are not very clear on that point either.
  • The included jumper wires are very short; perfectly sized if an Arduino board is installed on top, but not very flexible for other pinouts.
  • The demo code is written in French and is structured a bit awkwardly. I’ve taken the liberty of merging it into a single file and translating it into English.

Demo Code

Here’s my version of the demo code, with pinouts for ATtiny84 and ATtiny85 added (in fact, the code is less than 2K, so you could save a few more cents and run this on an ATtiny25, but I didn’t have any at hand).


Using the Arduino IDE with CrossPack

As I’ve started exploring some of the more exotic members of the ATtiny family, I have increasingly been clashing with the fairly old AVR toolchain included in the Arduino IDE. I understand that there is little upside for the Arduino project in upgrading their tools: The current versions support the ATmegas on which official Arduinos are based just fine.

There are, of course, a lot of people simply using avr-gcc and avrdude with makefiles and generic text editors, but personally, the Arduino IDE suits me just fine for most of my projects.

After a few months of replacing bits and pieces of the toolchain, I’ve arrived at a more principled approach, based on CrossPack, a well maintained distribution of up to date versions of the AVR tools for OS X, including patches for the latest processors. After installing CrossPack from the web site, the following script will replace the toolchain in the Arduino IDE with a link to the CrossPack toolchain:


Announcing ScratchMonkey 1.0

Among the sketches bundled with the Arduino IDE is  ArduinoISP, which only becomes relevant once you buy your second Arduino or other AVR processor. ArduinoISP turns an Arduino into a programmer, communicating with avrdude on a PC through the STK500 protocol, and with a  target AVR processor through an SPI based protocol (known as In-System Programming a.k.a ISP).

Earlier this year, I decided to expand on this idea, and ended up writing ScratchMonkey, a more versatile programmer sketch emulating the STK500v2 protocol.

A Better ISP Programmer

ArduinoISP is perfectly well suited for programming other Arduinos, or many AVR processors with factory fuse settings. However, the version bundled with the Arduino IDE has some limitations (some of which are addressed in forks of the standard version, to be fair):
  • Communication speed with the computer is limited to 19200 baud for protocol compatibility reasons. ScratchMonkey is emulating a newer protocol and thus runs at 115000 baud.
  • The protocol used limits flash programming to 16 bit addresses, which prevents programming the ATmega2560 used in Arduino Mega 2560s. ScratchMonkey supports the address extensions needed for larger flash memories.
  • If the fuse settings of the target processor specify an external clock source, it is necessary to supply one i.e. by installing a crystal on the bread board (this is not a problem when reprogramming Arduinos, as the board already contains a clock source). ScratchMonkey provides a clock source by generating a PWM wave on one of the timer output pins.
  • If the fuse settings specify a very slow internal clock source (e.g. the 128kHz internal source available on some processors), or a slow external source is installed on an AVR board (e.g. a 32.768kHz watch crystal), hardware SPI is too fast to communicate with the target. ScratchMonkey automatically falls back to software emulated SPI, which can be made arbitrarily slow if necessary.

High Voltage Programming

With some fuse settings, ISP ceases to be capable of reprogramming an AVR processor: The RSTDISBL fuse turns the RESET pin into a regular input/output pin (an attractive proposition, e.g., on the 8 pin ATtiny85), and the SPIEN fuse can disable the use of the SPI protocol. For such cases, AVR offers a bigger hammer allowing to reprogram the processor anyway: High voltage programming. 
High Voltage Programming (Artist’s Impression)
While the term may evoke images of Tesla or Frankenstein, the reality is considerably more prosaic, involving the application of a mere 12V signal to the RESET pin of the target processor.

Along with this signal, one of two programming protocols needs to be used: AVR processors with fewer than 20 pins use High Voltage Serial Programming (HVSP), a protocol using 4 signals, while processors with 20 pins or more use one of the High Voltage Parallel Programming (HVPP) protocols, of which there are two 15 signal variants for 20 pin processors, and a 17 signal variant for processors with more than 20 pins.

For some reason, most of the open source projects discussing high voltage programming limit themselves to reprogramming the fuses into a state where ISP can be used again. ScratchMonkey, on the other hand, supports full programming functionality for both HVSP and HVPP.

Supported Systems

Both an Arduino Uno and an Arduino Micro were tested as the programmer. Other Arduinos mostly should work as well, but have not been tested. I tested a wide variety of AVR processors as targets:

Top row: ATtiny1634, ATtiny84, ATtiny85
Bottom row: ATtiny4313, ATtiny861, ATmega328, ATmega1284
Not shown: ATmega32u4, ATmega2560 


ScratchMonkey is available on GitHub. An extensive (arguably excessive) manual is also available there.


Open Bench Logic Sniffer with OS X

While trying to debug a High Voltage Parallel Programming experiment and trying to get an idea of the state of the 15 or so signals involved, I decided I had outgrown the ability of my Bus Pirate (which works quite nicely as a logic analyzer, but is limited to 5 channels, 4096 samples at 1MHz, and very simple triggers).

I decided on an Open Bench Logic Sniffer, made by the same people as the Bus Pirate, and working with the same logic analyzer clients. Logic Sniffer allows sampling rates up to 200MHz, and 24K samples with 8 channels, 12K samples with 16 channels, or 6K samples with 32 channels, and much more sophisticated triggers. As my OS X client, I used Logic Sniffer Java client, which by now has pretty much supplanted the original SUMP client for which the Logic Sniffer was designed.

Initial experiments were not entirely satisfactory. It seemed that 8 channel mode mostly worked, but 16 channel mode tended to work only at the 200MHz sample rate, which was too fast for my purpose and only gave me brief snippets of the transactions I wanted to examine (at least, thanks to the advanced triggers, picking those snippets was feasible).

I decided to look for a firmware update, and at this point, the seamy underbelly of the Logic Sniffer ecosystem came into plain view:

  • There is a confusing tangle of web pages purporting to have Logic Sniffer documentation, pointing to obsolete versions of each other, with some of the links just broken.
  • The pertinent information on the web forum discussing Logic Sniffer is distributed across several threads, and it’s not always evident which information is authoritative.
  • Some key tools for upgrading are Windows specific, making life for OS X users a bit harder.
  • The Logic Sniffer authors were not always entirely aware of what the actual manufacturers did with the devices (My brand new Logic Sniffer from Seeed Studio shipped with firmware that was more than 2 years out of date!).
As a result, my upgrade took a rather circuitous route, and at one point had me believe I had bricked my logic sniffer (turns out I had just uploaded firmware into the wrong flash memory region). For future generations, here’s what I now believe are best practices:

  • The most useful starting page for Logic Sniffer is at Dangerous Prototypes (while the Gadget Factory page linked is so outdated that even the “updated” link it contains leads to a mostly broken page).
  • The discussion forum is part of the Dangerous Prototypes Forum.
  • The latest firmware, however, is still hosted at Gadget Factory (Don’t be discouraged by the “Mac OS X coming soon” links—see below).
To actually upgrade the firmware from an OS X machine (most other platforms are quite a bit simpler), I got the following procedure to work:

  • Get the ols-fwloader source from github and compile it (you’ll need to install autoconf through Fink or MacPorts). Most likely, you won’t need to install the resulting tool, but if you do, pick a suitable --prefix:
  • Get the Diolan dummy kext from the discussion forums and install it. You may see some scary looking warnings, but everything’s perfectly safe.
  • Get the “Linux Expert” package from the Gadget Factory download page (latest release right now is 3.08). Change into the OLS_Upgrader directory.
  • Put your logic sniffer into “ROM update mode” by holding the “update” button on the board and then pressing the “reset” button while the “update” button is held. If successful, both green LEDs (ACT and PWR) above the USB connector should be lit.
  • Determine the serial port of your Logic Sniffer, which will be of the form /dev/tty.usb*. Use that port in the code below.
  • Upgrade the FPGA bitstream, and then the Logic Sniffer firmware:
  • Now unplug and re-plug the logic sniffer. Everything should be working.
With the latest firmware, everything seems to work great. The hardware is capable of much more than the software currently supports, but even so, it’s a fairly nice instrument:


Review: Arduino Micro

Boxtec kindly offered an Arduino Micro for review, and I was grateful for the opportunity to add one to my collection.

Physical Design

Although I had seen the dimensions of the Micro on the data sheet, the first view of it was still impressive: The entire Arduino board comes in the size of a DIP-34 package (if such a thing existed). In fact, it is smaller than some AVR microcontrollers (like the ATmega1284 shown here).

Among the more difficult consequences of the tiny size of the Micro is that the pin labels can be fairly hard to read for aging eyes like mine, and since they are between the pins, it’s easy to forget which pin they apply to. Several of the first experiments I built had at least one connection made to the wrong pin, though I expect I’ll get used to the labels after a while.

The top of the board also features the USB Micro B connector. While USB Micro connectors are not uncommon, USB Mini is still a bit more prevalent among Arduinos, and the only Micro cable I had around happened to be Micro A. It pays to check in advance and order either the regular USB Micro cable or the Sparkfun Cerberus cable along with the Arduino Micro — otherwise, your friendly neighborhood retailer will be happy to charge you the price of an Arduino Micro for a connector cable!

A look at the bottom of the Micro shows that the board has components on both sides; the 34 pins are implemented as fairy sturdy male header pins that work great on breadboards. From the dimensions, I had expected that the Micro would also fit into a DIP-40 socket (e.g. so it could be easily inserted and removed from larger projects), but it appears that the pins are a bit too thick to make this possible without employing excessive force.

High Level Features

From the point of view of the Arduino API (digitalRead, digitalWrite, analogRead, analogWrite), the Arduino Micro is straightforward to use and powerful.

Digital I/O

At first glance, one might think that an Arduino Micro offers exactly as many digital pins as an Arduino Uno. However, the reality is quite a bit better than that:
  • The standard serial port of the Micro runs over USB. A hardware port is available on pins 0 (TX) and 1 (RX), but it is possible to use these pins for other purposes while still maintaining a full serial connection to a computer.
  • SPI is run through a separate set of pins (MOSI/MO, MISO/MI, SS, and SCK), which are available as digital pins if not used for SPI.
So while an Arduino Uno has a maximum of 20 pins available, and only 18 if the serial port is used, an Arduino Micro has 24 pins available. This is, in fact, better even than the Arduino Leonardo, which is largely pin compatible with the Micro, because the Leonardo only makes the SPI pins available through the ICSP header, and does not make the SS pin available at all.
A few extra pins may not seem like much, but as I’m currently working on a problem requiring 19 pins (see below), having 20 pins readily available was just perfect.

Analog Input

The Arduino Micro has a generous 12 analog inputs (6 of which are on “analog” pins, and 6 on “digital” pins).

“Analog” Output

There seems to be a bit of confusion surrounding the number of PWM outputs an Arduino Micro has. While the text on boxtec’s site correctly gives the number as 7, the accompanying diagram has 8 pins labelled as “PWM”. Two of those, 4 and 12, are not usable as Arduino analog pins, and pin 3, which is usable, is not labelled “PWM”. So, for the record, the usable PWM pins are 3, 5, 6, 9, 10, 11, and 13.

Low Level Features

If you like to dig a bit deeper into the mysteries of AVR programming, here are some lower level considerations.

Pin Layout

While digitalRead/digitalWrite are very useful abstractions, it sometimes is helpful to access the underlying port registers directly. In particular, it is sometimes possible to change or read up to 8 pins simultaneously. The precondition for this is, of course, that those pins are part of the same port, and it often helps if the physical sequence of the pins is the same as their bit order in the port.

The standard Arduino layout is pretty good at this, with the 20 pins arranged as one 8 bit sequence and two 6 bit sequences. Unfortunately, the Arduino Micro layout (and the Leonardo layout, on which it is based), is a different story altogether: The 24 pins of the ATmega32u4 are spread across 5 8-bit ports, and due to layout considerations, the Arduino boards rearrange pins and pick the occasional bit in the middle for LEDs. As a result, the longest contiguous sequences available are two 4-bit sequences.

Pin Interrupts

Another difference between the ATmega328 and the ATmega32u4 is that the former has a pin change interrupt available for any input pin, while in the latter (and thus the Micro), only 8 of the pins have pin change interrupts, 4 of which are assigned to the SPI interface. In practice, this should rarely be a limitation, but if you expect to be able to get a pin change interrupt on every conceivable I/O pin, that’s not going to work on a Micro.


On a happier note, the ATmega32u4 has a very impressive collection of timers:
  • Timer 0 (8 bit) and 1 (16 bit) appear to have fairly similar features across the entire ATmega line.
  • Timer 3 is virtually identical to Timer 1.
  • Timer 2 (8 bit on ATmega328) does not exist on the ATmega32u4.
But it is Timer 4, a 10 bit timer, that is particularly intriguing. It features no fewer than 6 PWM outputs, arranged in 3 pairs: For each PWM output, its complement can also be made available on another pin. A dead time generator can be set to slightly offset the two signals to introduce times when both signals are 0 (or 1), which appears to be useful for some power switching applications. A fault protection input can turn off the PWM outputs quickly. And finally, the timer can be clocked at an internal PLL frequency of up to 64MHz.

Using the Arduino Micro

Uploading Sketches

The Arduino IDE ships with support for the Arduino Micro in the “Board” menu. The upload procedure is a bit different from the Arduino UNO, and in practice, I’ve often found it necessary to manually press the reset button on the board in order for an upload to succeed. 

USB Support

One of the attractions of the Micro is obviously its hardware USB support. The Arduino software supports emulation of a Serial port, a Keyboard, and a Mouse. All three of these seem to work very reliably, and performance can be downright scary: It’s easy to send so much text to the Keyboard emulation that your computer keeps typing for several minutes after you’ve unplugged the Micro.

As a proof of concept, I built myself a simple mouse, using a SparkFun 5-Way Tactile Switch Breakout board.

Nevertheless, I found that the Arduino libraries make rather conservative use of the USB hardware capabilities available. For instance, I would find it very useful to open a second USB serial port, and the hardware seems to be capable of doing it, but the libraries don’t support it. There also is no built-in support for other USB protocols, e.g. MIDI over USB. One of my future projects will be exploring third party projects like LUFA, which are supposed to be considerably more powerful. 

High Voltage Parallel Programming

One of my current obsessions (and the origin of my infamous 19 pin problem) is the implementation of the various programming protocols available for AVR processors. I’m in the final testing stages of a new programming sketch named ScratchMonkey, and was eager to play with the Arduino Micro as an alternative to the Uno for a programmer.

I’m pleased to report that the Micro performed perfectly in this role. The extra pins allowed me to use a simpler breadboard setup (with the Uno, I had to use an auxiliary shift register for the control signals), and after a few minutes of cabling, I was able to successfully reprogram an ATtiny4313:

Shown here, left to right: A Maxim MAX662ACPA+ charge pump IC to generate the 12V high voltage signal from the 5V input; the ATtiny4313 target MCU, an ATtiny85 left on the board from a previous experiment, and the Arduino Micro.


An Arduino Micro probably should not be the first Arduino to give to a beginner: The small labeling, the finicky upload procedure, and the limited compatibility with Arduino shields are all drawbacks to a certain extent. However, the Micro excels with its breadboard friendliness, its USB capabilities, and a pin count and feature set exceeding most regular size Arduino boards. I highly recommend it as a second Arduino board for owners of a standard Arduino, or as a board for users with previous microcontroller experience.


Overqualified Flashlight

I had an old plastic flashlight with partially corroded innards, and no incandescent bulbs for it, so I decided to turn it into a fancy RGB LED spectacle, controlled by an ATtiny85.

Power Supply

The RGB LED I had needed forward voltages of 3V and more, so keeping the original 2x1.5V C cell power supply was not really viable (apart from the corrosion problem), so I decided to use a 9V battery. However, 9V was outside the operating range of the ATtiny85, so I used a LM317 voltage regulator to adjust the voltage to 3.8V (comfortably within the range of the ATtiny85, close to 3.3V for experiments, and suitable for resistors I had available).

Prototyping & Programming

Breadboarding the circuit was trivial, with my new Bus Pirate serving ably as a SPI programmer. 

Adding the Bus Pirate as a Programmer to the Arduino IDE is simple: In your Arduino projects folder (~/Documents/Arduino on a Mac), add a file hardware/buspirate/programmers.txt:
this will work OK, but quite slowly, as the version of avrdude shipping with current Arduino IDEs includes a suboptimal protocol for talking to the Buspirate. If you download the latest version of avrdude from its subversion repository, recompile, and copy avrdude and avrdude.conf to their corresponding paths in the Arduino IDE, it’s possible to obtain much higher programming speeds (You could also re-flash the Bus Pirate firmware to set it up for the stk500 protocol, but I would not recommend that).

While in earlier ATtiny85 experiments, I used the attiny Arduino cores, I switched to the Arduino-tiny cores this time, because attiny only supported 2 PWM pins on the ATtiny85, while Arduino-tiny supports 3.

The code itself is straightforward, except that since the LED is common anode, it is activated by a LOW output, and by the “inactive” part in the PWM cycle.


I had a SparkFun hex shaped protoboard that fit the flashlight very well. Fitting all the components onto the board was rather challenging, especially since the position of the LED in the middle of the board was not really negotiable. My original plan was to put the LED on one side and the rest of the components on the other, although this added some additional complications for the wiring.


Despite the cramped layout, I thought I had done a pretty good job placing the components. Unfortunately, I had forgotten to include the current limiting resistors for the LED, so the LM317 failed within a few seconds. Luckily, I had a scratch monkey at hand, and the LED and the ATtiny were undamaged. Removing the failed LM317 proved rather difficult, and retrofitting resistors between the LED ATtiny even more so. Ultimately, I found it easiest to put one of the resistors on the LED side of the board.

I wanted to use the existing power switch built into the case, so I had to connect to the power switch, and to the bulb socket, which turned out to be rather frustrating work, so I ultimately cheated by adding some strategically placed aluminum foil:

The Result