Is it a very bad idea to use a cheap USBASP variant like <a href=https://www.aliexpress.com/item/WholeSale-New-USBASP-USBISP-AVR-Programmer-USB-ATMEGA8-ATMEGA128/32272453926.html?spm=a2g0s.13010208.99999999.262.RJ2ZJK>this one?
not sure i haven’t been able to make mine work and i am using the cheap one.
FWIW, the firmware repository has a file in the root directory called “README”, and it has a shopping list for parts known to work. The usbasp there is only $2.15:
https://www.fasttech.com/product/1002900-atmega-attiny-51-avr-isp-usbasp-usb-programmer
I know that in this case paying double is not a big deal. I wanted to try to find the cheapest useful variant for the sake of knowledge. But with comments like “i haven’t been able to make mine work” I don’t think it’s worth to try. I’ll go with fasttech. Though I’ll use a cheaper clamp and cables to stay under $5.
Thanks for the answers.
Why?
When it comes to fiddly things like flashing MCU’s, I’d rather get decent parts. What’s the point of buying a clamp or cable that only works 75% of the time? When it doesn’t work, I find it very frustrating. The loss of time to reflash it will cost more than if you just bought the better parts. Don’t you think?
Several reasons.
- I expect to use this setup only several times. Though I don’t know.
- When it comes to clamp, the only known good alternatives are very expensive when shipped to Europe. This one is known to work, but there are indeed problems sometimes.
- The point is not to get something that works badly, but something that works decently. If I had a good chance of finding one for half the price, I could risk that this expense would be wasted. Really, I would regret another wait more than the lost money.
The SOIC8 clip I use is definitely pricey… and digikey’s shipping is kind of ridiculous. They insist on sending a box, even when ordering something as small as a few tiny surface-mount resistors.
A cheaper clip is the most effective way to save money on flashing hardware, particularly because it’s the most likely part to wear out during regular use.
Depending on how driver development goes, we might end up going with different MCUs and acupuncture-style flashing eventually, which would make the clip unnecessary and would also make it possible to flash the driver without removing it. But that hasn’t happened yet, except for a few drivers Mike C made.
Or there’s the option of using a MCU with enough space for a bootloader, and doing the “flashing” by literally flashing lights at it in a special firmware update mode. It would be a lot slower, but requires no special hardware at all — just a web browser on a reasonably bright screen.
But for now, a SOIC8 clip is still the way to go.
i have successfully flashed atmega based brushless escs with the same programmer but for some reason never got it to work with attiny but i am using pogo pin instead clamp in the case of atmega brushless esc.
A boot loader would be wonderful. I took a brief look at picoboot but haven’t had time to pursue in earnest.
I can cope with some frustration from the SOIC clip when flashing working firmware; but I have limited patience[1] with the SOIC clip and programmer connections when developing firmware.
I can (mostly) leave the SOIC clip in place but my off the shelf programmer must be disconnected and reconnected each edit/compile/flash/crash-and-burn cycle. There’s something about being unplugging the ribbon cabe that my off the shelf programmer doesn’t like so I wind up disconnecting/reconnecting it from the computer too.
That’s annoying to me…
I experimented quite a lot with solutions. What I’ve come up uses tri-state buffers to isolate the driver from the programmer during testing. Such a device could sit between the programmer and the driver. Mine sits on top of a Raspberry Pi Zero. The rPi runs AVRDUDE and is the also programmer.
That board also features a logic level serial input from the driver to the rPi to capture debug messages from the driver using a bit banging serial routine. With that I can leave all of the cables and the SOIC clip in place. I press a button to enable the buffers while the program loads.
But it’s still vulnerable to the SOIC clip deciding to jump off of the driver. So (for development purposes) I decided to solder a connector to the MPU. About that same time same time I decided I wanted/needed to be able to carry a work in progress into the field ; especially the more eccentric/novel firmware designs.
My first go at that happens to involve a PIC based H1-A but I’ll do this again with an AVR when the time is right.
This approach is especially helpful with the H1-A because you can’t simply just take an H1-A in and out of it’s host. The inductor must be moved and pin 4 modified for programming.
[1] My first job (decades ago) involved programming a handheld computer. It was never intended that anyone program it in assembly so there wan’t a good program loader. The first hack (that we lived with for a while) loaded one byte per second into the device — which inserted several minutes in the edit/compile/debug cycle. But even that wasn’t as frustrating as an SOIC clip that won’t clip.
I have a bunch of different dev hosts for different hardware types. I usually just use the head of a light with driver hanging out, and a pair of red/black wires or clips on the spring and ground ring. I power it with either a battery or a bench power supply, and clip to the MCU when I need to reflash. The usbasp generally stays in a basket with all the dev hosts I’m not using at the moment, except for a few seconds each flash when it’s plugged in.
It’s really low-tech but it seems to work fine for my purposes and is easy to take with me to work elsewhere. This is all I need:
I have the expensive clips from the two leading manufacturers and the cheap black ones for a few $ from ebay. The cheap ones are definitely the best.
For anybody having problems to program the Banggood FET+1 drivers this thread might be helpful:
that might be it, i’ll swap and try with tiny25.
The cheap clip is nowhere near that bad. I have one and have done hundreds of connect-flash-disconnect cycles with it on cramped 17mm drivers. It works fine as long as you clip it on straight.
Cool. Good to know.
Thank you everyone for all the information in this thread (as well as the linked ones). It has been extremely helpful.
I am using a windows 10 pc (although I also could use Fedora 26 if I had the right tools on there) and Amtel Studio 7.
I have successfully connected to a QLite driver from MtnElectronics, cleared it, and flashed Battcheck, Minidrv, and Star_1mode onto the driver.
I want to put on Crescendo from TM, but cannot get it to work properly. Everything looks fine, I can compile and create the hex file, but the resulting hex is SO short I think it is not correct.
:1000000009C00EC00DC00CC00BC00AC009C008C09A
:1000100007C006C011241FBECFE9CDBF02D002C069
:08002000EFCFFFCFF894FFCFF2
:00000001FF
My first thought was that it wasn’t properly getting the linked H files (tk-voltage, tk-attiny, tk-calibration, tk-delay, and tk-random), so I downloaded those and put them in the ATTiny DFP folder on my machine (where there were other H files) but that doesn’t appear to have helped.
Anyone have any tips, or any other firmware I should try for the QLITE?
As far as code changes to the Crescendo, I did the following:
Uncommented the “#define ATTINY 13” line
Uncommented the “#define NANJG_LAYOUT” line
Uncommented the first two lines under “// Common nanjg driver” line
Commented the two lines that were open for the MTN17DDm driver (I think that was the one that was active by default)
Other than that, I didn’t really change anything. I believe the NANJG is the correct one for the QLITE driver, and I think the ATTINY 13 is correct fo rthis one (although it is the ATTINY13a, so maybe that is the issue)
A few times I tried commenting out some code for strobe and bike modes, in case overall space was the issue, but I don’t think those would effect the compile (just loading it on the driver would be the issue there, I assume).
To run Crescendo on tiny13, you’ll need to disable memory and thermal regulation and config mode. The attiny13 has no temperature sensor, and it does not have room for the optional memory feature. Or perhaps grab an older version from the repository, which should have a qlite-compatible .hex file already built. I was originally aiming for Convoy’s drivers, but Simon didn’t want to try it this year so I made it a bit nicer and mostly targeted FET+1 tiny25 drivers instead.
About size, there should be an option somewhere to see the compiled size and find outh whether it fits. This is done in the build.sh script automatically, but I’m not sure where the option is in Atmel Studio.
More generally, check the bin/build.sh script for compiler settings it expects. It may be easier to build and flash these in Fedora instead, after installing gcc-avr and avrdude and bzr.
I’ve never used Atmel Studio, but I do find compiling and flashing to be very easy on Linux. TK’s build and flash scripts make it even easier!
And not to take away from Crescendo, but if you’re looking for something ready to go on the Qlite, the ramping firmware I threw together is aimed at those drivers. It certainly lacks some of Crescendo’s features (eg, no blinkies), but is ready to go for the attiny13 while retaining memory and a couple other options. And if memory serves me right, it currently compiles at < 800 bytes, so there’s plenty of room for customizations. Tap to stop, tap again to resume ramping. Double tap to jump to turbo.
Runtime config menu:
- Memory toggle
- Stop-at-the-top toggle (without any user interaction, stops itself at turbo)
- Turbo Timer Toggle (turbo steps down to 50%)
- Reset to default configuration
Thanks TK, I’ll give those a try now. And thanks gchart, I’ll probably start by trying to flash yours 
All of you do great work here, and I really appreciate the help.