which version to use?
Opened this issue · 14 comments
Hello,
I used your 1.06 alpha on a usbasp clone some years ago, now i bought a new one like this: https://it.aliexpress.com/item/1pcs-FREE-SHIPPING-ST-Link-V2-stlink-mini-STM8STM32-STLINK-simulator-download-programming-With-Cover/32442061903.html
i see from https://github.com/bperrybap/usbasp/network that a few user gone forward with your code, do you suggest to still using the alpha 1.06?
I also noticed that there were some updates on the forks a while back.
I don't really know much about the other forks other than I've briefly looked at the commit messages
and a few of the commits in the rccam fork.
So I can't really speak on what is in the other forks.
What processor is on the device you have?
If it is a atmega48, then I definitely would not bother with anything other than the peter or my 1.06 as there is no room left in that part for anything else.
Honestly, I think it is a bit of a mess right now since Fischle is no longer maintaining the code and never set up a repository for it.
I haven't gone through the updates on the forks with any amount of detail, however, it can be tricky to add functionality as even in the code that Peter and I had, not all the functionality would fit in the smaller parts. And in some cases, even a tiny tweak to the code could make the compiler generate very different code that was several hundred or more bytes larger which would mean it would no longer fit in the smaller parts.
Also, the rccam fork has several patches for avrdude. I haven't looked to see what they do, but I'd be concerned that the USBasp device might have issues if it was used on a standard avrdude build.
Or that it requires the patched avrdude in order to work.
Also, the more recent avrdude patches in the rccam fork changed some of command line arguments for locating the USBasp device. I'm not sure the ramifications of those changes and I'd be concerned that it might break the drag and drop burning scripts that come with the package.
I'm not saying that the additions/updates on the forks is bad, it is probably really good stuff, just that I don't know much about it, and it is possible that the updates might cause issues in the smaller parts. i.e. the code might no longer be able to built for the smaller AVR parts like the atmega48 even if the PDI updates were disabled.
It is a big unknown to me.
what I'd like to see happen is for Peter and I to sync up, and get everything merged back into his master branch. Then we need to move/give his repository to the USBasp organization so it can be the master of all the forks. Then talk to rccam and start to move in pull requests for the new functionality into the USBasp organization repository.
But even after that, I'd be very leery of putting in new functionality that depended on avrdude patches as that adds yet another complexity to using the USBasp device and firmware that is outside the control of the USBasp firmware.
I'd also want to verify that the avrdude patches don't break the drag and drop burning utilities that come with the package.
thanks bperrybap for this good explanation, I hope that you and peter would make this repo the new standard and that the usbasp organization will adopt it.
meanwhile i will use your alpha 1.06, until know it worked without problems! I agree with you, I don't think that adding new functionalities would be a good point. In my opinion the cheap usbasp is made to be cheap and simple nothing more, if someone needs more he could always use a professional device as the ice or dragon ecc
on the other hand it is true that it would be nice to have advanced functionality (even if until now i just used it to upload code, nothing more) on the usbasp, maybe two branch one with the "new-standard", the 1.06, and another one with the "cutting-edge" function would work
The keeper of the official code was Fischle but we have been able to contact him so I'm assuming he is no longer supporting it.
There is no actual "USBasp organization" I created a github repository organization (which is different from a personal account) called "USBasp" that could potentially be used as a central location for this USBasp code.
Peter and I talked in the past about moving this code to a centralized type repository/place to make it easier to find. However, neither of us wanted to be strapped forever maintaining it.
Also, if the github organization repository really took off, it might at some point no longer qualify for the free account. Not sure about that one.
It does look like some of the updates that rccom has done like the PDI mode. I'm not familiar it, but I think it is used on the ATxmega parts.
i tested today the new usbasp in the first picture
well something strange:
[ 747.120100] usb 3-1: new low-speed USB device number 6 using xhci_hcd [ 747.265752] usb 3-1: New USB device found, idVendor=03eb, idProduct=c8b4 [ 747.265759] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 747.265763] usb 3-1: Product: USBHID [ 747.265766] usb 3-1: Manufacturer: zhifengsoft
a fast google search led me to a few results:
https://github.com/lb5tr/usbasp-zhifengsoft
http://wiki.efihacks.com/index.php?title=USBasp_Experiences
so it is a programmer almost compatible with usbasp but which should be flashed with a new firmware to use it as a usbasp. i think i will just put it in the can of unused stuff
to be honest i suggest to don't add compatibility for this hardware
- it s bad designed, i just say that it doesn't have the pull up resistor on the reset (maybe it is software enabled)
- the usbasp is at the same price and already well supported
anyway when you want you can close the issue!
While you can't use one of the pre-built f/w images you should be able to build the code in this repo to work with that board.
From looking at the commits in the other repository, it appears that they changed the AVR pins used for the USB data signals from B0 and B1 to D2 and D3 on that board.
(I think I remember seeing this on some other boards in the past)
All you have to do is modify 3 lines in usbconfig.h appropriately:
Change PORTNAMEfrom B to D
DMINUS_BIT from 0 to 3
DPLUS_BIT from 1 to 2
#define USB_CFG_IOPORTNAME B
/* This is the port where the USB bus is connected. When you configure it to
* "B", the registers PORTB, PINB and DDRB will be used.
*/
#define USB_CFG_DMINUS_BIT 0
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
* This may be any bit in the port.
*/
#define USB_CFG_DPLUS_BIT 1
/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.
and then run make to rebuild it for your board.
--- bill
Yes that is true, but anyway since the pid and vid are different i would be able to use it with - c usbasp. I am sure i could workaround this...
But really for 1€ it doesn t worth
Once the proper build tools are in place, it would only take a few minutes to make the changes, build it and update it.
Granted for those people using choosing to use windows, getting the tools in place is not so easy.
@bperrybap I uploaded the Alpha1.06 hex for Atmega 8 on the chip of my USBASP. The upload was successful. But now my board is not recognised by windows 10 system. When I use Zadig to load drivers
it gives this in the verbosity log.
libwdi:debug [wdi_create_list] Driverless USB device (1): USB\VID_0000&PID_0002\5&121DFBC1&0&4
libwdi:debug [wdi_create_list] Device description: 'Unknown USB Device (Device Descriptor Request Failed)'
What can be a possible reason for this?
Regards for your time.
Karanbir
libwdi:debug [wdi_create_list] Driverless USB device (1): USB\VID_0000&PID_0002\5&121DFBC1&0&4
I'm not sure what that is saying the product id and vendor ID are. (I don't use Windows)
When plugged in, the USBASP device should power up with the LED red.
Once the OS enumerates the device, the LED should turn green.
The Vendor ID should be 0x16c0 and the product ID should be 0x5dc
If you don't see those IDs there is something not working correctly.
--- bill
Actually the hex file did not download properly. Used the save as option on right click. what it saved was some HTML code. This became known after I opened the downloaded hex file in a text editor.
I then cloned the files through github desktop and voila I now have four souped up usbasps.
Thanks @ sleemanj and @bperrybap
Here is a pic.
The project includes a flashing utility to do the flash for you.
For windows it is called winflash
Did you use that?
No I used another utility called averdudess.
BTW how is the winflash utility used, from the windows or from the command prompt?
Winflash is a .bat file that can be run from the command prompt but it also supports drag and drop so you simply drag and drop the file you want to burn on top of the bat file.
It uses avrdude under the hood.
It is described in the included readme file: https://github.com/bperrybap/usbasp/tree/1.06-alpha/bin/firmware