Archive for cjh

FPGA Project: Graphical LCD

First success with a new project: a simple frame buffer and controller for the graphical LCD display I’d previously used with an AVR.

The red board is a Papilio One with a Spartan 3E FPGA, power supply, SPI dataflash for the FPGA configuration, and a FTDI USB-serial IC for communications and programming. The white protoboard houses buffers to drive the 5V LCD from the 3.3V FPGA I/O and a MAX232 used to provide the awkward negative LCD drive voltage. To the left on the green protoboard is a 4-character dot matrix LED display.

A block RAM is just the right size to perform as a frame buffer, and they are dual-ported, so one port can be set aside for outside access. The frame buffer continuously cycles through the contents of that RAM with a simple state machine, occasionally wiggling control signals and delaying for a short period between each line to let the display react. The code will appear on GitHub when it’s cleaned up a bit.

edit: The code for the LCD controller/framebuffer is here.

Site update

I finally fixed some long-standing issues with the site, switching to a new theme in the process. Still cleaning up and reorganizing stuff. Among other things, IPv6 should work now.

I’ve moved a few things to GitHub:

s3tools also moved to GitHub some time ago: s3tools

Some other new things there:

…and several others.


Finally broke down and set up Flickr as my primary means of sharing photos:

The interface isn’t quite as annoying as it used to be,

There’s some good photos there from the 2011 Michigan Botanical Club Spring Foray.

Also some stuff here, but since the Gallery folks decided to lobotomize Gallery 3, I’m not sure how much I’ll be using it. (Not even TIFF support? Seriously?)

Update: I’ve largely gone over to Picasa. Flickr’s UI is just too cluttered and poorly designed. I’m not too fond of Picasa either, but it’s much cleaner.

AVR XMegaA4 breakout

Here at last is the breakout board I designed for the Atmel XMegaA4 a while back. It’s a simple thing, just headers, a crystal, a ISP programming connector, and various power supply and analog voltage reference filters. The board is sized to fit within Seeed Studio’s lowest cost bracket for their PCB service. The board:

Mostly surface mount parts…don’t let that scare you away, they’re not that hard to deal with…easier than through hole parts, in some ways. You don’t need to go buy solder paste, you do need some flux. The procedure:

  1. Apply flux to the surface mount pads with toothpick.
  2. Bead solder on the pads. If it gets sticky and forms peaks, use more flux. Get too much solder on, wipe it off with the soldering iron. You don’t need much, just enough to form a solder joint, and too much will make things difficult.
  3. Apply more flux…it will not only help solder flow, it’ll hold your parts in place (like solder paste does, but cheaper). Don’t apply too much…it’ll liquefy and pull your parts off their pads before the solder melts. You want the solder beads sticky, you don’t want your parts swimming in flux. Use toothpicks to remove excess flux.
  4. Tack the parts down on the fluxed solder-beaded pads, nudging them into place with toothpicks. Too large/round of a solder bead will make this difficult. Some troublesome parts are the inductor and the crystal load capacitors, which have a tendency to get pulled off their pads.
  5. Reflow the board. You want to heat the whole thing up so the solder melts. You’ll see parts shift into place when this happens. Electric skillets and toaster ovens are popular approaches to this, I’ve used a cheap hot air gun for my first two and a skillet for the third, and recommend the skillet (with a bent piece of aluminum sheet metal under the board to help spread heat and help with placement and removal). This board’s small enough to easily heat evenly with this approach. If using the hot air gun, approach the board slowly with the airstream to get the flux melted…this will help hold the parts in place better, and keep them from blowing away.

You’ll want to omit or remove the capacitors on PA0 (C10 and C11) and PB0 (C9 and C12) if you need to use those pins for digital signals of any significant speed, they are filters for external analog references. L1 can be replaced with a short wire if you don’t need the extra filtering on the analog supply.

The parts list:

Part Value Device Package
C1 100nF 0805
C2 15pF 0805
C3 15pF 0805
C4 100nF 0805
C5 100nF 0805
C6 10uF 0805
C7 100nF 0805
C8 10uF 0805
C9 100nF 0805
C10 100nF 0805
C11 4.7uF 0805
C12 4.7uF 0805
JP1 PINHD-1X19 1X19
JP2 PINHD-1X19 1X19
JP3 PINHD-2X3 2X03
L1 27nH IMC0805ER27NJ01 L2012C
Q1 4MHz ABL-4.000MHZ-B2 HC49/S
R1 10k 0805

Most of the parts were available from Mouser, though I went to Avnet for the XMega32A4. The board should work fine for others of that series, of course.

And finally, the Gerber files:

Remote shutter release adapter for Lumix G1

I’ve got a growing list of camera-related things I’d like to try, and the lack of a way to trigger the shutter for my Panasonic Lumix G1 has become a real annoyance. Unfortunately, Panasonic only offers one option, a wired remote shutter release that costs $80, though you can get it some places for a mere $50.

Fortunately, there’s another option, detailed in this blog post:

It’s a simple multi-resistance control, connecting various resistances across one circuit and allowing multiple functions to be controlled with one pair of wires…the second “ring” contact and the “sleeve” contact of the 4-contact 2.5 mm TRRS (“phone” or “phono”) plug. I’m not sure the high resistance has any use, it may allow the camera to detect that an external shutter release is plugged in. Closing the circuit with a 5 kohm resistance signals a half press of the shutter button, and a 2 kohm resistance signals a full press. A few resistors is all that is required to convert it to switch closure control. The second ring contact (connected to the 30-40 kohm resistor) appears to be the ground…this is unimportant if using relays or pushbutton switches, but needs to be accounted for if using transistors or optoisolators.

The main problem is the 2.5 mm TRRS plug used. I was unable to find one of the corded adapters he used, but found a cheap $20 Rocketfish headset that included an adapter. On opening, it proved to be a one-piece plug adapter, but I was able to cut it apart into a separate 3.5 mm jack and 2.5 mm plug. The wires connecting the two were potted in a thermoplastic compound…softening it with heat let me strip much of the bulk off with pliers, prying and cutting with a razor knife did the rest. Given how much trouble it was to get ahold of the 2.5 mm plug, I made a single general-purpose adapter that I would be able to use with a variety of external triggers. I free-formed the adapter onto the plug using 4 resistors (a 15 kohm and 22 kohm in series for 37 kohm total, and a 3.3 kohm and 2.2 kohm) and a header socket, and encapsulated the whole thing in hot glue for a compact and solid adapter.

There’s easier ways to get the plugs, I was unlucky and in a hurry. To my surprise, Mouser does not seem to have these 2.5 mm plugs. DigiKey doesn’t seem to have them either, but does have cords with the required plugs:

Chop one of those in half, and for $6.09 you get two plugs with cords attached. Or you may just want to buy the jacks and use the cords whole…for some reason I’ve found the jacks much easier to find than the plugs.

Newark was the only place I found that actually has the plugs:


Close stuck SSH sessions

Something I’ve been looking for as long as I’ve been using SSH is a way to force the SSH client to exit. When dealing with unreliable connections or working with embedded Linux devices, you can often end up with a SSH client that thinks it’s still logged in, and which insists on sending all keystrokes blindly into the aether until the connection finally times out.

There is a way out that doesn’t require opening another terminal to kill the SSH client: press enter, tilde (~), and then period (.), typing each as a separate keystroke. This doesn’t appear to be a well-known feature (perhaps it’s just my poor luck in looking for it), but can be quite a time saver.

WiFi Christmas Lights

While looking for something to do with my 3.5″ Insignia Infocast, I came across this post about some controllable RGB Christmas lights:

WiFi-enabled Christmas lights seemed like a good way to test out a variety of things, and hopefully something to show to family members who don’t quite get what I do for work and play (while I’m not sure that WiFi Christmas lights is the best example for this, it fit the season). The result didn’t see any use during Christmas, unfortunately…setting up a Linux machine on a wireless network via the command line is not as straightforward as I’d hoped, so it never got hooked up at my family’s place. I never got around to coding any lighting programs, so only the most basic functionality is actually implemented and tested. But those basics are there: a CGI program that runs on the Infocast (which is essentially a Chumby One, with a 454 MHz ARM processor, 64 MB of RAM, and a WiFi dongle), displaying a web page and sending I2C commands to an AVR Xmega board, which itself is loaded with firmware that communicates with the LED string. A hex inverter is used as a 5V driver for the LED string communications line, and to provide some measure of protection should mishaps occur while wiring things up.

The Infocast main board plugs neatly into a solderless breadboard with the addition of a couple right angle headers to the “mod port”. I used single-row headers on both sides of the board, the header on one side soldered in “backwards” and extended with a straight header to get the needed length and spacing. The result worked quite well:

The lights themselves have simply been modified to remove the original remote control receiver, replacing it with a bit of ribbon cable and a header connector for plugging into a solderless breadboard. This is not ideal…if the connector pulls out of the breadboard, I’ve got exposed pins with 5VDC and fairly high maximum current flailing around near my largely-3.3V Infocast and AVR. It’s far more secure than the first approach, which had the connectors attached straight to the thick, unwieldy light string cables, though:

