Category Archives: Embedded

Embedded Computing devices and information

Arduino and the evil print statement

freakduino_chibi-thumb-505x579-58708I finally got around to reading Akiba’s excellent blog article entitled Intermittent Bugs and How to Strike Fear In the Heart of Experienced Devs, and this statement jumped out at me:

It just so happens that print statements in the Arduino library use an interrupt service routine and since the AVR doesn’t allow nested interrupts, any interrupt must wait until the current interrupt is finished before being serviced.

In short, one should never issue a print statement from within an interrupt service routine on the Arduino platform.  This implementation was the root cause of a rather nasty hanging bug in Akiba’s ChibiArduino product, and it was a tricky one to track down.

I’ve been working with Arduino for a few years now, and time and time again I’ve run into odd problems which were ultimately traced down to serial.print().  Timing glitches, random lockups, and other bizarre behaviors were all ultimately caused by relying on print statements to provide status during development.  Serial buffer overflows are a huge issue – it’s really easy to cram more data into the UART than the receiving end is able to handle, especially at low baud rates.  The default 9600 baud setting certainly exacerbates this issue; bumping this up to 115200 often avoids the lockup-causing buffer overflow but can introduce other odd timing issues.

As Akiba alludes to in the aforementioned article, it is often safer to toggle or pulse a debug pin to externally monitor events.  This technique is very helpful for measuring time consumption for a block of code – toggle the pin high at the beginning of the block of code to measure (preferably by directly manipulating port register bits – Arduino’s digitalOut() is horrifically inefficient) and toggle it low at the end of the block.  Monitor this pin on your oscilloscope to measure the time.

A couple of pearls of wisdom to pass along:

Recently I’ve found myself working less and less with the Arduino environment and moving more towards direct AVR development.  Arduino is a double-edged sword – lots of libraries and community support, but the indirection and abstractions offered by the platform often come at a high price.


Freescale FRDM-KL25Z, Ubuntu, and mbed

Recently picked up a Freescale FRDM-KL25Z dev board from Mouser – it’s a really inexpensive way to dip a toe into the whole mbed/cloud compiler ecosystem.  It’s a lot of dev board for the price – $14USD buys a Kinetis L series KL2 microcontroller (ARM Cortex M0+ MCU at 48 MHz, 128K flash, 16K SRAM), Capacitive touch slider, MMA8451Q accelerometer, tri-color LED, and OpenSDA debugging.  There’s a lot to like about this board beyond the price – Programming and firmware updates via a simple USB storage interface, Arduino-compatible I/O footprint, and lots of free online resources.

My primary development machine at home is a Gazelle Professional i7 laptop from System76 running Ubuntu 13.04 (x86-64).  The FRDM dev board was immediately recognized when it was plugged in to the laptop.  Since I purchased the board to experiment with mbed, I followed the relevant instructions at to upload the mbed firmware.  Plug mini-USB cable into the openSDA port of the dev board, hold down the reset button and plug the USB cable into the laptop.  So far so good – Ubuntu mounted the BOOTLOADER partition as expected.  Copy the specified firmware to the BOOTLOADER partition – check.  Directory listing showed that the file was there.

According to the instructions, the next step is to simply unplug the device from the laptop and plug it back in; the device should automatically boot into the MBED partition.  This, unfortunately, is not what happened; the device booted into the default TOOLS mode.  I assumed that I had done something wrong – maybe I didn’t wait long enough for the firmware to be programmed.  Lather, rinse, repeat – no dice.

Finally, out of frustration, I (shudder) booted up a Windows XP virtual machine and repeated the procedure.  And…it worked.  From this point forward, mbed worked just fine from Linux; copying files to the MBED mount resulted in the app successfully being loaded.

I found several threads on the mbed forums from the developers indicating that there are issues with the initial mbed installation procedure under Linux, but I saw no resolution other than “use Windows”.  A bit more digging turned up a solution from the fine folks at Rowley Crossworks: this thread discusses the issue and how to fix it.  Unfortunately I had already installed the mbed firmware using (shudder) Windows XP so I was unable to try the fix.

So, long story short, the device cannot be updated to use the mbed firmware under Linux without a bit of manual work first.  Or just put up with Windows briefly to update the device and move on.

Vintage Digital VT420 Terminal on Raspberry Pi

My first gig straight out of school involved supporting a large group of CAD drafters and engineers at a government facility. We used several different CAD systems at the time – AutoCAD on PC, DEC CALMA on Vax 11/785, and HP ME10 on quirky HP Apollo running UCSD P-System. Drafters using all of these systems submitted plot jobs to a big old Calcomp large-format electrostatic plotter. When I first took the job this was very much a manual process. The PCs were running a custom Ungermann-Bass network (ethernet came along a bit later) and plot jobs were sent to a central server on the network. I quickly grew tired of manually copying plot files around and developed a plotter queue application in C which would monitor a network share and automatically queued jobs to the plotter. The PC users loved it, as they got their hardcopy much faster than they had previously. The DEC and HP users quickly became jealous and begged me to extend this service to include them. A couple of classes and a lot of reading led to a very nice solution written in VAX assembly; the CALMA drafters got their plots much faster and the company ended up with another trained system admin for the 11/785.

Most of this initial development work was performed on Digital VT320 terminals. I always preferred the amber screens to green; they were much easier on my eyes, especially in the low-light environment that CAD drafters of the era preferred.

Fast forward a couple of decades. Sitting on my desk I have a $35 computer the size of a deck of playing cards with processing power an order of magnitude beyond that of the slightly more expensive VAX 11/785 that I used to support. What a cool industry.

A couple of weeks ago I was perusing eBay looking for treasures when I stumbled across an auction for a slightly used DEC VT420. The price was very reasonable, as was shipping. Since my Raspberry Pi is currently running headless, I thought it would be fun to put these two together and document the process. It was MUCH more straightforward than I had previously imagined.

The VT420 is a bit more modern than the 320 that I had used back in the day. The biggest advantage that I could see for this project is the 420’s multi-session support – it supports a whopping TWO SIMULTANEOUS SESSIONS running in either full-screen or “windowed” (split-screen) modes. The terminal supports text widths of 80 or 132 columns, and 25, 32, or 48 lines. Sweet!

Physical Connections

My terminal has two DEC MMJ (Modified Modular Jack) jacks on the back rather than the more ubiquitous DB9 or DB25 connectors that you may be accustomed to. From a purely physical standpoint, the MMJ jack looks like a 6-pin RJ45 with an offset latch connector. Fortunately, adapters are available online; I was able to find MMJ cables and DB9 adapters from a local firm, Pacific Custom Cables. If you are following along at home, I picked up two of each of the following: part number BC16E (DEC423 office cable, 3 foot length) and part number A9F12D (DB9F to DEC MMJ adapter). The office cable is available in custom lengths and is already configured as a null-modem (AKA “Crossover”) cable. The adapter has a molded-in female MMJ jack on one end and comes with a modular DB9F plug so you can configure the connection however needed. The following table shows how I wired the adapter:

MMJ Pin Color Desc DB9 Pin
6 White DSR 7
5 Black Rx+ 2
4 Red Rx- 5
3 Green Tx- 5
2 Yellow Tx+ 3
1 Blue DTR 8

Note: The offset tab on the MMJ connector is over pins 4-6. I clipped the metal socket off of the red pin and soldered it to the green pin prior to inserting it in the DB9 housing. For those interested in specific electrical details of this configuration, there is an excellent overview available at

I opted to use a USB-Serial adapter for this solution rather than using the on-board UART. There are many options available here – I’ve used several different Keyspan adapters with Linux in the past with excellent results. Since I did not have a spare adapter handy, I rolled the dice and ordered a cheap ($14 with free shipping) dual USB-to-RS232 adapter from eBay. The device I picked up did not claim Linux compatibility and is listed as a “Syba SY-ADA15033” adapter. Turned out to be a good call – the Pi recognizes the device as an “IOCrest dual USB to serial adapter SY-ADA15033”; lsusb shows device ID 067b:2303, which is a Prolific Labs PL2303 chipset. Painless install; the Pi automatically loaded the pl2303 driver and created /dev nodes ttyUSB0 and ttyUSB1.

Configuring the Raspberry Pi

I am running the excellent Occidentalis Raspberry Pi distribution from the folks at Adafruit on my Raspberry Pi. Since this distribution is based upon Raspbian Wheezy, I would expect the setup instructions to be virtually identical.

This distribution did not ship with a termcap/terminfo file for the VT420. The requisite file(s) can be installed easily by installing package “ncurses-term” with apt-get or aptitude.

I added the following two lines to my /etc/inittab:

T0:2345:respawn:/sbin/getty -L ttyUSB0 19200 vt420
T0:2345:respawn:/sbin/getty -L ttyUSB1 19200 vt420

Just for fun, I also created a new pi-themed /etc/issue file. This is based upon a file sent to me by a friend who did not remember where he found it – if you happen to know the source, please let me know so I can properly attribute the source!

Configuring the VT420

Pressing F3 brings up the VT420 configuration screen.

The initial screen is the setup directory – you will need to select “save” after making changes to store your settings in non-volatile memory.

