I'm a big fan of tinyisp's, and have made a few of my own versions with custom firmware... But...
For one project a long time ago, I needed to flash an SPI-programmable AVR co-processor from an ESP8266, as a side-effect, I could drag-and-drop AVR firmware into my browser and it would automatically flash it.
Fast forward, to needing an AVR to run side-by-side with a Pi, I made that GPIO-based SPI programmer much more generic.
https://github.com/cnlohr/cnpiha...
And, now, more recently, I needed a TPI programmer. Unable to use my Tinyisp, and still loving the Linux "make automatically builds, flashes and handles fuses in about a second" environment, I decided to write a GPIO-only TPI flasher, which also worked out surprisingly well. Could even do HV programming with nothing more than an alligator clip, 12V supply and my raspberry Pi.
https://github.com/cnlohr/pi_tpi
I'm currently looking into expanding these environments to cover the UPDI interface, despite having no use in any UPDI-enabled processors.
From my point of view the GPIO-only flashing features really enable a LOT of options that would previously be awkward.
For instance, if you want an AVR to handle real-time stuff on the RPI, you would normally have to use a programmer to flash the AVR, but by having it on-board you can type "make" from within the Linux environment and everything _just works_.
I'm really curious what I could do to further spur any other interest in the community, maybe for contribution or use. Surely there are other folks out there who strongly prefer the "make" environment for build-and-flash for rapid-pace code development.
