Monday, March 31, 2014

Introducing Muggeseggluino

One of the ideas that fascinate me in my electronics projects is minimalism in form factors. Having started out on an Arduino Uno, I started building ATtiny84 (14 pin DIP) based projects after a while, then ATtiny85 (8 pin DIP) based projects.

That's where things remained for a while, but eventually, I could not resist the temptation of tinkering with the most minimalist of the ATtiny series: The ATtiny4/5/9/10, coming in a 6 pin SOT-23 package. Despite the modest specs of the series (The ATtiny10, as the luxury high end model, features 32 bytes of RAM and 1K of flash), there is decent compiler support (don't expect to run an Arduino core, of course), but programming the MCUs is a bit tricky. Pulling out the MCU from the circuit and reinserting it for every programming cycle would require rather massive amounts of soldering, and putting it onto a breakout board sort of defeats the purpose of having such a small form factor in the first place.

I decided to try a different approach: 

Every pin of the MCU (Except for GND) is broken out to a pin in the right row of headers. The left row is connected to the rightmost row in the prototype area. That way, the two rows of headers can be connected to operate the circuit, and separated when reprogramming the MCU. After the software is final, the headers can be removed and the two rows of pins bridged (The astute reader will notice that the space savings over a DIP breakout board, if any, are minimal, but I still like the design).

The name of the board, "Muggleseggluino", derives from the Alemannic word for a small but distinctive amount. It seemed an appropriate name for situations where just a tiny bit of microcontroller was needed as an ingredient.

Right now, I'm still playing with software options. The easiest solution out of the box is Wayne Holder's ATtiny10 IDE. The high voltage circuit is only needed when using pin 3 as an I/O pin, otherwise, SHDN can be used on the RESET pin directly. If you already have a 12V power supply, the single transistor circuit used by ScratchMonkey should also work.

Tuesday, January 28, 2014

Digispark & Co

Boxtec discussion recently brought up the fact that the last year has seen a good number of ATtiny85 based boards with USB connectors:
While of these, I own only Digisparks (having been one of their Kickstarter backers), the others seem close enough in design for me to offer a few thoughts about the idea.

Hardware

Electrically, all four boards seem to be based on the Digispark design: An ATtiny85 MCU, an USB connector directly connected to the MCU. Within that basic design, the boards have quite a bit of variety in the mechanical aspects:
  • The Digispark 
    • Features a male USB connector that is simply designed into the PCB. While this is an eye catching and original design, in practice it caused me no end of mechanical problems. Even with perfect mechanical tolerances (which at least the early Digispark boards did not have), having the board sit right next to the USB plug was rarely convenient, so I ended up using a f-m USB extension cable, pretty much negating the point of having a male connector in the first place. 
    • Has a voltage regulator on board and can be externally powered.
    • Has an unique and elegant, squarish form factor that Digistump is trying to build an ecosystem around.
  • The Adafruit trinket
    • Features a standard female USB mini connector, which in practice probably will work out much better than the male connector.
    • Voltage regulator, can be externally powered.
    • Available in 3.3V and 5V variants.
    • Reset button on board.
    • Board looks like a tiny Arduino Micro, pins brought out DIP style. Mounting holes might be quite useful.
  • The Olmexino
    • Female USB mini connector. [Update: Now (wisely) changed to a full size USB connector]
    • No voltage regulator, though it looks like it might be possible to power externally with appropriate voltage. Hardware reset button.
    • Board comes as a DIY kit, which for the most part seems like a fun idea. The only board of the four featuring the through-hole variant of the ATtiny85, and even a socket for it. My one concern is the SMD USB connector, which is not my idea of fun to solder, especially since mechanical reliability is a major concern for this part. [Update: It seems that Olmexino came to the same conclusion. Rev B of this board features a through hole, full size USB connector — unfortunately, nobody seems to make through hole USB mini connectors].
    • Pins brought out SIP style.
  • The Iteaduino Tiny
    • Appears to have a female USB micro connector, which I'm not terribly fond of. In my experience, mini connectors are much more convenient for frequent plugging/unplugging.
    • No voltage regulator, no reset button.
    • Instead of bringing out all pins, this design seems to have a male ISP header. I'm not at all convinced this is a good idea. The whole idea of this family of boards is to be able to do programming through USB. Furthermore, it's impossible to fall back to High Voltage Serial Programming on this board because some of the pins are only brought out through USB.
    • To add to the hardware design issues, Iteaduino apparently did not disable the RESET functionality of the MCU, so of the 4 I/O pins brought out by the header, only 3 can be used safely.
All four of the boards share the concerns of the original Digispark design: Of the 6 I/O pins available on an ATtiny85, only 3 (PB0, PB2, PB5) are truly unencumbered: PB3/4 are connected to USB (which in practice rarely seems to be a problem, but would make me a bit nervous when the board is plugged in), and PB1 has an LED attached, which is a problem in some applications (early Digispark designs had the LED on PB0, which made I2C unusable, but this has long been fixed).

Software

All of the boards use about 2K (the Adafruit Trinket a bit more) of the flash memory for a boot loader allowing the boards to be programmed through USB. If you're used to modern Arduinos, getting used to these boards might have a bit of a learning curve, as reprogramming them is somewhat timing sensitive. None of the boards works with the Arduino IDE out of the box—the Adafruit Trinket requires some manual configuration or a custom Arduino IDE downloadable from their site, while the others use the Digispark customized Arduino IDE.

In addition to regular ATtiny85 activities, all of the boards have some capability to work as an USB device (e.g. a keyboard or a mouse). Generally, the software USB libraries work as advertised, but it tends to be somewhat more fragile than using a true USB capable MCU.

Pricing

One of the attractive features of the Digispark was its low price, and the clone boards are priced even more aggressively. 

Final Thoughts

The Digispark was a rather original design when it first came out. From the neat form factor, to the minimalist USB connector, to the software USB and boot loader support, it featured several novel ideas, and demonstrated they could be done. As for whether they should be done, the situation might be less clear:
  • In hindsight, I don't think the male USB connector was a good idea.
  • The small form factor is really convenient for space constrained projects.
  • The boot loader certainly adds convenience for beginners. If you're comfortable working with external programmers, I'm not convinced the extra convenience of a boot loader is all that useful.
  • Though the software USB support might be a bit finicky to use, it's undoubtedly a benefit for some applications.
In summary, I think these boards are at their most useful when you want USB capabilities in a project, and space and/or money are an important concern. In some projects, having a voltage regulator on board might be convenient as well. For many other projects, it seems to me that a plain ATtiny85 (possibly of the through hole variety) and an external programmer are far more flexible and not all that much harder to use.

Thursday, August 22, 2013

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. 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. 

Sunday, July 28, 2013

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).



Thursday, July 4, 2013

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:

Sunday, June 23, 2013

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:

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

Availability

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

Thursday, May 2, 2013

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: