Bench PSU: AVR JTag update #4 (I think I can stick a fork in it now)

I've slowly but surely made progress on my bench power supply. I think my JTAG issues are a thing of the past. I've done a couple things to ensure reliable communications, and I've now got the AVR Dragon running at 2 MHz with 0 errors so far. First, I put the 20pf capacitor on the JTAG clock line, at the breadboard side. I know I derided the lowly 20pf cap in the past as a pawn of the Capacitor Cartels, but I'm eating crow now.

The second thing I did was to create a JTAG "Bread Head", so named in and inspired from this post on Blondihacks: Bread Head. I'm not a great photographer, and macro shots seem to be even harder, but here it goes:

My Atmel 644 (and pin compatible DIP 40s) JTAG
Breadboard adapter. I could probably trim a little more
perfboard off the top.

I did a couple things slightly differently from Ms Dunki. Since I was targeting a 40 pin DIP form factor, my original piece of perfboard was cut 20 holes long and 9 holes wide(which left one row on either side of the chip). That turned out to obstruct a lot of the breadboard, and make it a pain in the ass to add or remove wires in close proximity to the chip. So I trimmed off as much of the "empty" space as I could without jeopardizing the structural integrity.

The other thing I did differently was instead of embedding the whole thing in epoxy (which I seriously considered), I used Polycaprolactone plastic, which goes by the brand name "Shapelock". It "melts" to a moldable state at 160°F(71°C), which sounds pretty hot, but's pretty tolerable to mold by hand. I melted the plastic and pressed it onto the underside, to protect the exposed wiring from shorting stuff on the breadboard.

Plastic-coated underside

Here's the side-view:

Side-view. Believe it or not, I probably took 50 close-up shots of this thing,
and the three shots that made this blog came out the best.

The single, isolated 13mm pin had me a little worried, I didn't know if it would work. It goes to pin 31 in the 644, which is one of two ground connections to the breadboard. I was going to skip it if it wasn't secure, but the Shapelock helped stablize it, and overall, having that pin there made the whole device more stable.

My dev circuit looks a lot cleaner now:

Before (with my "shielded cable" too)

After (also with a lot more functional components in place).

So in the meantime, I had made some progress on my bench supply:

I typically divide my embedded application code into three "tiers". I'm a software guy at heart, and architecting is sort of my thing, so sometimes I get rather elaborate building "low", "middle", and "high" level systems, even when I could probably have hacked something together. I typically build all three tiers in tandem, though I tend to favor the low level framework code early on, since nothing can really function at the higher levels without it.

My "low level" consists of a set of drivers for the various subsystems, broken into area of functionality by domain. For example, I've got a manager class that handles I2C communications. I've got another manager that handles IO with the IOExpander (the 28 pin chip seen in the photo above), that uses the I2C manager. But both are "low level" drivers that abstract the functionality of those parts of the system.

The "mid level" consists of more framework infrastructure, but it exposes the low level functionality in a way that makes sense to the types of things that the main application might want to do. For example, I have a screen system, and set set of "widgets" that are logical areas of a screen that can be purposed for a particular use. The voltage readout in the photo is in fact a voltage sensing widget mapped to that part of the screen. (Which is actually working by the way, that long blue wire in the lower left is going to pin 40 on the 644, which is one of the ADC pins, and it's sensing the output of the RC filter on a PWMed square wave at 25% duty cycle. 5V x25% = 1.25. Nifty!) Also mid level is input handling, and a "mode" stack system, to allow defining a user interface state machine. (I used a similar, but more extensive system on "Goodtimes").

The high level tier is really the application definition, eg specific modes of operation, and the organization of widgets specific to each mode. This is currently the least developed part of the system, since I've only recently gotten the lower tiers barely functional. This will probably be the more sparse level in the end also. It's a power supply, there's not a whole lot of end user interaction. I'll have a "main" mode, with a channel selection, voltage and current settings, and a calibration mode that I'm still in the mental design stage of.

I'm writing the system software in C++, because it's a lot better than the alternative AVR studio languages for crafting architectures, and the 644 has got plenty of memory and processing power to spare to this application.

Next month, I'll start working on the analogue parts of the circuit, the actual voltage/current regulators and sensing circuits. I'm a little scared not only because they are harder to me (op amps are deceptive in their superficial simplicity, implementational complexity). I also need to source an ATX socket connector to hook up my old power supply that originally motivated this project)

--P