self-contained SD based AVR programmer

I spent some time going through the XMega D manual. One thing I found out was that the actual SPI system isn't going to be the best choice for AVR programming. The issue is that the clock system is designed to go way too fast. The slowest you can make it go is CLKper / 128, which for a 32 MHz system clock is 250 kHz. As an alternative to that, you can instead put the USART into SPI Master mode. In that configuration, you can use the USART baud rate generator to essentially make arbitrarily slow clocks. If there's a downside there, it's that the highest clock speed available is 2 MHz, but that's fine. By setting the USART0 and SPI bits in the REMAP register for the port, you can force the USART to be pin-compatible with the SPI system. But since the USART is going to wind up being the only peripheral used - whether in synchronous, asynchronous or SPI mode - it's possible to revisit this in the hardware later so that it won't be necessary.

I know, this project has been rather quiescent.

One unknown was whether the trick of using a charge pump to supply the LCD contrast voltage would work or not. The basic idea is not completely unknown, but I had never done it.

To recall, the XMega controller at the heart of this project only works at 3.3 volts, and the LCD spec says it requires 5 volts. If you didn't use this trick, then ostensibly you'd need half a dozen bidirectional level shifters to bridge the gap. In fact, the LCD controller chip in the module works just fine at 3.3 volts, and the LCD simply requires the contrast voltage to be around 4.5 volts lower than Vcc. So using an inverting charge pump to make -3.3 volts would allow the contrast voltage to range between 3.3 and 6.6 volts lower than Vcc.

Well, I built up a Toast-R-Reflow II controller with a 3.3 volt supply for the entire system (it had a 3.3v thermocouple interface chip, so it was a good candidate), and sure enough, the LCD works just fine.

Now I need to port/replace the Arduino LiquidCrystal library to straight AVR libc.

At least for the initial version, one limitation on the hardware is going to be that for TPI, PDI and UPDI, the unused pins will not necessarily be quiescent. It's on the user to insure that the NC pins of the programming interface are actually not connected, or that unexpected signals on those pins won't do any harm. They will at least be confined to the target power voltage range, but for example, MOSI will have a copy of the transmit data on it and SCK will have a copy of the clock during PDI.

Also, target power will only be applied while programming takes place. If configured, target power will be applied and after a brief delay (perhaps 10 ms or so) the programming cycle will begin. When it's over, target power will be dropped.

At boot, you get the first project on the disk

<PROJECT>
<- Remount, -> Select

 You use up and down to scroll through the projects. If you go left, the power for the SD slot is turned off and you get:

Insert SD card
-> when ready

Click right and you go back to the beginning.

After picking a project and clicking right, you get

<PROJECT>
<- or -> last:NONE

 This is telling you you can use the left button to go back to the selection menu, or right to start an operation with this project. last:NONE is telling you that the result of the last operation is undefined.

Click right and the operation begins:

SECTION: FLASH WRITE
***

The bottom row is a progress indicator for each sub-task. In general, you can expect first a chip erase operation, then the fuses are set and verified, then flash and lastly EEPROM. 

At the end, you go back to the previous screen, with "last:GOOD" instead of NONE, assuming there were no errors. If there were, it would be "last:BAD"

If there are errors, the error is shown and the screen paused for a second before going back with "last:BAD"