Ups ! Got the reset wire mistaken with TX - no problem... Used a Raspberry Pi with linuxspi and special version of avrdude to program the firmware onto the USBasp (then I discovered my mistaken reset) - USBasp alpha works very well.
Edit: And it's lightning fast on 4Mhz target when you remove JP3 connection :D, perfect auto clock 
Ok,
So I finally hooked up a 32khz crystal to an AVR.
And sure enough it fails to auto select the correct clock (picks a clock that is too fast)
But not all the time.
avrdude is not handling the ISP interface as well as it should, and I found a bug in avrdude that needs to be fixed which is triggered by this particular failure, but neither of those should be causing the USBasp device to pick the wrong clock - one that is too fast.
It picks the correct clock and it works for reading fuses. But the way avrdude does its flash update causes the USBasp device to re-negotiate the SCK clock after erasing the flash but before writing to it.
This specific sequence fails every single time on the 32Khz clock.
Then because avrdude doesn't check the initialization status on the second initialization, it attempts to write to the part even if the initialization failed (which it does in this case)
Now I just need to figure out why this happens and what can be done in the f/w to fix it.
It may turn out that certain FCPU frequencies won't properly auto SCK clock select.
Worst case for this, I could remove 16Khz and replace it with 8Khz so 32khz crystals would work,
but then other faster clocked AVRs would end up running slower.
Anybody have any ideas/suggestions on what low frequencies people are really using, in case it comes down to having to make some hard choices?
--- bill
It picks the correct clock...
...
Worst case for this, I could remove 16Khz and replace it with 8Khz
Wat clock did it pick? 16KHz? That is too fast, it should pick something < 8KHz.
If it picked 16KHz, that is no bug there will always be frequencies at which usbasp picks an out of spec isp clock. In those case -B should be used.
i agree that very slow clocks should be handled by -B. imo best to shoot for fastest download speed possible. one of the reasons i use a custom download utility is because it takes half as long to flash a chip compared to the "standard" method. as close as possible to theoretical spec for charge retention.
time is not always a concern for hobby use but every second saved can be a big deal if you download hundreds or thousands of times a day on a serious project. personally i get very upset staring at slow progress bars whether its work or play.
This issue does not affect the -B option. The selected clock with -B should always work.
This is an issue with auto SCK clock selection.
My philosophy is that when using auto SCK clock selection "just works" is a higher priority than clocking as fast as possible.
This is because when using the Arduino IDE, you can't easily insert a -B option to fine tune the clock.
And when not using the IDE using -B is an easy option to use to ensure you get what you want.
There are a few coding issues in both avrdude and the USBasp code.
I'll take the detailed discussion offline with Peter but here is the high level summary:
When flashing new code, avrdude tells the USBasp device to initialize everything,
After waiting a small period of time, avrdude calls some code to re-initialize the USBasp device,
which does the same sequence above which sets the clock back to auto select, and does a "CONNECT" again, even though the ISP signals are already connected.
The connect code then ends up picking 16Khz clock this time.
Then when the Enter ISP programming mode command comes in, it fails to sync with the target which is running at about 32768 Hz.
The odd part is that in order for the auto SCK code to pick a clock it had to enter programming mode using the selected clock.
The auto SCK code then resets the target to allow the next enter programming mode to work.
I think what is happening is that the sequence that avrdude is using is triggering something in the USBasp f/w that is not properly handling the ISP signals. There may be an issue with unreset in that the timing may be too short at such a slow clock, or it could be that avrdude is not waiting long enough after sending the chip erase using a pass through command.
Anyway, I'm about to start digging into it.
I've got gdb up and running on avrdude, which is quite helpful to see what is happening.
The reason I asked about what the popular clock rates were is that if 32768 is used more often than clocks between 64Khz and 375Khz, the auto select table could be altered to make things work for 32khz if it turns out that the auto sck code can't be made robust for this frequency.
At this point, I still believe that the auto sck code can be made better to handle it.
--- bill
Ok some progress.
This has been quite challenging to track down what is happening.
While I think there is likely to other issues beyond this one, here is an update on what I've found so far.
I am seeing an interaction of avrdude, the USBasp f/w, and the V-USB f/w,when auto sck mode is used and the sck clock is slow (under 2Khz).
(lots of things interacting)
avrdude has code in it to limit the size of the flash write block size when the sck frequency starts to get slow.
The issue seems to be that if you don't reduce the block size, the time to write the flash will block the usb poll loop that V-usb uses to service USB events.
This causes some sort of error on the USB and the next USBmessge being sent to the USBasp target through lib usb fails. After that, while USB communication seems to recover, avrdude and the USBasp f/w never seems to recover to continue the existing programming session. So while avrdude keeps sending write data blocks and then trys to read the flash to verify, it will always fail with a corrupt flash.
avrdude will only lower the block size when the sck frequency is above zero but below a threshold.
The issue is that avrdude sets the sck frequency to zero when auto sck is being used.
So if auto sck ends up selecting a low frequency, things break.
In order for auto sck to work at low freqencies, avrdude needs to fill in the final selected sck frequency so that the block size is properly adjusted by other parts of the avrdude code when the flash writes are done.
Prior to this 1.06 f/w, there was no way to get the sck frequency auto selected by the f/w.
Currently, there are now two ways to get it.
It is returned from the CONNECT command and there is a separate command to request it.
I patched my version of avrdude to update the internal sck frequency and it starting working again.
I'll have to do more testing to see what other issues may be lurking.
I see two issues in getting this fixed in avrdude:
So even if I could get past the #1 item, I'm not sure I could convince joerg to accept the patch to make it work.
As a point of reference:
I've been trying to get a libusb patch into avrdude for 6+ years and it is needed to make any of the atmel programmers like avr dragon, MKII, etc, be able to use the Arduino IDE to burn a bootloader.
Kind of funny that you can't use an Atmel ISP programmer with the Arduino IDE to burn a bootloader.
--- bill
An update.
After a couple of days of some intense debugging, I've done some updates that makes the auto sck selection better for low clock rates.
It now seems work ok with existing versions of avrdude.
These changes only affect auto clock selection.
Here are the changes:
There were some slight tweaks to the auto selection code to try the clock rate twice instead of once.
There were also a couple of places where multiple bits were being set in a PORT register that was shared with the USB signal pins. The AVR can't atomically set more than a single bit. The code was tweaked to make these operations atomic by masking interrupts during the multi bit operations.
The reason that I've dropped the clock from 8k to 4k and have a 4k fall back is that I consider these situations as an emergency fallback. These should only be used if something is going wrong and there is no way to use the -B option.
I've tested the code on an AVRs running at:
16Mhz - uses 1.5Mhz clock
12Mhz - uses 1.5Mhz clock
8Mhz - uses 1.5 Mhz clock (This is out of spec) [update: I can't do math, this is actually in spec!]
1Mhz - uses 93.750 Khz
128khz - uses 16Khz clock
32.768Khz - uses 4kHz clock (4khz is new in this version)
16Khz - uses 1Khz clock.
Note/update: please ignore this paregraph below as a 8Mhz CPU could use up to a 2Mhz sck clock. I obviously wast thinking when I originally wrote this since 8Mhz is less then 12Mhz so the sck clock can be up to 1/4 of CPU clock.
The one that is a bit concerning is clock selected at 8Mhz
The spec says the SCK clock should be:
- less than 1/4 FCPU when FCPU < 12Mhz
- less than 1/6 FCPU when FCPU >= 12Mhz
So for a 8Mhz clock sck should be no higher than 1.33Mhz so at 1.5Mhz it is about 13% over spec.
But given the AVR can run when FCPU is 4x sck clock when slower, the communication is AVR to AVR using AVR SPI h/w and there is probably some margin, it is likely to work in most situations.
I've pushed out a new alpha version of the code.
Any feedback & suggestions would be great.
Especially feedback for any poor results with auto clock selection at 8Mhz or slow clocks like at 32Khz
Here is a link to my repo:
Make sure to grab the 1.06-alpha branch.
It will contain a new set of pre-built images dated 2016-05-18
--- bill
I've got a patch for the usbasp file in avrdude for anyone that wants to build an updated avrdude to show the selected auto selected clock.
(I wish that avrdude used git as it would make it much easier to share patches)
PM me if interested.
--- bill
I have a small gift for Bill = bperrybap, for doing such good work:
An example of using i2c communication between two avr's,
with added test sound for buzzer on PB2 for atmega8.
Tested and works great !
a) the hex files are old - .c source needs recompiling
b) fuses are same as for USBasp, select F_CPU up in .c code
c) pull resistors 4.7k up required on sda and scl
d) search "makesnd" in the code to see where you can make modifications.
Thank you. Got the new firmware from May 18.
bperrybap:
After looking at the avusb500 design, I do not believe that it could ever be as fast as a USBasp device at programming.
The avrusb500v1 design used an avr clocked at 3.64689Mhz giving a maximum h/w spi data rate of 912Khz
The avrusb500v2 designed used an avr clocked at 14.7476 or 18.
"better" is always subjective. I have no idea about this other device so I would not even be able to offer any sort of comparison.
I have one of these old STK500 programmers with a 3.6864Mhz crystal and it does 1.8M on a mega8535. The SPI2X Flag can be used to implement SPI at 1/2 FOSC.
One advantage of such device is that it can be run on AVR Studio and Arduino, unlike the V2. That for me is gold: One tool, rather than many cheaper ones for each purpose, but it is not natively supported and I haven't been able to add it on newer versions of arduino (works fine on 1.06).
iugamarian:
I used original AvrUSB500V2 programmer. I also built one and have seen that it works.
But I tested only on two microcontrollers.Asking: with the new software is usbasp getting better than AvrUSB500V2.
Asking: can I rely on Usbasp to be very good and dump the A...V2 's ?
Pointing out - the sources for A...V2 programmer seem to be very well made, with auto clock and all -> maybe read them te get some ideas or routines
Does it really have Autoclock!? I set mine manually trough AVS4, never noticed any Autoclock feature!
iugamarian:
Pointing out - actually A...V2 programmer implements STK500v2 protocol with very detailed source code -> can't we just make the usbasp act like a stk500v2 (a stk500v2 is 20$ on ebay :D) if we have it done ?Asking (this is my favorite) - can we emulate ft232rl chip behavior in Usbasp, including legality of using the ft232rl usb identifiers on a firmware for Usbasp
You might find interesting a version of HoodLoader2 which emulates a AVR ISP MK2 right from the USB/Serial Atmega16u2 present in the newer arduino boards. Serial functionality is kept, too.
iugamarian:
Pointing out - it's very cheap to upgrade Usbasp to A...2 status if you need more speed
Speed is faster, but... An ATMEGA328 20KB sketch can be burned in about 1 second using AVR studio or a 3rd party hex burning software. Arduino takes more like 7 seconds (using the same programmer) after a lengthy compilation
Strangely the Linux versions compile almost instantly... If you are looking for speed this would be way to go.
casemod:
Speed is faster, but... An ATMEGA328 20KB sketch can be burned in about 1 second using AVR studio or a 3rd party hex burning software. Arduino takes more like 7 seconds (using the same programmer)
i noticed this some time ago and one of the reasons i prefer other setups besides arduino ide. most often a custom program using lpt port. however sometimes the ide cant be avoided. im not sure whether its the fault of usbasp firmware or avrdude but im hoping it will get characterized and fixed someday.
john1993:
i noticed this some time ago and one of the reasons i prefer other setups besides arduino ide. most often a custom program using lpt port. however sometimes the ide cant be avoided. im not sure whether its the fault of usbasp firmware or avrdude but im hoping it will get characterized and fixed someday.
One thing i would like to see is a similar method to that used on the MBED platform in which the hex is sent to a device that shows as a removable memory. The new versions of the arduino IDE already provide the option to export the binaries, so that's half way done
I own one of these Spartan FPGA boards:
This shows up as a removable drive and the bin file is sent to it. Notice the 32u4 MCU
oh yeah! lpc parts i work with have that capability. none of the complicated hardware and driver baloney. drag and drop is like heaven on earth.
Any updates?
I guess this is all dead then. RIP
I'm still around. Just haven't really done much on the project.
I guess I should go in and do a final cleanup and move it over to the usbasp github project that I set up.
--- bill
I'm still around. Just haven't really done much on the project.
I guess I should go in and do a final cleanup and move it over to the usbasp github project that I set up.
So what's new/different/changed in your firmware compared to Fischl's firmware?
I have a bunch of different AVRs I can test your USBasp firmware with 
hansibull:
So what's new/different/changed in your firmware compared to Fischl's firmware?
Several things fixed & cleaned up.
The biggest being:
--- bill
Great! Looking forward for a "clean" release of this. So, what's left? Anything I/we may help with?
BTW have you thought of supporting "different" USBasp hardware? Personally I prefer to use the USBISP hardware, because of its sleek hardware (picture down below). However, hardware-wise it's a tiny bit different compared to the "original" USBasp. A fork of the official USBasp firmware to add support for this hardware can be found here. Would love to use your FW with this hardware though!
There are some resources on the web describing how to make the Fischl fw work on this board. However I expect our firmware to work without modification (and we do have an atmega88 hex file). Can't try it out right now though.
The hardware difference seems to be that on this board USB D- is connected to both PB0 and PD3 (INT1). On the original usbasp, it is only connected to PB0. The original Fischl will not work as it drives (for no real reason) PD3 (It drives all PD pins except PD2). This makes usb communication impossible and actually causes pin contention.
Incidently, Bill (bperrybap) proactively fixed this: our fw only configures pins as output if they are really used as such.
Just for fun, I'll get such a board and try it out
And yes, we had a really fun project with this, but we didn't go the last mile (put a decent readme.md file in place and cleanup the different branches). We definitely should pick this up.