BMOW title
Floppy Emu banner

Alternative AVR Programming Header Ideas

That ubiquitous six pin header for in-circuit programming of Atmel AVR microcontrollers – it’s the standard, but it’s not a great standard where size and cost are a concern. Can I do better?

Programming most AVRs requires a six wire interface, with a clock, serial in, serial out, reset, power, and ground. It’s common to include a 3 x 2 pin 0.1 inch header on any AVR-based board. Typically a keyed box header is used to prevent accidental backwards cable attachment, like the header on the Adarfruit breakout board shown above, but sometimes bare 3 x 2 pin 0.1 inch headers are used.

That’s fine for hobbyist work or building a prototype, but when building larger numbers of AVR-based boards, the 3 x 2 pin 0.1 inch header has two significant drawbacks. The first is the component cost and related assembly cost for a header that will only ever be used once, for a few seconds during manufacturing. It’s not a huge cost, but it’s still a factor when trying to minimize the cost per unit – why throw away money? The second drawback is the relatively large physical size of the 3 x 2 pin 0.1 inch connector. For small boards containing mostly surface mounted parts, the ICSP header can complicate layout and routing, or require enlarging the PCB.

Ideally we want a programming connector with these attributes:

  • zero per-unit cost
  • small footprint, preferably one-sided
  • keyed to prevent backwards cable connections
  • holds cable firmly attached to the board

Here are some options to consider.

 
Empty Footprint 0.1 inch

The simplest option is keep the standard 3 x 2 pin 0.1 inch header footprint, but don’t actually solder a header into it. When it’s time to do programming, place a 3 x 2 header in the holes, and apply some sideways finger pressure to ensure the pins make solid contact with the hole plating. It’s low tech, but it works.

A small optimization is to use a 3 x 2 pin 0.1 inch lock header footprint, where the holes for the individual pins are very slightly offset instead of appearing in a perfect grid. This helps hold the header in place temporarily with friction, so finger pressure normally isn’t needed. It’s what I do for Floppy Emu programming, as shown here:

This approach eliminates the cost of an otherwise-useless programming header, but it’s still too big and doesn’t prevent backwards insertion. And even with the lock header footprint, it’s not great at holding the cable in place for extended periods of development or debugging. The pins often slide out of the holes.

 
Empty Footprint 0.05 inch

A second option is to use an empty 0.05 inch header footprint, which reduces the required board area to just 25% of original. That’s great, and this might be a good solution. But most AVR programmers have a 0.1 inch cable, so a 0.1 inch to 0.05 inch adapter will need to be built or purchased. That’s a minor drawback, but it only needs to be done once.

0.05 inch pin headers are fairly delicate. Would they hold up to hundreds of insertions and removals, with the added forces of finger pressure or lock headers?

This solution is also not keyed to prevent backwards cable insertion, nor does it grip the cable tightly.

 
Empty Non-Rectangular Footprint 0.05 inch

If I’m contemplating building a 0.1 inch to 0.05 inch adapter anyway, there’s no reason the 0.05 inch end needs to retain the standard 3 x 2 layout. I could do something with 4 pins in one row and 2 pins in a second row, or any other kind of irregular pin spacing that would prevent backwards cable insertion. Maybe a 7 pin single row design, with one of the pins removed. This would make the footprint area slightly larger than a 3 x 2 layout, but it might be worth it to prevent accidental backwards connections.

 
Pogo Pins

Any kind of footprint with plated-through holes will hinder routing and component placement on both sides of the board. Spring-loaded pogo pins provide an alternative approach, making it possible to build a one-sided programming interface with exposed pads, similar to this:

With 0.05 inch spaced pogo pins this allows for the smallest footprint of all, but the pogo pins need to be held against the board with one hand during programming, making it awkward to use. It’s OK for a programming operation lasting a few seconds, but not for anything longer.

This simple AVR ICSP pogo pin adapter from Tindie shows one such approach:

