Fixing USBasp based on ATmega8

I have an USBasp based on ATmega8 which I have never been able to do anything.

The specific model I have is this (that I also got deom DX):

Whenever I try to program (either a sketch or burn bootloader on a blank chip) with it I get this message:

avrdude: warning: cannot set sck period. please check for usbasp firmware update

I have properly selected the correct programmer in the IDE and the USBasp drivers are installed.

Is there anyway I can use my UNO do flash my USBasp with the newest firmware from USBasp - USB programmer for Atmel AVR controllers - fischl.de using my UNO R3 as the ISP ? Will that solve my problem?

Thanks.

AlxDroidDev:
Is there anyway I can use my UNO do flash my USBasp with the newest firmware from USBasp - USB programmer for Atmel AVR controllers - fischl.de using my UNO R3 as the ISP ? Will that solve my problem?

Yes, updating the firmware will solve your problem.
Connect the Arduino to the header pins on the USBasp as you would when using the Arduino as an ISP http://arduino.cc/en/Tutorial/ArduinoISP
13 -> SCK
12 -> MISO
11 -> MOSI
10 -> RST/Reset
You also have to short together one of the jumpers at the top of the USBasp to put it into self-programming mode.
Upload the latest firmware .hex file using AVRDUDE.

Cookies:

AlxDroidDev:
Is there anyway I can use my UNO do flash my USBasp with the newest firmware from USBasp - USB programmer for Atmel AVR controllers - fischl.de using my UNO R3 as the ISP ? Will that solve my problem?

Yes, updating the firmware will solve your problem.
Connect the Arduino to the header pins on the USBasp as you would when using the Arduino as an ISP http://arduino.cc/en/Tutorial/ArduinoISP
13 -> SCK
12 -> MISO
11 -> MOSI
10 -> RST/Reset
You also have to short together one of the jumpers at the top of the USBasp to put it into self-programming mode.
Upload the latest firmware .hex file using AVRDUDE.

Cookies, sorry for the dumb question, but I've never used avrdude directly. How do I do that, specially specifying that the UNO will be the ISP ? Thanks.

How do I do that, specially specifying that the UNO will be the ISP ? Thanks.

It is explained in the readme file

http://www.fischl.de/usbasp/Readme.txt

avrdude -c usbasp -p atmega8 -U flash:w:main.hex

If you are using Arduino as ISP it would be something like this

avrdude -c arduino -p atmega8 -P com3 -U flash:w:main.hex:i

Anyway, I have a USBasp myself and I get the same warning as you, but I just ignore it, it works OK.

Erni:
Anyway, I have a USBasp myself and I get the same warning as you, but I just ignore it, it works OK.

While that will work on an AVR that is setup to use a crystal,
it won't always work depending on the fuses. i.e. it won't work on new parts using the internal oscillator at 1Mhz.
With the old USBASP firmware you have to short out the slow SCK jumper on the USBASP programmer
since it doesn't support setting the SCK clock rate in the command interface.

With the standard older Fischl firmware that would be jumper J3.

--- bill

AlxDroidDev:
Whenever I try to program (either a sketch or burn bootloader on a blank chip) with it I get this message:

avrdude: warning: cannot set sck period. please check for usbasp firmware update

i have also purchased those from dx and there is no need to reprogram your chip. that is only a warning for a feature the firmware does not support. use the -B avrdude option to select clock speed instead. for new chips out of the tube with default 1mhz its rarely but sometimes necessary to slow programming down that way.

Thanks for the help, guys!

I finally got the Arduino ISP sketch working. Somehow during the afternoon it wasn't working, complaining about sync() and the like.

Now, at night, it decided to work (same jumper cables!).

I tried the flashing procedure again. The first downside I found was that my USBasp-clone is not exactly an Atmega8, but an Atmega8A-AU, and the device signature is different. So I did what I did to bootload my Atmega328-PU (note: non-P) with the Arduino bootloader: I edited avrdude.conf to let the Atmega8A signature be the one for the Atmega8.

A few verification runs with avrdude and all seemed ok. Let's flash!

Before proceeding, I dumped the original flash from my USBasp-clone to disk:

avrdude -c arduino -P \.\COM7 -p m8 -v -B 1 -U flash:r:originalusbasp.hex:i

