Add Pololu USB AVR Programmer AVRDude -t compatibility

In various documentation, like section 3.d of the user manual, this is stated: "AVRDUDE’s terminal mode (the -t option) is not compatible with the programmer because the programmer will exit programming mode and release the target A VR from reset if it receives no programming commands for 1400 ms."
I (and I think many other AVRdude users) would appreciate fully -t compatible operation, without that timeout. This would then be fully avrispv2 compatible.

  1. Best approach might be to add a USB AVR Programmer Configuration Utility option to disable that timeout. Being able to advertise complete avrispv2 compatibility wouldn’t be bad for Pololu. But this may require changes to both the utility and the Programmer’s firmware (latest version only). Any chance this feature could be added?
  2. Alternatively, a “keep alive” option specifically for the Pololu USB Programmer could be added (by me) to AVRdude: is there a safe “null” character or command which is safe to send serially to the USB AVR Programmer every 1.3 seconds during no-traffic periods, which merely resets the USB AVR Programmer’s exit/release timer?

I guess I’m most interested in (2), if there’s any information about that…


Thanks for the suggestion on how to improve the programmer.

We never had much hope of being totally AVRISP v2 compatible. Our programmer uses a different set of frequencies for programming. Also, in recent firmware versions we have changed the signature from “AVRISP_2” to “STK500_2”, so it is not even identifying itself as an AVRISP v2 any more. This was necessary to support AVR Studio 5 and Atmel Studio.

Please note that keeping your AVR in programming mode for long periods of time can be dangerous; if your batteries wear out or the power gets disconnected during that time, it is possible that your AVR’s fuse bits could be corrupted and it would become unusable.

Your idea of sending a keep alive command from AVRDUDE would work. The 1.4 second timer gets reset after any STK500 command, even if the command byte was not recognized. I would recommend sending a CMD_GET_PARAMETER command that reads the PARAM_STATUS parameter.

Have you contributed code to the AVRDUDE project before?


Thanks for responding. I appreciate the struggle required to maintain compatibility with new development suites.

The shorter and less intrusive the “keep alive” poll command is, the better. I suppose I was hoping for a truly “null” command which has no effect on the current command buffer (simply skipped), and generates no response from the programmer, but merely tickles the timeout timer. But maybe there no truly “out of band” character that fits the bill, never used either in commands or data. Too bad - it would be nice for the background tickler process to be completely invisible.

No, I haven’t contributed to AVRdude yet, but this seems like a reasonable opportunity.