When I first encountered Tiny chips, it felt like a bit of magic. Such a tiny, $1 thing had a mind of its own, it could run my code, blink GPIOs, and everything. Yes, perhaps it has a smaller CPU and less memory than others, but those limitations are possible to overcome. Better still, people have rewritten Arduino frameworks and key libraries to support Tinys, so in most cases you won’t have to reinvent the wheel. Fantastic!
I just had to use it in my projects.
If you were looking for a history of the ATtiny Flasher, the first thing you’d find on the internet is my "Use ArduinoISP sketch" article. It explains how, with just a few wires, a resistor, and a capacitor, you can flash Tiny on the breadboard.
Obviously, this required a custom PCB that could do that whenever I need it. This made for a simple but handy tool.
I immediately identified room for improvement. Smaller and bigger issues became apparent as I started implementing practical Tiny projects.
First, you constantly need to move Tiny from Flasher to breadboard and back to flash updated code. And Tiny’s legs tend to break after a hundred moves or so.
Of course, you can connect Flasher to a breadoard with breakout wires, but then another issue arises: breadboard components can interfere with the firmware flashing process, especially those sitting on the SPI bus.
So, the next round of redesign produced a considerably different tool. Essentialy, it would address the first issue by allowing both in-socket and in-breadboard flashing. But, more importantly, it would have the 74HC126 buffer IC on board that would connect host with target only during flashing.
Another obvious improvement was to make the tool also deliver power to the breadboard. As an experimental feature, I added a serial connection beetween host and target, since by then I was getting tired of debugging with LEDs.
Revision C of the Flasher introduced minor improvements to the previous design. At this stage, I decided to go public with the project and launch a Crowd Supply campaign.
Although Flasher was already my favourite child, I thought it had to be much better than its competitors to succeed.
Thus, in the next revision, I would aim higher and implement a superior design.
One large flaw with motherboard designs I’ve used before is that the Nano board can never deliver actual 5 V due to the protection diode. Another problem is that all Nano clones are slightly different in design and size, so it would be very hard to ensure the Flasher would fit them all.
So, the Nano had to go in, the MCU would live on the board.
Since I had a bit more space and pins now, I decided to add a high voltage programmer (anyone can appreciate another GPIO when they have just five, right?). Since it’s no longer possible to pull out the Nano for reflashing, I had to add a switch to allow the programming host and target to use the same USB port.
Also, since you generally don’t want to suddenly inject 12 V into your breadboard design, so another switch was added to ensure you can’t enable HV programming accidently. Finally, a third switch was added to turn off the serial bridge, which pulls lines high when enabled, which can be quite unfortunate at times.
The biggest issue with the HV programmer was that it uses an extra pin for programming. That means some SPI pins would have to switch directions, which in turn would render my buffer IC useless.
So, the 74HC126 quad buffer had to go, freeing space for 74HC241 octal buffer, which can serve both low and high voltage programming, depending on the need (and comtrolled by host).
Also, the target reset circuitry had to be redisigned, since existing HIGH, LOW and HIGHZ states had to add 12V-HIGH option.
Well, all in all, I’m happy to say I received the board prototype a few days back. Both the reset circuitry and LV flashing work, which leaves me with the task of updating the code to support a seamless flashing experience in both HV and LV modes.