It’s nice, but there’s nothing to help align the cable or prevent backwards connections.

For a fancier solution, there are pogo pin cables from Tag-Connect that include alignment pins and optional locking legs to hold the cable firmly on the board:

But when you include the area needed for the alignment pin holes, the Tag-Connect footprint is essentially the same area as the standard 3 x 2 pin 0.1 inch header footprint, and the size advantage is lost. And with the version of the Tag-Connect cable that has locking legs, the required footprint area is even larger. Look at this beast:

 
Conclusion

So what’s the best option? I don’t think any of them is a clear winner – they all have advantages and disadvantages. I really like the idea of pogo pins and exposed PCB pads, but the required alignment pin holes mostly negate the space savings, and I don’t like the idea of always needing one hand to hold the cable in place. For my purposes, I think the non-rectangular footprint with 0.05 inch headers is worth exploring further. I’ll see what I can cobble together for testing.

Read 12 comments and join the conversation 

Daisy Chainer Testing

Good news: the Daisy Chainer for Floppy Emu is finished, and working nicely in all my tests. With the Daisy Chainer, a mix of real and emulated disk drives can be combined into a single Apple II daisy chain for maximum flexibility. The real drives can be attached before or after the Floppy Emu.

I have a few Daisy Chainer boards available for sale now. Send me an email if you’re interested in getting one (use the Contact link at the page’s upper-right).

Not-so-good news: newly-assembled Daisy Chainer boards are a pain to test, and this is something I didn’t account for. A true functional test requires connecting the board to a Floppy Emu, an Apple II, and a variety of other disk drives, and then running through many different permutations of daisy chain configuration and disk emulation modes. It requires 15 minutes or more. That’s OK for a few hand-assembled units, but there’s no way I can do that for a larger production run.

To support faster testing, I’ve designed two special test boards that plug into the male and female DB19 connectors on the Daisy Chainer. These will enable some automated loopback testing of the main board using its own microcontroller. It won’t be a perfect test, but combined with some other automated tests for things like pin-to-pin solder shorts it should detect most likely assembly defects.

The problem is that in order to support the automated testing with the special test boards, I need to make some modifications to the Daisy Chainer PCB. I’ve finished that work, but I’m waiting for PCB delivery and then I need to assemble a second prototype. So it will probably be at least a month until full production of more Daisy Chainers is possible.

This is the first time I’ve ever been forced to redesign a PCB not because there was a problem with the device itself, but simply because the device was difficult to test efficiently. Lesson learned: when designing anything that you expect to build more than 10 units of, planning for testing should be an integral part of the design process.

Read 2 comments and join the conversation 

Floppy Emu Firmware Update: Smartport Unit 2 Mode

Celebrate Friday with a firmware update for the Floppy Emu disk emulator! This firmware adds a handy new disk emulation mode for Apple IIGS computers called Smartport Unit 2 mode. It’s what I called “chameleon mode” in an earlier post, and it’s very helpful for one specific configuration: you’re using the Floppy Emu as a Smartport hard disk, and the Emu is “unit 2” daisy-chained behind an Apple 3.5 inch floppy drive. With the new firmware, it’s now possible to boot from Smartport unit 2!

Normally an Apple IIgs in this configuration could only boot from the Apple 3.5 inch floppy drive (the 1st drive unit in slot 5), limiting the configuration’s usefuleness. Smartport Unit 2 mode causes the Floppy Emu to initially appear as a 5.25 inch drive in slot 6, which the IIgs will boot from, and load a small bootstrap program. This program will modify the Smartport unit priority table in RAM to give Unit 2 priority over Unit 1, and then reboot from slot 5. Presto, unit 2 boots.

You should only use Smartport Unit 2 mode when the Floppy Emu is daisy-chained behind an Apple 3.5 inch floppy drive. In all other cases, continue to use regular Smartport mode.

Get the firmware here: apple-II-0.2H-F25-modelBC