The this command line I used to flash my USBasp from the arduino as ISP :

avrdude -c arduino -P \.\COM7 -p m8 -v -B 1 -U flash:w:usbasp.atmega8.2011-05-28.hex

(I had avrdude.conf, avrdude.exe and the hex file all in the same folder, one I created for this).

This is where things got a bit sour: it flashed, but gave me the following results (just the interesting bits):

avrdude: reading input file "usbasp.atmega8.2011-05-28.hex"
avrdude: input file usbasp.atmega8.2011-05-28.hex auto detected as Intel Hex
avrdude: writing flash (4700 bytes):

Writing | ################################################## | 100% 1.52s

avrdude: 4700 bytes of flash written
avrdude: verifying flash memory against usbasp.atmega8.2011-05-28.hex:
avrdude: load data flash data from input file usbasp.atmega8.2011-05-28.hex:
avrdude: input file usbasp.atmega8.2011-05-28.hex auto detected as Intel Hex
avrdude: input file usbasp.atmega8.2011-05-28.hex contains 4700 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.21s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x3b != 0xdb
avrdude: verification error; content mismatch

avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: Fuses OK

avrdude done. Thank you.

Two things there worry me:

a) all the fuses are 0. I had noticed this before, when using only -v with avrdude, but since the USBasp was working, I won't care much about it. I am afraid to set the supposedly proper fuses and "fubar" my USBasp-clone.

b) note the "verification error, first mismatch at byte 0x0000". WTF? The USBasp still works for verifying other Arduinos (I checked it with 2 different arduinos), but I have no idea how this will affect other aspects of its functionalities.

I redid the procedure 3 times (flashing the latest USBasp firmware), and everytime I got the same error.

Any help on these 2 matters?

Thanks.

It gets weirder! I decided to flash the fuses to the USBasp, since the fuses for the Atmega8 match those for the Atmega8A, and my USBasp has a 12Mhz Xtal on board.

Take a look at the command I issued and its output below:

avrdude -c arduino -P \.\COM7 -p m8 -B 200 -U hfuse:w:0xC9:m -U lfuse:w:0xEF:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "0xC9"
avrdude: writing hfuse (1 bytes):

Writing | | 0% 0.00s ***faile
d;
Writing | ################################################## | 100% 0.07s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xC9:
avrdude: load data hfuse data from input file 0xC9:
avrdude: input file 0xC9 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0xc9 != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: hfuse changed! Was c9, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: stk500_cmd(): programmer is out of sync

In other words, it wouldn't let me save the fuses. What gives?!

you must add the -u option otherwise avrdude will not change the fuses.

john1993:
you must add the -u option otherwise avrdude will not change the fuses.

Thanks for that, John.

Considering that my fuses are set to 0, do you thing it is a bad idea (or a good one) to try and set the fuses?

Thanks!

if your fuses are really set to zero the chip is dead and theres nothing you can do short of buying an expensive programmer with 12v capability. try just reading the fuses. that is always safe. if the signature reads ok that means your fuse is not really zero. if you didnt use the -u before then it is not likely fuses were changed to zero. one must be very careful when changing fuses because that is the #1 way noobs brick their avr.

john1993:
if your fuses are really set to zero the chip is dead and theres nothing you can do short of buying an expensive programmer with 12v capability. try just reading the fuses. that is always safe. if the signature reads ok that means your fuse is not really zero. if you didnt use the -u before then it is not likely fuses were changed to zero. one must be very careful when changing fuses because that is the #1 way noobs brick their avr.

I can read the device ID and my USBasp-clone works well (except for the annoying "sck period" message). Other than that it can communicate with other devices and other devices (arduino ISP) can communicate with it.

I am wondering if the wrong fuses are causing the "sck period" problem.

A lot of these USBasp programmers from China have the lock bits set so you can't re-program them or read them. You need to check your lock bits on the ATmega8 and see if they have been set. If the lock bits have been set the only way to re-program is to do an chip erase first.

alx is not trying to reprogram his usbasp so none of that is relevant. as i mentioned before the sck period message has nothing to do with the targets fuses and is an avrdude warning that is to be ignored. i would suggest reading this thread from the start, specially my comments, and posting the avrdude output this time while reading fuses. it should tell exactly what is wrong.

