ATxmega programmer for $0.50 or how to make your USBASP support PDI
Do you know XMEGA, the new family of AVR microcontrollers? They look really sweet, especially for someone who already mastered the AVR architecture. More speed (32MHz!), more peripherals (5 USARTs! 16 PWM channels!), modular design, and you can still use the same well known tools. And then you read about the programming interface and... what?! What happened to ISP? No way I would purchase a completely new programmer model just to play with their new MCU!
|V-USB interrupt disturbing the PDI clock
- but not breaking it
Fortunately, implementing the new programming protocol in USBASP was not that hard. Initially I thought it would be almost impossible, because PDI requires a constantly clocking signal and disconnects if the clock rate drops below 10 kHz. Strict timing is a problem for V-USB (USB protocol implementation used in USBASP) as it handles all USB transmissions in software and cannot do both things at the same time (like a guy who lacks brain power to walk and talk at the same time). The tests showed that the interrupt handling a basic control transfer only steals 40-50 us, and this is short enough to allow for the reliable PDI bit banging. Sending more payload (more than a regular control message) would break the clocking but the programmer can be scheduled to work in batches, so it gathers all data from the usb and only then begins the PDI transmission (hoping that there will be no new USB transmission for a while).
|Bit-banging clock (to the left)
and timer clock (to the right)
My implementation switches to the hardware timer clocking to keep the clock running during the interrupt-intense USB transmissions. It is not really necessary because the programmer could also disconnect and reconnect after each transmission, but I think the PDI might like the continuous clock better ;-)
R1 and R2 seem redundant but I put them here after the official Atmel PDI documentation. The thing is, the DATA line is bidirectional and the physical layer should be able to detect collisions. My implementation does not do it, but it could, thanks to the MISO line (maybe someone will implement it some day...). Another weird thing is RESET connection, it looks like it should be GND instead, and yes, this is GND, that can be disconnected at will. Permenent GND connection breaks the PDI bus-keeper so it must be disabled before receiving anything from PDI.
If your USBASP is 3,3V then it would be more simple:
1. USBASP Firmware supporting PDI
Unpack, apply the patch, compile:
Note: ATmega48 is not supported because its flash area is to small for the increased program size. I only tested it on ATmega8 because that's what in my USBASP. ATmega88 should work, too.
2. AVRDUDE supporting USBASP with PDI
|The canonical flashing LED!|
- Add a simple interface to USBASP and you can program ATxmega
- If you already have USBASP then the interface can be made in minutes almost for free (but if you have to buy USBASP, it is still the least expensive way to program ATxmega)
- Upgraded USBASP can still program old AVRs (without the interface)
- There is a catch: you have to install a new firmware in USBASP using another programmer