Note this firmware also contains some changes needed to support the forthcoming Daisy Chain Adapter. There shouldn’t be any visible differences, but be on the lookout for possible problems with daisy chaining, so you can revert to the previous firmware version if needed.

Read 5 comments and join the conversation 

Floppy Emu Chameleon Firmware

Here’s a fun party trick: firmware for the Floppy Emu disk emulator that emulates a 5.25 inch floppy drive, but then reconfigures on the fly as a Smartport hard disk emulator. Why is this useful? It’s not obvious at first, but if you’re a Floppy Emu owner with an Apple IIgs and an Apple 3.5 inch floppy drive, read on. Or if you just like nifty hacks, this one’s for you.

The IIgs supports daisy-chaining up to six disk drives – a great feature. Unfortunately there are strict rules about what order the drives must appear in the chain, depending on their type, and there are further limitations on which drives can be used as boot drives. So there are some perfectly reasonable drive combinations that are impossible in practice.

The best example is a Floppy Emu configured for Smartport hard disk emulation mode, combined in a daisy chain with an Apple 3.5 inch floppy drive. IIgs owners want to boot from the Emu’s Smartport HD most of the time, but still want the flexibility of having a 3.5 inch drive for the occasional physical floppy. Apple says no. Drive ordering rules require the 3.5 inch drive to appear before any Smartport drives, and only the first drive in the chain can be used to boot the computer. The IIgs will always attempt to boot from the Apple 3.5 inch drive. So the desired configuration is impossible, and this is a limitation of the Apple IIgs design rather than anything specific to the Floppy Emu.

But wait… maybe there’s a hope. Eric Jacobs points out there’s a table that controls the boot priority of the drives in the daisy chain, located in Apple IIgs memory at address E10FC0. This table is initialized during a cold boot and gives the first drive first priority. If you edit the memory table and then restart with a warm boot, you can force the IIgs to boot from a different drive, like the Emu’s Smartport HD instead of the Apple 3.5 inch drive.

That’s good news, and it provides a theoretical solution, but the actual practice is lousy. You have to turn on the computer, interrupt the boot process with control-reset, enter the Apple II system monitor with CALL -151, and manually edit the memory table using arcane debug commands. Then you finish the process by forcing a jump to the warm start address. Several months ago I confirmed that this process works, but it’s not very user-friendly, so I dropped it.

Here’s where part two of this party trick comes into play. The IIgs also supports 5.25 inch floppy drives, which must be connected in the daisy chain after any 3.5 inch and Smartport drives, but nevertheless normally get a higher boot priority than the other drive types. I can leverage this fact to make the Floppy Emu appear as a 5.25 inch drive, which loads a small bootstrap program that edits the memory table. Then the Floppy Emu auto-reconfigures itself as a Smartport drive, and the bootstrap program performs a warm start of the IIgs.

Here’s the play-by-play process:

  1. Connect the Apple 3.5 inch drive to the Apple IIgs
  2. Connect Floppy Emu to the Apple 3.5 inch drive
  3. Turn on the Apple IIgs
  4. Floppy Emu configures itself as a 5.25 inch drive
  5. Floppy Emu provides a hard-coded disk image containing a bootstrap program
  6. Apple IIgs boots from the 5.25 inch bootstrap disk
  7. Bootstrap program displays a splash screen and modifies the IIgs memory table
  8. Floppy Emu reconfigures itself as a Smartport HD
  9. Bootstrap program performs a restart of the IIgs
  10. IIgs boots from the Floppy Emu’s Smartport HD

The net result is that it’s now possible to have an Apple 3.5 drive and a Floppy Emu Smartport HD in the same daisy chain, while booting from the Emu’s HD – something that was previously impossible.

Watch the video carefully, and you’ll see a text screen flash by that says “Big Mess o’ Wires, rebooting from smartport unit 2…” That’s the bootstrap program at work. Unfortunately my composite video to HDMI adapter creates ~5 seconds of blackness whenever the IIgs first powers on, or changes between text and graphics modes, so this isn’t the greatest video. The whole process from power on to Smartport HD boot only takes about 10 seconds, with no user intervention needed.

