Ah, I see, thanks. What does that "cannot set SCK period" error even measn then?
there is no sck "error". it is a warning only and should be ignored. there are literally thousands of complaints about this on the internet and in many cases programmers are returned to seller for no reason. lots of them are bricked trying to fix a problem that does not exist. they should change that warning but unfortunately most sellers dont even know what usbasp is or whats its for.
To say that it isn't a problem and should be ignored is an overstatement.
It may or may not be an issue for programming, depending on the environment.
and fungus, this warning message is not issued when using all USBasp devices.
The warning is due to using outdated USBasp firmware with a newer version of avrdude.
If virgin AVR chips are to be programmed a slow sck clock period MUST be used.
This means that setting the sck period may be very important and depending on the firmware
in the USBasp device it may or may not be possible, and might require setting a jumper.
Here is what the warning really means.
Unfortunately the way the AVR is designed, it uses the MCU clock that is controlled
by fuses when ISP programming.
So depending on how the fuses are configured, that clock can be literally anything.
It could be using the internal oscillator at 8mhz, or 1Mhz, or using an external clock
from a crystal or oscillator.
When programming using ISP, the data can only be clocked in at a particular rate
using sck. The maxim sck clock rate is based on the MCU clock rate and there is no way to know what
the MCU clock is from the ISP pins.
This means that if the MCU clock is say 1Mhz you can't clock in (and hence) burn an
image as fast as when the MCU clock using an extern crystal at 16Mhz.
And if you attempt to burn an image when the MCU clock is 1Mhz using a fast sck,
it will fail.
Keep in mind that a fresh/virgin AVR is shipped with the fuses set to 1Mhz internal
clock so the initial burn of fuses and program must be done using a slow sck clock period.
Different ISP programmers handle this differently.
Some simply always use a slow clock on the ISP interface. While this always works,
it is will be noticeably slower on larger images that it could have been when the MCU
is clocked at 16Mhz.
The USBasp firmware originally handled this by having a jumper.
If you look at the schematic you will see JP1 labeled as "slow SCK".
The firmware defaulted to using a fast SCK but could be told to slow down
by installing the "slow SCK" jumper.
From what I've seen most of the USBasp devices out there, have firmware that
supports this jumper and have the jumper on the boards.
Unfortunately, many of the USBasp boards have the solder pads for the jumper but
don't have the 2 pin header soldered to the pads to actually use it.
But it can usually be added by simply soldering a 2 pin header to the pads.
The newer versions of USBasp firmware still retain this jumper setting/option but
also have added new USB commands to allow setting the sck clock period from the HOST/PC.
In the newer firmware, the jumper still overrides the clock. So if the jumper is installed
you will get the slower clock regardless of whether the command was sent to set the sck period.
Avrdude has been updated to use these new USB commands to set the sck clock period.
When a USBasp device is using the older firmware, these new USBasp commands will fail
and that is what the avrdude warning is telling you.
It is saying:
"Hey, I tried to set the sck clock period, and your USBasp device doesn't support it,
because of this, the programming may or may not work".
avrdude issues the mentioned warning whenever there is an attempt to set
the USBasp sck clock and the command fails.
Unfortunately, the newer avrdude code will always attempt to set the sck clock for USBasp devices
even if you don't explicitly use the -B option to ask avrdude to set the rate.
So the warning will always be seen when using a newer avrdude with older/outdated USBasp firmware
even if not trying to set the sck clock using -B
The irony is that the USBasp command that is being sent to the USBasp device to set the sck clock
when the user is not using -B really doesn't do anything and isn't needed.
It attempts to set the sck period to its default clock, which the USBasp device is already using.
A better approach would have been to not send the USBasp command set the sck clock rate
unless the user explicitly asks to set it. Then there would be no warning unless -B was being used,
in which case the warning would be appropriate.
If you want this behavior changed, you should file a bugtracker report for it on savannah:
Now the tricky part of all this, is that when buying these USBasp devices off Ebay you never
really know what firmware you have. Compounding this, is some vendors modify the firmware.
They can make simple modifications like changing the AVR pins used for jumpers to more substantial
changes like changing the behavior of the sck clock or its jumper.
The one I purchased had old firmware it in. I updated the firmware to the newer firmware.
It is isn't difficult to do, but you do need another ISP programmer to do it.
In my case, I also modified the firmware to change the way the LEDs worked.
While ISP programming, I use a red LED to indicate writing and a green LED to indicate reading.
It is nice to see the burn (flickering red LED) and the verify (flickering green LED) happening.
So back to whether this is an issue or not...
The answer is "It depends".
If you have a USBasp device with non original/modified firmware that always burns the images slow,
then ISP updates will always work. And you can burn virgin AVRs as well as AVRs that are
using the standard Arduino 16Mhz cystal.
If you have a USBasp device with older firmware that doesn't support setting sck over USB,
you won't be able to burn virgin AVRs using -B to set sck to a slow rate and will have to use the JP1 jumper to slow
down sck. If you board doesn't have a slow sck jumper, you will have to add it. If you board doesn't have
the pads for it, you will not be able to burn virgin AVRs.
But, you will be able to burn the AVRs once they have their fuses set for a faster MCU clock and/or are using
the Arduino standard 16Mhz crystal.
If you have a device with modified firmware, "it depends" on what they have done.
Having the later firmware is really nice since it allows you to use the -B option to set sck
so you can run fast or slow without having to resort to using a hardware jumper. And
you can set the sck speed to allow the fastest possible burn for the MCU clock you have.
Unfortunately, there is no way of knowing what firmware is in your USBasp device
unless you build and burn your own firmware.
This can be difficult on Windows machines since Windows was/is not designed for s/w development
and so it doesn't come with the necessary tools.
It can be done on Windows but it requires setting up the unix tools.
Actually all the needed unix tools come with the Windows Arduino IDE,
but the environment will need a bit of tweaking to actually use them.