john1993:
alx is not trying to reprogram his usbasp so none of that is relevant.

Uh.... That's not what I see.
Most of this thread looks to be about trying to update/re-program a USBasp device.
Look at the original post and then again at his comments in response #6
and the hex image he is using.
What I see is that the thread started about a question about an sck error/warning message
when attempting to burn a blank AVR
and then asking about using an UNO to update the USBasp device to the latest firmware.
Then, in response #6, actually attempting to update the USBasp device firmware with a setup using ArdinoISP.
Even the title of the thread is "Fixing USBasp ..."

as i mentioned before the sck period message has nothing to do with the targets fuses and is an avrdude warning that is to be ignored.

I disagree with this.
If trying to program a new part with the factory default fuses,
which is using the internal 1Mhz oscillator (which is controlled by fuses), sck period must be slower
so the "warning" is indicating why things are not working.

Also note that the original question relates to burning a blank part is what was stated as being done in the original post:

Whenever I try to program (either a sketch or burn bootloader on a blank chip) with it I get this message:

The older versions of USBasp firmware used a jumper to slow SCK down, the newer versions support doing this from avrdude.
If the clock is not slowed down when using a slow clock in the target AVR, avrdude will abort
or get strange errors since it can't talk to/program the part.
While I agree that the SCK warning can be ignored in some situations,
(like when the target has fuses set up to use an external crystal like a typical Arduino board)
the warning message does indicate why things may not be working on a virgin/blank AVR chip.

With the old firmware if you get this error/warning message and things are not working, often everything will work
if you simply jumper the slow SCK jumper on the USBasp device.

This is what I do on my USBasp device as I've not gotten around to updating my USBasp firmware so it can
be slowed down from avrdude rather than having to use a jumper.

Once the AVR has been programmed to use a faster external crystal, (which requires changing fuses)
the USBasp slow SCK jumper can be removed.
Future re-programming of that AVR can now be done faster
and the SCK error/warning can be ignored since the AVR is now running with a faster
external crystal and the faster SCK will not create any issues since the AVR can keep up
with it.

--- bill

bperrybap:
Most of this thread looks to be about trying to update/re-program a USBasp device.

yes i see that many followup posts dealt with trying to reprogram the usbasp. but my reply was in response to his complaint again in his post preceding mine about 'the annoying "sck period" message' and suspicion that fuses cause it. this is not a result of trying to reprogram the usbasp with arduinoisp. neither fuses on the usbasp not the target affect that.

bperrybap:
If trying to program a new part with the factory default fuses,
which is using the internal 1Mhz oscillator (which is controlled by fuses), sck period must be slower
so the "warning" is indicating why things are not working.

i get that message regardless of target speed so dont see the utility. we should just realise that new chips need slow clock and -B is how you do that not j3.

bperrybap:
With the old firmware if you get this error/warning message and things are not working, often everything will work
if you simply jumper the slow SCK jumper on the USBasp device.

the usbasp i got from dealextreme does not have j3. i suppose they may have shipped different versions but all the ones from that vendor ive seen are the same. even going back 2 yrs.

so if he is trying to program the usbasp that message/jumper/command is not relevant and if trying to flash a slow raw target the -B is how you do it as i mentioned in post #6. either way the avrdude output while trying to do a read should tell whats wrong. of particular interest would be if sig is ok but fuse still reads as 0 which makes no sense. unlikely all bits are programmed and as we all know if rstdsbl is 0 there is nothing op can do except use another chip.

John,
Remember your avrdude thread from back in November?
http://arduino.cc/forum/index.php/topic,133005.0.html
I'm the guy that built an updated avrdude 5.11.1 windows binary from the SVN sources
for you to speed up your 1284 bootloader development - I'm very familiar with avrdude and usbasp.
For others, if you are going to be burning many bootloaders,
I highly recommend getting a later avrdude as it dramatically
speeds up the process since it will only burn the bootloader code space and not all the flash
from zero up to the bootloader.
3-4 seconds for fast SCK, 30 seconds for slow SCK compared to
30 seconds with fast SCK and about 7 minutes with slow SCK with the avrdude that ships with IDE.
(the windows binary I built and config file is attached as a zip image near the end of the thread linked above)


Just to refresh my understanding of things, and to look at the -B option and SCK clock modes
on USBasp a bit closer,
I went back and had a look at both the avrdude source code and the usbasp source code.