It works, but there are still some details to resolve. There’s a timing dependency between when the computer boots, when the Floppy Emu reconfigures as a Smartport HD, and when the bootstrap program restarts the IIgs. I used hard-coded delays that work on my system, but may not work for other people. Get these delays wrong, and the IIgs will fail to boot from the bootstrap disk, or will restart and try to boot from the Smartport HD before the Floppy Emu has reconfigured itself. A better solution would involve some kind of control signal between the IIgs and the Floppy Emu to orchestrate the timing, rather than relying on fixed delays with no feedback.

A second problem is that this trick is incompatible with my (yet to be released) Daisy Chain Adapter. The Daisy Chain adapter senses what type of disk the Floppy Emu is configured to emulate, and acts accordingly. It can’t support a Floppy Emu that suddenly transforms from a 5.25 inch drive into a Smartport HD in the middle of operation. There needs to be some way for it to detect that this has happened, or be notified that it’s happened, so it can reset its own internal state. But so far I’m lacking any practical ideas on how to do that. In the worst case I can simply warn users that this firmware trick is incompatible with use of the Daisy Chainer, but that would be a shame.

Read 5 comments and join the conversation 

Daisy Chainer Update

Picking up after a month hiatus, I’ve assembled one unit of the Daisy Chainer for the Floppy Emu disk emulator, and it seems to be working. I’ve only had time to do brief testing, but so far so good, and the power/ground weirdness observed in the breadboard prototype appears to be gone. Some parts that I planned for proved to be unnecessary, so you can see a few unpopulated footprints on the board. To be removed in a version 2 PCB, maybe.

The Daisy Chainer board makes it possible to insert a Floppy Emu anywhere into your daisy chain of Apple II drives, with other floppy drives before and/or after it in the chain. It provides a nice improvement in flexibility for Apple IIGS owners and other Apple II users with complex drive setups.

As seen in the photos, I ultimately went with the “smart” design that I discussed earlier, with an ATMEGA48 microcontroller in charge of the show. But the firmware couldn’t be simpler: it’s just a 12-instruction loop that reads some inputs, updates three bits of state, and uses a lookup table to determine some output values. I’m still not convinced this was the best approach, since I could have performed the same function with just 2 or 3 basic logic ICs. But the microcontroller is no more expensive, and it’s more compact, and more flexible, so maybe it’s OK even if it does feel like overkill.

Usage is simple: just plug it in and turn it on. The male DB19 (at left in the photo) connects to the upstream drive in the daisy chain, or directly to the computer if there’s no upstream drive. The female DB19 (at right) connects to the downstream drive, and the Floppy Emu connects to the 2×10 header with its ribbon cable. There are no user controls and nothing to configure. The only nod to “human interface” is a set of three LEDs that might be useful for debugging, or for curious nerds. They show the status signals used for detecting the drive type of the Floppy Emu and the downstream drive.

Read 11 comments and join the conversation 

PCB Autorouting

The Apple II Daisy Chainer for Floppy Emu is done, and I’ve ordered a few PCBs made for testing. This proved to be a surprisingly challenging board to lay out and route the traces. It’s a simple two-layer board, and I wanted to keep it as small as possible, so the signal routing quickly became very congested. Hand-routing of the first 40 traces took almost a whole day of tedious work, so I finally gave up and tried autorouting the remaining 80 traces. And it worked! The result looked pretty good, too. I’m curious to know how autorouting has turned out for other hobbyists. Have you ever autorouted nearly an entire board? What were the results?

I haven’t had good results with Eagle’s built-in autorouter, so for recent projects I’ve been using a stand-alone autorouting software package called Freerouting. It’s a Java-based app with a slightly awkward UI, but it’s impressively powerful. First you export your Eagle board file in .DSN format, using a script provided by Freerouting. Then you import the DSN file into Freerouting and let it work, running for about 1 to 15 minutes. When it’s finished you can export an Eagle session script, which will rip up all your old tracks and lay down the new ones calculated by Freerouting.

