Re: [avrdude-dev] avrdude and usbasp

[Artur J]

Oops, I think I didn't include the list in one of my replies. Adding that 
address back in.


New patch worked very nice. kkmulticopter flash tool recognized that programmer 
type of usbasp clone is available. Programming worked without a glitch. I also 
ran avrdude directly with -v -v option and got following:

Using Port                    : usb
Using Programmer              : usbasp-clone
Setting bit clk period        : 8.0
avrdude: seen device from vendor ->XWOPEN.<-
AVR Part                      : ATmega168P


So this programmer does not report product name, only vendor name. Another 
clone that I have reports both:

Using Port                    : usb
Using Programmer              : usbasp-clone
Setting bit clk period        : 8.0
avrdude: seen device from vendor ->www.fischl.de<-
avrdude: seen product ->USBasp<-
AVR Part                      : ATmega168P


Another thing to note is this:

avrdude: try to set SCK period to 8e-06 s (= 125000 Hz)
avrdude: set SCK frequency to 93750 Hz
avrdude: warning: cannot set sck period. please check for usbasp firmware 
update.


Something not working quite right here. Both my clones had this.

Thanks for your help Rene

Artur


________________________________
 From: René Liebscher <address@hidden>
To: Mark <address@hidden> 
Sent: Saturday, January 14, 2012 2:43 PM
Subject: Re: [avrdude-dev] avrdude and usbasp
 
Am 14.01.2012 19:42, schrieb Mark:
>   > If you can not read it, this should be not ignored if there is a
> value to be checked specified in the config file.
>   > I will change it to either not reading it at all if there is a
> value specified or to ignore the error only in this case.
>
> Do you mean not reading at all or ignoring  if there is *not* a value
> specified?
>
> True, *if* there is a value specified in config file. In my test
> config file reads
>
> programmer
> id = "usbasp-clone";
> desc = "Any usbasp clone with correct VID/PID ";
> type = usbasp;
> usbvid = 0x16C0; # VOTI
> usbpid = 0x05DC; # Obdev's free shared PID
> #usbvendor = "";
> #usbproduct = "";
>
> That's per your patch. So the value is not specified in the config
> file, correct? I think in this case it would be best to display what
> can be read from the device or ignore if nothing could be read and
> either way keep going like nothing happened. This way user could add
> information obtained from the device to their config file but if they
> didn't, the process would still complete. In my test the process
> failed because the information that is not present (commented out) in
> the config file could not be read from the device and this instead of
> being ignored caused failure. Lack of usbvendor or usbproduct in
> config should be an indication that we want to keep going while
> possibly trying to display what can be read from device.
>
I have changed it, so it tries to read the information but ignores any
error if we do not need the information (not set in conf or empty
string). If it can be read it is shown when at least -vv is given.
(Before applying the patch, do an 'svn revert'.)
>>
>> Also, why are we making original USBasp, it's old version and NIBObee
>> special cases hardcoded into usbasp_open function? Shouldn't the code
>> be made generic and these 3 also moved to config file?
>>
>   > If we remove it now many people will complain (especially users of
> old usbasp, if there are any, and users of nibobee) as they can no
> longer program their devices. May be we should add additional entries
> for them in the config file now and remove these special cases some
> versions later. So there is enough time people can change their settings.
>
> You're making a good point. However, if we move hardcoded values to
> config, things should still work for everyone if they install new
> binary *with* the new config file. Things will only break if they keep
> old config file and drop in new binary. They shouldn't do that anyway.
> If they have custom settings in their config file, they should move
> them to new config file. The change could be documented so that they
> can figure out what they need to do to get things working again.
> Adding entries and removing code later also makes sense. One may argue
> that there will probably be people upgrading from some old version
> before changes to version after code removal and things will break for
> them anyway. Either way, it may also be a good idea to add a warning
> message if entries are not present in config file for original
> devices. Not that I'd personally care, for example, since I don't have
> original USBasp.
Only the new config entries and a new binary is not sufficient, you also
have to use the new programmer id in your Makefiles, and as NIBObee is
used at education sector I do not want stop students at downloading
their programs. Some releases later google will know the solution for
the potential download problem in 1st place (and nicai-systems.com will
have updated its website.)

But I also have added the correct usb params for usbasp in config file
and a warning message for nibobee ;-)

> Regards,
>
> Artur

Regards,

René