The long green jumpers are the I2C lines, the small DIP IC is a hex inverter powered off the 5.6 V from the lights and driving the LED comm line. There’s a FTDI USB-serial module that takes up entirely too much board space, but gives a serial console into the Infocast/Chumby One board. The black box underneath is the case and power supply for a dead Ethernet switch, adapted as a base for the protoboards. (someday, I’ll stuff one of the USB-serial modules into that box as well and free up some board space)

The Xmega32A4 board is one of my own design, made with Eagle, boards done by Seeed Studio, and put together with a Home Depot heat gun. A good part of the goal with this project was simply to get an Xmega talking with the embedded Linux devices via I2C, as a general purpose controller/data acquisition peripheral. This turned out to be quite trouble-free, once I figured out that my I2C addresses needed to be shifted by one bit on the Linux side (for those unfamiliar with I2C, some things consider I2C addresses to be 8 bits with the LSB a read/write flag, others consider them to simply be 7-bit addresses with the flag considered separately).

Due to various delays with the toolchain (do not run Bingo’s toolchain build scripts from, they have an entertaining failure mode in which they crawl up your directory tree executing “rm -fr *” as they go, and the script maintainers refuse to recognize this as a significant problem…fortunately I was able to restore from a recent Time Machine backup, and am now using an old toolchain until I can build a newer one that works), wireless configuration, and general lack of time, the code is nowhere near a finished product, but here it is in all its hodge-podge, undocumented glory:


Got some good stuff…a few cheap EL-backlight HD44780 16×4 character LCDs and inverters to drive their CCFL backlights, some junk electronics with relatively large 16×1 character LCDs at $1 each, a couple alphanumeric vacuum-fluorescent displays, and some interesting little intelligent 4-character dot-matrix LED displays in DIP packages…these guys:

Rather pricey, especially in single quantity, but I got 3 for $10. Slightly inconvenient interface…parallel address and data, uses up GPIO fast. Very sharp and clear in low light conditions.

Insignia Infocast

A.K.A. “BB8”, for “Best Buy 8-inch”.
First off, it’s not an alarm clock. For some reason a lot of people seem to mistake it for one. The Insignia Infocast is a Best-Buy branded Chumby device, an “internet media terminal”. It runs Linux on a 800 MHz Marvell PXA168 ARM9, has a 800×600 color touchscreen, 2 GB internal storage (on a microSD card that can easily be swapped out), 128 MB RAM, Compact Flash, SD, 2 USB 2.0 host ports, etc. And it’s extremely hackable. The board has labeled headers for an I2C bus, a 115200 8N1 USART, and 4 GPIO pins (and a good number of other GPIOs scattered around the board that could be repurposed if needed), and there’s source code with examples of using these. The whole thing runs off 5V DC, powered out of the box from a wall-wart, with a coin cell battery for RTC backup. I don’t know yet how much power it needs, but converting it for battery operation should be trivial.

For a piece of consumer electronics sold by Best Buy, it is surprisingly fast and easy to get into…nothing to jailbreak, there’s an easter egg of sorts that lets you in. Once the device is up and running, go to the apps screen, press the logo in the corner to bring up the device info screen, press the pi icon in the upper right corner to bring up a hidden control panel, and press the sshd button to enable SSH login. Log in via SSH (no password needed), type “make” or “gcc”, and it will offer to download and install a toolchain for you. It’s got enough CPU, RAM, and storage space that you don’t necessarily need a cross-compiler, you can do everything on the device itself.

The bottom is held on by four screws hidden under the rubber feet, and one snap-latch at the back near the USB ports…relocate the feet, remove the screws, and pry a bit with a flat-blade screwdriver to get it open. There’s some ventilation slots on the bottom with plastic cover bits that can be easily snapped off with pliers, letting you snake ribbon cables from the serial and I2C/GPIO headers through to the outside world.

The device uses an AU6350 for the USB ports and card slots. For Compact Flash, this chip is limited to PIO mode 6…so there’s no reason to go for an expensive card faster than 25 MB/s (and it’s entirely possible the actual bottleneck would be between this chip and the processor). I haven’t discovered if it would be possible to boot directly from a card, but you can put your own stuff on the card and overlay it over the file system with UnionFS as detailed in this forum post. A current oddity of the software is that it won’t automatically mount a SD card if it’s in the slot at boot, but I did get it to automatically mount the CF card…this may have to do with the fact that I formatted the card as ext3. This is something that merits further investigation.

Some detailed information here, including I2C source code, pictures of the main board, and schematics of the reference platform:

Amazon S3 tool updated

Made some minor tweaks to the library, some more major changes to the command line tool. More file type extensions are recognized, and there’s a new syntax for specifying file paths with bucket name. Also, local aliases can be defined for bucket names…for example, instead of referring to a bucket as “”, you can define an “images” alias for it. Code’s still a mess…