Obtaining good autorouting results requires careful setup of Eagle’s design rules. For example, the default might be to use 8 mil traces with 8 mil minimum spacing between traces, but power and ground might be treated as a separate net class requiring 20 mil traces for extra current-carrying capacity. The design rules also define what size drill to use for vias, and how close to the edge of the board it’s OK to route traces. The autorouter takes all of these constraints into account when it does its job.

So what’s not to like about the autorouter? Can a skilled human do a better routing job? Why not autoroute everything? Here are a few drawbacks that I found.

 
Fixed Component Placement – When I route by hand, I’ll sometimes discover that I’ve placed a component in the middle of a chokepoint for PCB traces. If the placement isn’t critical, I can move the component to make routing easier. The autorouter can’t do this, at least not that I’ve seen. It treats the component placements as fixed and immutable, even when nudging a resistor 10 mils to one side could make a huge difference.

In theory there’s no reason that the autorouter couldn’t handle changing component placements. Additional constraint information could be supplied, providing a bounding box of acceptable placements for each component, or tagging some component placements as critical and non-movable.

 
Unnecessarily Aggressive Routing – If the design rules say that 8 mils is the minimum acceptable spacing between traces, the autorouter will often stack traces 8 mils apart even when there’s plenty of room for wider spacing. It’s too aggressive – pushing spacing to the limit when it doesn’t need to. In theory this shouldn’t be a problem, but it feels like poor design practice to me. To avoid the risk of accidental short circuits, I prefer not to push the PCB manufacturing limits except in those few areas of the board where there’s no alternative.

A good example is autorouting between adjacent pins of a 0.1 inch header. There’s roughly 30 mils of space between the metal rings that surround adjacent pins, providing enough space for an 8 mil trace with 11 mils of space on both sides. But Freerouting often placed such traces off-center, with 8 mils of space on one side and 14 on the other. It met the design rules, so from its viewpoint there was no reason not to do it that way.

In practice an 8 mil minimum spacing is already conservative, and most PCB manufacturers can do 6, 5, or 4 mil minimum spacing. So it’s unlikely this behavior will cause any trouble here, but it might for other boards with smaller minimum spacings.

 
Nuances of the “Best” Routing – Once Freerouting finds a routing solution, it tries to optimize it by minimizing the total trace length and the number of vias. These are good optimizations, but sometimes I want other considerations to trump them. For example when I route manually, I try very hard to minimize vias in power and ground traces. I would be happy to add 5 extra vias elsewhere if I could eliminate one via for power or ground. Freerouting doesn’t support this kind of trade-off, so all vias are treated equally.

A related consideration is the number of power and ground paths. The autorouter considers a pin to be powered if there’s any combination of traces leading from the power supply to the pin. Only one such path is required, and the result is a logical tree with the supply at its root and the power pins at the end of the branches. But when I route manually, I often connect branches back together, creating multiple paths from the power supply to the pin. I use the same approach for grounds. The goal is to minimize the voltage difference between power and ground points on different regions of the board.

The autorouter doesn’t care about visual aesthetics, and normally I don’t either. But when two possible routes are equally effective, I normally choose the one that’s similar to other traces I’ve already routed. It makes the board’s interconnections easier to understand at a glance.

Freerouting also doesn’t account for any potential analog signal effects, at least not that I’ve seen. If it’s important to minimize the trace length for a specific signal, or match the trace lengths of two signals, it can’t help. It also doesn’t consider problems like the parasitic capacitance formed by two long parallel traces. Depending on the signals, the signal speed, and other factors, a skilled human might choose to route two signals on non-parallel paths even if parallel routing was the shortest distance with the fewest vias.

Do you have any autorouting secrets to share? Let’s hear them!

Read 5 comments and join the conversation 

« Newer PostsOlder Posts »