The recent avrdude (past few years and what ships with Arduino)
will always try to set the SCK speed on usbasp before connecting to the chip to talk to it.
It either sets it to an auto clock mode (0, which is fast) or sets
it to a value from the avrdude.conf file or a value from the -B command line option.
The -B overrides the setting.
If the usbasp device firmware does not support setting the isp SCK through
the USB USBasp command interface, avrdude will report a warning.
From the avrdude code in usbasp.c

  int nbytes =
    usbasp_transmit(pgm, 1, USBASP_FUNC_SETISPSCK, cmd, res, sizeof(res));

  if ((nbytes != 1) | (res[0] != 0)) {
    fprintf(stderr, "%s: warning: cannot set sck period. please check for usbasp firmware update.\n",
      progname);
    return -1;
  }

The avrdude code first does a SETISPSCK command and then does a CONNECT.

If you look at the official usbasp releases on the fischle site,
http://www.fischl.de/usbasp/
support for this SETISPSCK command started in the 2009-02-28 release.
Prior to that, the usbasp firmware either ran in hardware ISP or software
ISP depending on a hardware jumper.
According to the official schematic that jumper is hooked up to PC2 and is called JP3.
It grounds PC2 to set software SPI mode.

From the USBasp firmware in main.c
Pre 2009-02-28

    /* set SCK speed */
    if ((PINC & (1 << PC2)) == 0) {
      ispSetSCKOption(ISP_SCK_SLOW);
    } else {
      ispSetSCKOption(ISP_SCK_FAST);
    }

