That perfboard looks handy, but I find stripboard, e.g. Veroboard, or cheaper copies, easier to use.
Though there is the added expense of a track-cutter.
I still prefer to start with a re-usable socketed breadboard until I’m happy with the circuit design, and only then transfer it to a permanent soldered version.
For perfboard I like to use wire-wrap wire, but again you need a few tools, at least an insulation stripper, some needle nose pliers and a side cutter. Better still a wrap/unwrap tool to twist it around the leads of the components before soldering.
No, this is not really wirewrap, where an engineered square pin with sharp corners is used without solder, it’s just a hybrid way of quickly wiring then soldering things up, that works nicely IME.
A big illuminated magnifying glass on a stand also helps.
The wire-wrap wire is very easy to work with, the insulation very resistant to heat/botched soldering, and being silver plated, solderability is excellent.
As Flashy Mike has shown, building a development setup can be simple and inexpensive, whichever way you do it. I have two of the FastTech USBasps which work well, I didn’t realise that they also sold Atinys already mounted on 0.1” leads, I’d better have another look.
I’d recommend starting from the schematic of the BLF Q8 driver.
This is the classic FET+1, perfected by DEL, which is at the core of many subsequent drivers from other designers.
Note: R1 and R2, the old voltage divider, are not populated, current firmware uses a different method to measure cell voltage, and this, along with other firmare changes, reduced power consumption dramatically and freed up another pin (for e.g. driving a second bank of 7135s).
However if you want to experiment with e.g. BLF A6 or X6 drivers, and their simpler firmware, you would need to put them back.
DEL was generous enough to publish it, instead of only showing a PCB layout, and leaving it to the inquisitive to puzzle it out by reverse-engineering.
Here it is:
Open the image in a new tab and you’ll get the full size version from dropbox.
It is set up for Aurdino coding, including their bootloader.
Which is fine. And has opened up some sort of coding to a great many.
But if you want to use C, rather than their interpreter, and develop compact code to run on a minimalist embedded device, best off starting in Atmel Studio and learning the hard way I think.
For which I think you will need an USBasp, not an Isp, (or the basic USB connection baked into these things, with their bootloader, that takes up a lot of space).
I have no idea how tricky it might be to return these things to vanilla Attiny 85s, but it might even require a high voltage programmer to re-set some fuses.
They do look good though, I suspect the one you linked to, and many others, are now knock-offs. The real ones from the original designers cost much more, and are now unavailable. But still less than a cup of over-priced coffee, or half a pint of “craft” beer. Sad.
Take a look at e.g. Julian Iletts channel for some background. This is a very old video (2014) but explains a few things.
And yes these MCUs have been around for a long while. Consider them mature (extremely so).
I have a USBasp on the way. I was planning to use that to reprogram the ATtiny85. The board brings all the pins out to headers, so I wouldn’t even need a clip. It didn’t occur to me that the USBasp might not be able to change fuse settings. If it doesn’t how do people set the fuses?
< sigh > I need to finish reading the 25/45/85 data sheet.
If it doesn’t work it was only a couple of dollars. I might be able to use it elsewhere.
I was planning on using Ubuntu with avr-gcc to compile.
If the usbasp can flash the firmware, it can also set the fuses. But if the MCU is very underclocked or uses the reset pin, it could require high-voltage reprogramming.
As for learning, there is a fairly significant amount of example code in the repository to learn from… and for making e-switch UIs, there’s also a UI toolkit which eliminates most of the need to touch low-level code. The toolkit takes a significant chunk of ROM, but it makes the rest of the process much easier and may also reduce code size overall compared to older coding styles.