Global setup screen. The important setting here is “S1=Comm1, S2=Comm2”. This enables session control for our two serial lines.

Display setup. This screen allows you to specify number of columns (80 or 132) as well as number of lines (24, 36, or 48). Each session can be configured independently.

General setup. It’s important to select “VT400 Mode, 7 Bit Controls”, especially if you use Emacs, or your arrow key behavior will be really messed up.

Communications setup. I selected 19200, 8 bits, no parity, 1 stop bit.

Keyboard setup. I set F1, F2, and F5 to “FKEY”, leaving F3 set to “Set-Up” and F4 set to “Session”. I’d recommend this configuration if you’re using multiple sessions (more on this later). The rather odd setting labeled “,< and .> Keys” needs this configuration if you ever want to be able to type the “greater than” or “less than” symbol; the default configuration does not generate these characters.

Beautiful Results

The login screen is gorgeous and is based upon ASCII art sent to me by a friend. If you happen to know of the origin, please let me know so I can give the author proper attribution – he didn’t remember where he found it.

Emacs at 80×25. Works like a charm. You can switch between the two sessions by pressing the F4 key.

Pressing Ctrl+F4 toggles between full-screen and windowed sessions. “Windowed” is a bit of a misnomer here – it really is just a split-screen view. The split can be resized via Shift+F4+Arrow keys.

This picture shows session 2 displayed at 132 columns by 48 lines.

Issues, Problems, Etc.

So far I have ran into surprisingly few issues. I initially wasted several hours trying to get things configured with absolutely no success until I realized that you simply cannot run agetty from a user shell, even as root – THIS DOES NOT WORK. After beating my head against the wall for an inordinate amount of time I remembered fighting this exact same battle way back in 1998 or so with an old DEC VT100 terminal and Linux. Once I added the entries to /etc/inittab it just worked.

Flow control is a problem. While the cable does indeed pass through DSR/DTR and XOFF is configured, fast updates such as directory listings will often contain garbled characters. If anyone has a solution to this particular problem I’d love to hear about it.

I had hoped to use tmux to run multiple sessions, but I’m an emacs user and tmux changes the $TERM environment variable to SCREEN for some reason, which causes emacs to flip out over control characters (backspace and arrow keys). There’s probably an easy fix for this but tmux was a nicety in any case.


I really love this terminal. I spent many, many hours writing code on a nearly identical terminal at the beginning of my career, and there is something very comforting about returning to this configuration with my Raspberry Pi. Since this Pi is destined to become the central controller for my home automation solution, it will remain attached to this terminal. I hope that others find this blog post useful and give a new home to a VT420 or similar terminal with their Raspberry Pi. Have fun!

Cook Technologies Steel Raspberry Pi Case


I discovered this case while browsing through eBay looking at Raspberry Pi offerings. I’ve been looking for a slightly more rugged case for one of my Pis, and this one seemed to fit the bill nicely. Some may argue that spending $28 for a case for a $35 computer is excessive, but given how difficult it is to actually lay hands on a Raspberry Pi these days it seemed like an easily justifiable expense. I ordered two Raspberry Pis on November 1 and just received the first one a couple of days ago. I ordered this case from eBay on 11/28 and it arrived today (12/3).

Initial impressions of the case make it very clear that the case was designed and built by a competent, experienced manufacturer who actually cares about quality. The case is hefty, made of 19 gauge cold rolled steel, and is beautifully painted with a black powder coat finish. No sharp edges to be found. Screw holes line up evenly and are cleanly drilled and tapped. Cutouts for the Raspberry Pi line up precisely, have ample clearance for their intended use without providing too much of a gap. Inside the case the manufacturer has provided foam inserts to firmly hold the Pi in place and prevent any circuitry from shorting against the steel case. The Pi fits snugly within the lower half of the case without being “wedged in” to the provided space. Once assembled, the Raspberry Pi is held firmly in place and the case feels substantial.

I only have a couple of complaints about the case, and they are really minor quibbles. First, an option for mounting ears would be extremely beneficial; a provision for securely mounting the case to a cabinet would expand the case’s potential applications. Finally, the case really should have some kind of light pipe arrangement for the Pi’s LEDs. A hole is indeed provided for this purpose, but it seems odd given the otherwise stellar build quality of the case.

I am in no way associated with Cook Technologies, I’m just a VERY happy customer. It is, unfortunately, rare these days to discover a manufacturer who provides this kind of fit and finish in a product geared towards the hobbyist. This case is a pleasant exception to this unfortunate rule. The case is currently available for $28 USD from eBay seller cooktechinc with free shipping. Worth every penny, IMHO.

More pictures of the case follow…