post 2009-02-28

	if (data[1] == USBASP_FUNC_CONNECT) {

		/* set SCK speed */
		if ((PINC & (1 << PC2)) == 0) {
			ispSetSCKOption(USBASP_ISP_SCK_8);
		} else {
			ispSetSCKOption(prog_sck);
		}

The pre 2009 code supported "slow" (s/w isp) or "fast" (h/w ISP)
and the new code supports a forced slow rate (which also uses s/w ISP)
or the value/rate sent from the -B option which defaults to to a fast h/w ISP
if not sent.
This rate/mode is controlled by the jumper - Installed == slow, removed == fast or -B mode
depending on the firmware.

This jumper setting check is in the top part of the code for the CONNECT
command. This means that even if on newer firmware that supports the
-B option which uses the SETISPSCK command, the jumper will override that
setting. (avrdude does the CONNECT after SETISPSCK)


Now that we know how avrdude and the firmware works, lets take a look
at how it interacts with a blank AVR chip.
Every single blank m328p AVR chip that I've programmed required using a slower SCK clock.
The default USBasp SCK clock rate is too fast for the default internal clock that the AVR
shipped with.

I've not programmed a large quantity, only around 10 or so, but this was true for all them.
The SCK clock had to be slowed down when using either an AVR dragon or the USBasp device I have.

Using the internal clock is controlled by fuses inside the AVR so yes the target fuses
can affect whether or not the USBasp device can program the AVR - or at least
make it not work with all the USBasp defaults.
Note: according to the datasheet the m328p clkdiv8 fuse is programmed when shipped
which gives a 1mhz clock by default for blank chips, so I assume that the SCK clock
will need to be slowed down for all blank m328p chips and not that mine were
somehow "unluckily" slow.

Since the firmware on my USBasp appears to be old and out of date, it requires using slow SCK jumper to slow
down the clock. (the -B option does not work as there appears to be no support for SETISPSCK in my device firmware)
The USBasp device I have also has it's jumper headers labeled differently from the official schematic.
On my USBasp device, I short out the header pins labeled j2 rather than j3.


From my experience, here is my take away from all this
when using USBasp devices.
If you have old USBasp firmware you will ALWAYS get the SCK warning.
In order to burn a bootloader into a blank chip, the SCK will need to be slowed down.
If you have old USBasp firmware, you must use the slow SCK jumper to slow the clock down.
Not all USBasp devices label their slow SCK jumper the same or use the same label as in the official schematic.
If you have newer firmware you can use the -B option, but.....
from what I've seen so far, the Arduino IDE does not use the -B option when it burns a bootloader, so if
using the IDE, it looks like you will still need to use the jumper.
As an alternative you can use the avrdude commandline interface where you can spedify the -B option.

If the AVR is running faster than the 1Mhz default, then no jumper or -B option should be needed
but the avrdude SCK warning will still show up.

--- bill

Now I need to go update my USBasp device to the latest firmware so I can eliminate
the ugly warning message.

So I updated my USBasp firmware using an AVR dragon.
As expected, no more SCK warning messages from avrdude.
details below.

alx,
to update your USBasp, you will have to set your jumpers properly.
The most important one is the programming jumper which connects
the reset line on the ISP header to the reset on the processor.
Typically there are 3 jumpers

  • VCC pass through (connects VCC to ISP header)
  • Programming (connects ISP header reset pin to AVR reset)
  • Slow SCK (grounds PC2)

It may take some sleuth work with a magnifying glass to figure what the jumpers do to
ensure you have the correct jumpers set since these devices typically
don't come with much if any documentation and the PCBs don't use
the same jumper numbers as Fischl's schematic.
The only way to figure it out is to follow the traces on the PCB
and then look at the pinout for the AVR used on your device.
Its not that bad, since all you really have to do is see which header/holes
connect to VCC, RESET, and PC2.

You will also have to decide how to power the USBasp device.
Either from the USB or from the UNO through the VCC pin on the
ISP header. If you use the ISP header you will need to make sure you
pass power through which is another jumper.

I've not seen in your previous posts how you set the USBasp jumpers.
Did you connect up the programming jumper?
Once you get the programming jumper set, get the device powered
and get it wired up, it should program ok.

--- bill


Details...

It wasn't as straightforward as I had hoped but still wasn't that difficult.
(most of the issues were linux udev permission related since I've rebuilt my machine recently)

The USBasp device I had used a atmega48 which only has 4k of flash so the latest
firmware release from 2011-05-28 could not be used. However the previous release
from 2011-02-28 has support for setting SCK clock rate so I went with that.

In order to enter programming mode, the reset line has to be connected
to the ISP header/connector. On the official schematic that is J2 on my device
it was labeled J3. (I figured this out a while back using a strong microscope and following
the traces on the PCB)
What made it tricky was that my device has no case but uses clear shrink tubing
as a cover. It didn't have a header in place for the programming jumper.
I didn't want to cut off the protecting layer just to short out the programming jumper.
The trick was to use a bread board jumper.
I was able to pierce the shrink wrap with the pins and short out the needed trace.
The clear plastic held the jumper in place and when removed
the plastic is left with two tiny small holes from the jumper pins.
(See attached photo).
After that, it was a snap to program the software.
As an added bonus, I went in and modified the firmware to show activity on the green LED.
By default the Green LED just turns on Green and stays green while the device is plugged in.
The RED led turns on when avrdude tells the device to attach to the AVR chip.
I modified the code to turn off the green led while the firmware is actually talking to the
AVR chip and solid green while idle. The result is that the green now LED flickers while
the USBasp device is actually talking to the AVR.
But with the new avrude you have to look quick because the actual burn of a bootloader
when in fast SCK mode is about 2 seconds.
It is a nice flicker during the 30 second update when using the older avrdude.

yes i recalled the favor you did. your forum name is forever burned into my mental hall of fame. thanks for saving me literally hundreds of hours developing custom bootloaders.

your usbasp experience is interesting and quite different from mine. first i will say having purchased hundreds, no exaggeration, of chinese usbasp clones (betemcu, lcsoft, etc) for clients i never saw one with a j3. 3v-5v and self program jumpers, yes. clk jumper no. and always got the warning msg regardless of fuses or target. something else a mystery is 9 out of 10 worked fine for 1mhz chips. thousands of raw mega8 and few dozen other types like tiny, 168, 328, 1284, etc w/o any need for -B or updates. but some rare lots, even from same vendor, needed to be told to slow clock. i tried updating those with official firmware which sometimes worked and other times didnt. but always bailed out by -B. so looks like its a crap shoot what you will get from china. and many variation on firmware. ive considered throwing together a diy usbasp deadbug because it would only cost $1 or so but for a couple bucks more places like aliexpress, ebay, dx always prevailed.

thanks for putting together this very interesting and informative "wiki" on usbasp history. and thanks again for helping with that avrdude hack.

btw are you considering posting hex for that usbasp code? id be very curious to give it a try. if its anything like your avrdude mod it would be a boon to hobbyists around the world. specially those many noobs who get confused by the warning.

john1993:
your usbasp experience is interesting and quite different from mine. first i will say having purchased hundreds, no exaggeration, of chinese usbasp clones (betemcu, lcsoft, etc) for clients i never saw one with a j3. 3v-5v and self program jumpers, yes. clk jumper no. and always got the warning msg regardless of fuses or target.

wow. Very interesting. hundreds?
Are you involved with a school/students or something?
I can't imaging being involved with purchasing so many units.

I have no idea why people that make USBasp devices deviate from the Fischl's names/designators on their boards.
Maybe some of them actually go in and change the hardware and the code?
But I suspect that most of them don't and use the stock Fischl code
but for some odd reason change the designators on the PCB.

Nearly all the ones I've seen on Ebay do have the jumpers or at least the pads for the
3 options. VCC passthrough, slow SCK, programming.
(At least in the photos, but then sometimes you don't get what is shown in the photo)
Example, the photo of mine showed a jumper for the VCC passthrough. The actual
board I got had a zero ohm resistor soldered in. It can be altered/fixed with a bit of soldering.

But I'll agree it can be a bit rough for less technical folks.

something else a mystery is 9 out of 10 worked fine for 1mhz chips. thousands of raw mega8 and few dozen other types like tiny, 168, 328, 1284, etc w/o any need for -B or updates. but some rare lots, even from same vendor, needed to be told to slow clock. i tried updating those with official firmware which sometimes worked and other times didnt. but always bailed out by -B. so looks like its a crap shoot what you will get from china. and many variation on firmware. ive considered throwing together a diy usbasp deadbug because it would only cost $1 or so but for a couple bucks more places like aliexpress, ebay, dx always prevailed.

Interesting. Maybe the parts didn't have the CLKDIV8 fuse set.
With the normal/stock Fischl firmware, if you don't have support for the setting the SCK rate
you will get the SCK warning from avrdude. But that also means -B won't work as well.
Maybe some of the USBasp devices are hardwired for slow mode?

My feeling with cheap import h/w is that I can't build the hardware for what I can buy it for on Ebay.
But if needed, I can fix the software to work on whatever design they used.
So I just buy the cheap stuff, and fix it to work if I have too.
For the USBasp device I had, the hardest part was looking at the traces to verify where
all the connections went since there wasn't a schematic.

Oddly enough, there is an even an error in Fischl's code vs schematic.
On the official schematic, the green LED is hooked up to PC1 and Red to PC0
but yet the code believes that Green is on PC0 and Red is on PC1.
My board matched Fischl's code rather than the official schematic.

btw are you considering posting hex for that usbasp code? id be very curious to give it a try. if its anything like your avrdude mod it would be a boon to hobbyists around the world. specially those many noobs who get confused by the warning.

I can build and post whatever .hex people want.
Although it is pretty easy for people to build it for themselves
or just burn the stock .hex images that come with each release.
The only difference between my code and the stock .hex is that
I tweaked the way the LEDs work. The rest of the code is unchanged.

The biggest issue with posting .hex images is that
it is a bit complicated as there are many different combinations so one .hex won't
work for everyone.
It depends on which AVR is used in the USBasp device.
It can be mega8, mega48, or mega88.
And then the mega48 can't run the latest 2011-05-28 firmware.
Complicating things further is the actual hardware design.
Not all boards are using a 12Mhz clock.
Also, if the hardware doesn't use the same ports/pins as the official Fischl design
then Fischl's firmware won't work without tweaks to make it match the hardware.

The stock LED behavior is ok so I think most users would probably be just fine
if they simply updated their boards with the proper stock .hex image supplied by Fischl.

The trick is that if the USBasp being updated doesn't match the Fischl schematic
then their board will be useless until is uploaded with the proper USBasp image for
that board.
The only way to know if the USBasp device is compatible with Fischl's stock firmware images
is to get out the magnifying glass (I used a USB microscope) and look at the connections on the PCB for
the ISP connector and see where the all go. Tedious but not difficult.

Then if it doesn't match, it is pretty easy to go tweak the code to match
the hardware and simply build the image you need.

--- bill