Meta

AVR programmer fix

Intro

If you work with development boards you know that they usually connect through USB which provides power, can program and debug the micro and you also get some virtual serial port. Most external programmers not so much, they only do the programming and debugging thing. Except the pickit2, and even though I don’t use PICs anymore this is still by far the best programmer I have ever used. The reasons are simple: through its 6 pins interface it can program/debug, you can choose whether to supply power and at what voltage, you can reuse the pins as serial port or even a simple logic analyzer. Of course, the next version pickit3 is totally crap, but that is another story.

Towards the Xmega

Recently I have decided to give up on the AVR tiny and mega and use some sort of xmega for everything not requiring ARM, due to lack of time to switch between architectures. It does not make sense to lose time switching between devices while building only a single or small number of devices at hobby level. I would have jumped for the SAM D20 for everything, but its peripherals are inferior and it burns too much power while idle, even though the core is so much better. In most projects I don’t mind having at least 3 cables to the board: power, programming and serial port.

But I have recently started to develop some wireless nodes and needed to switch the programming cable and serial port and power between boards, which was making me lose a lot of time. At this stage of development I prefer to keep the debugger attached, not rely on the serial port debugging only, so a serial port based boot loader is useless. It gets quite a bit cluttered:

I realized that while using XMegas I could actually squeeze all 3 cables in the original 6 wire programming cable because 2 of the 6 wires on the ISP connector are not used in the PDI connector so they can be replaced by serial TX/RX. Power can be injected at the programmer side as well. A USB hub can provide one input and two ports, one for the programmer and one for the serial port adapter. So I started the build, first modifying the hub. Since I don’t have a short enough micro USB cable a long one was sacrificed, but rest assured, I will use the other half as well.

Then I built a module that can inject power and pass on the serial port instead of the MOSI and SCK ports. I have settled on using only a fixed 3.3V power supply, as I highly doubt anything else might be needed. I chose to include a separate regulator because the serial port adapter cannot provide enough current through its 3.3V output. This way about 200-300mA should be available for the development board, the rest being consumed by the hub, programmer and serial converter. A double pole switch allows the led to signal that power is being applied without being turned on by power applied from the board. Using a bi color LED i can signal the 2 situations: green means there is power on the board while yellow means there is power on the board and it is applied from the module. Here’s the schematic and the finished module:

I have put everything together and used tape to fix them to the Atmel ICE programmer, that way if I ever need to detach it and use separately, it will be a quick fix. The result is quite a monstrosity:

Now, the small xmega header board can be used with a single cable attached:

Of course, the board needs to have the serial TX and RX connected to the 2 available pins on the ISP connector, but this is a fix I will implement in future versions of the board

The finished device is rather large compared to the pickit2, but maybe someone from Atmel can take care of implementing these features in future versions of the atmel ICE, or AVR-ISP 3 or some other programmer/debugger.

8 comments to AVR programmer fix

[…] Have you ever needed to look at what is going on on a serial port and not have a PC/smartphone around because the location was a bit inaccessible? I did not need this until now, but now I do, so I was looking for a solution. After building this, I think that it would be a good addition to the modified programmer. […]

[…] [Bogdan] makes a good point. When you use a dev board you get programming, debugging, power sourcing, and usually a UART. When you go to the trouble of hooking up a programmer why don’t you get the same thing? Astutely, he points out that all you usually get with programmers is programming. So he set out to add features to the hardware he uses to program XMEGA. […]

[…] [Bogdan] makes a good point. When you use a dev board you get programming, debugging, power sourcing, and usually a UART. When you go to the trouble of hooking up a programmer why don’t you get the same thing? Astutely, he points out that all you usually get with programmers is programming. So he set out to add features to the hardware he uses to program XMEGA. […]

[…] [Bogdan] makes a good point. When you use a dev board you get programming, debugging, power sourcing, and usually a UART. When you go to the trouble of hooking up a programmer why don’t you get the same thing? Astutely, he points out that all you usually get with programmers is programming. So he set out to add features to the hardware he uses to program XMEGA. […]

[…] [Bogdan] makes a good point. When you use a dev board you get programming, debugging, power sourcing, and usually a UART. When you go to the trouble of hooking up a programmer why don’t you get the same thing? Astutely, he points out that all you usually get with programmers is programming. So he set out to add features to the hardware he uses to program XMEGA. […]

[…] [Bogdan] makes a good point. When you use a dev board you get programming, debugging, power sourcing, and usually a UART. When you go to the trouble of hooking up a programmer why don’t you get the same thing? Astutely, he points out that all you usually get with programmers is programming. So he set out to add features to the hardware he uses to program XMEGA. […]

[…] [Bogdan] makes a good point. When you use a dev board you get programming, debugging, power sourcing, and usually a UART. When you go to the trouble of hooking up a programmer why don’t you get the same thing? Astutely, he points out that all you usually get with programmers is programming. So he set out to add features to the hardware he uses to program XMEGA. […]

[…] [Bogdan] makes a good point. When you use a dev board you get programming, debugging, power sourcing, and usually a UART. When you go to the trouble of hooking up a programmer why don’t you get the same thing? Astutely, he points out that all you usually get with programmers is programming. So he set out to add features to the hardware he uses to program XMEGA. […]