Thursday, July 31, 2014

Lötet, freie Schweizer, lötet!

The recent introduction of chasing electroluminescent (EL) wire inspired me to give this a try in a seasonal installation:


admittedly, the sound on the video is not recorded off the installation—I overdubbed the same MP3 file the installation plays on top of the video, so the fairly soft rendition of the audio through the simple speaker I used did not detract from the majesty of the visuals and the occasion.

I noticed that so far I had never written up an EL wire project, mainly because the software generally has all the sophistication of an LED blink sketch, the hardware is 95% off the shelf (I'd rather not tinker too much with the high voltage AC current involved in an EL wire project), and my craftsmanship with the wire shaping is undistinguished. Nevertheless, I thought it was time to show how a project like this can be done.


Bill of Materials

  • EL Wire — I mostly use Sparkfun's brand of EL Wire, bought mostly through Boxtec. Make sure whatever wire you buy has the right plugs. I bought some of my EL wire from Seeedstudio, and spent some rather instructive time and effort refitting it with the plugs I needed (some adhesive copper tape and a bit of heat shrink tube ended up working quite nicely). The wire I use is 2.3mm thick (the thinner, the more tightly the wire can be bent).
  • Adapter cable for the chasing EL wire
  • An EL Sequencer — my Sparkfun EL Sequencer still works, despite the nasty accident it suffered when I first powered it up.
  • An EL Inverter to generate the high voltage high frequency power to drive the EL wire.
  • Electrical tape to mask off the sections of EL wire that I don't want to be seen.
  • Garden mesh to mount the wire. I bought a roll of 3x3.5mm garden mesh and cut it to size as needed.
  • An Arduino Uno with a MP3 Player Shield to play the music.
  • speaker for the audio output. With some additional circuitry, the MP3 shield is also capable of sending a fairly reasonable quality output signal to an external amplifier (e.g. your stereo system).


Arranging the EL Wire

There are numerous ways of getting EL wire to keep whatever shape you want to form it. The technique I'm using (which I may have invented; I don't recall having seen it anywhere else) is to use a tight garden mesh with holes a bit bigger than the diameter of the EL wire, and weave the wire through it:

it turns out that it does not matter whether the EL wire runs on the front or the back side of the mesh: it is bright enough that it will be equally visible on both sides. EL wire can bend quite a bit, but if abused too much, it will eventually break, so my wiring tends not to be all that tight.

The EL wire I buy generally comes with a plastic cap at the end, and the mesh is tight enough that I need to remove the cap or cut off the end of the wire. I've generally not had problems with this practice, but in the new chasing EL wire, doing this seems to have created some sort of shortcut between the individual strands of wire, so I had to separate them a bit and put some electric tape around the end to fix the problem.


Code for EL Wire

Basically a glorified blink sketch, as I said. Rather than synchronize line by line, or note by note, I just synchronize with the start of the song, which happens to be recorded at a fairly steady 60bpm (except for a ritardando at the end which I'm ignoring). For the chasing wire, I'm using an adapter cable using 3 channels; I do the chasing with 2 channels on, 1 off at a time, although the other way around also works, of course.



Playing the MP3 File

For playing the MP3 file, I used Bill Porter's very convenient MP3 shield library, so the actual code to play the file was trivial: 



The synchronization is simply done by connecting the TX pin of the Arduino to the RX pin of the EL sequencer, and then sending some data when ready. It certainly could have been made more precise, but for my purposes, I thought it close enough.

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.