Now that the v3 hardware is in process, it's time to think about the firmware.

I'm going to hold my nose and use Atmel's IDE under Windows just because it seems to be the path of least resistance (and I'm in a bit of a hurry). The hope is that they have some sample code for a USB mass storage device, and some more sample code for an SD card reader. If the two can be stitched together, then the hope is that it will be relatively simple to adapt the A/B switching, encryption and the rest of the UI from the v2 LUFA code.

To load the firmware, there are two options. One is the SWD interface on the board. I believe it should, in principle, be possible to attach the ribbon cable from my ATMelICE's SAM port to the board and use that for programming. But in addition to that, the datasheet seems to indicate that the blank chip will come up on the USB bus and present a CDC interface over which programming can take place. In addition to that, I've added an ERASE jumper to the board that hopefully will return the chip to this same state, allowing pure USB programming to be the preferred method. This would allow for field firmware updates more easily - the user would jumper ERASE and connect power briefly, then remove the jumper connect USB and run some sort of programming software to load the new code in.

For proper security, end users will want to seal Orthrus inside of a case of some sort. The purpose of the case will be to prevent access to the SWD interface (the fact that there's an interface on the board layout doesn't imply that the lack of one would make SWD impossible to access without it). A laser-cut acrylic layer case that screws together along with a pair of tamper-evident adhesive seals would be sufficient to allow access only to the USB port, the two SD card slots and the button. With access only to those ports, it will be much more difficult to implant rogue firmware (I won't say impossible because I can't know that for certain).