Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sponsor AVRDUDE #997

Closed
kristofmulier opened this issue Jun 18, 2022 · 14 comments
Closed

Sponsor AVRDUDE #997

kristofmulier opened this issue Jun 18, 2022 · 14 comments
Labels
non-technical Proposed change of non-technical nature (editorial stuff etc.)

Comments

@kristofmulier
Copy link
Contributor

kristofmulier commented Jun 18, 2022

The work done for AVRDUDE is of utmost importance for millions of developers. Therefore, I think you should consider adding the GitHub sponsor option. I think it's a pretty new feature, it looks like this:

image

I'll be happy to make the first donation :-)

@dl8dtl
Copy link
Contributor

dl8dtl commented Jun 18, 2022

Well, the question then is: what to do with the money?
Personally: it won't be able to buy me more time for the project.

@kristofmulier
Copy link
Contributor Author

@dl8dtl ,
I know that donations for opensource projects typically don't make a lot of difference. Most people (and companies) just use opensource without giving any reward to the makers. However, it could be a way for those that care, to show their care.

@dl8dtl
Copy link
Contributor

dl8dtl commented Jun 18, 2022

I do understand that part, but the question remains, what to do with the money …

@MCUdude
Copy link
Collaborator

MCUdude commented Jun 18, 2022

what to do with the money …

I'd argue that spending donated money to buy hardware to resolve reported issues is the way to go. For instance, there are lots of unresolved Xmega-related issues that can't really be fixed until we have the hardware to test with. In #435 @mcuee has done a great job and linked related issues.

@dl8dtl
Copy link
Contributor

dl8dtl commented Jun 18, 2022

If anyone wants to tackle those issues, I guess it's easy enough to convince Microchip to donate a devboard.

IMHO, the project lacks man power rather than money.

@mcuee
Copy link
Collaborator

mcuee commented Jun 18, 2022

If anyone wants to tackle those issues, I guess it's easy enough to convince Microchip to donate a devboard.

I will agree with that. Last time (around 2011) when Travis and I were working on libusb-win32 and libusbk projects, For Microchip I had good connection at the time and I got them to donate MPLAB ICD3 and some other tools to Travis. I got PICkit 2 and mnay PIC chip samples from Microchip for my help on Microchip's pk2cmd tool.

And for Atmel it was just some mailing list contact (Atmel was using libusb-win32). And both companies were very helpful. For example, Atmel provides AVR Dragon, AT90USBKey and UC3-A3 Xplained (the projects are USB centric).

Now Atmel is under Microchip and I think Microchip is pretty good in terms of supporting open source community.

IMHO, the project lacks man power rather than money.

I will tend to agree as well. That is what we are facing in libusb, libusb-win32 and libusbk as well (I am the non-developer admin of these projects). For example, libusb has quite many issues and pull requests pending the involvement of developers/reviewers, especially on Windows side.

We did collect two rounds of donation for libusb-win32/libusbk project previously in 2011 and 2014. That was to get the digital signature necessary for the kernel driver signing. Without the digital signature for libusb0.sys and libusbk.sys, you will not be able to use Zadig to install the driver necessary for libusb/avrdude/openocd/etc.

I think it is still okay to have some donation to help some developers to get the necessary tools.

@mcuee
Copy link
Collaborator

mcuee commented Jun 18, 2022

what to do with the money …

I'd argue that spending donated money to buy hardware to resolve reported issues is the way to go. For instance, there are lots of unresolved Xmega-related issues that can't really be fixed until we have the hardware to test with. In #435 @mcuee has done a great job and linked related issues.

I think it is still okay to have some donation to help some developers to get the necessary tools. Some tools are not provided by Microchip (eg: FTDI2232H/FTDI232H based tool) and some people may not want to get the help from Microchip.

My original intention was to use avrdude as a tool to help testing libusb/libftdi/hidapi (just like OpenOCD). But then I got more interested in avrdude as it seems the codes are easier to try to understand than libusb and OpenOCD. So I will at least try to understand the root cause of the issue and try to understand the patches (not to come out with patches).

I do not want to bother with Microchip this time so I am buying cheaper tools myself -- the more expensive will be two STK500 (programmer portion only) clones and one AVRISP MKII clone on order. I also bought the ATmega4809 Curiosity Nano board, ATmega328PB xPlained Mini board and the original Arduino Nano Every from Mouser. I am reluctant to buy the ATxmega related xPlained board (eg: A1U, A3BU and E5) as of now since they cost about US$55 each. So I choose to order a cheaper ATxmega32D4 breakout board. The other tools like Arduino clones and USBASP/USBispTiny are not that expensive to get.

@mcuee
Copy link
Collaborator

mcuee commented Jun 18, 2022

@dl8dtl
Other than testing (not a developer so usually I can not come out with patches, but I can mess with Linux/macOS/Windows, and also FreeBSD when needed, and I have access to quite some tools), I can help to organize the github issues a bit better (to label them and link them, including closed issues) if you give me the access. I am doing this type of work for libusb, hidapi, pyusb and libusbdotnet.

For example, I think the issues number were not that manageable one month ago -- now it is much more managable at 114.

@dl8dtl
Copy link
Contributor

dl8dtl commented Jun 19, 2022

I can help to organize the github issues a bit better (to label them and link them, including closed issues) if you give me the access.

Offer happily accepted, thanks!

@dl8dtl
Copy link
Contributor

dl8dtl commented Jun 19, 2022

That was to get the digital signature necessary for the kernel driver signing.

That's certainly a good point, although I don't think needed for AVRDUDE right now.

@mcuee
Copy link
Collaborator

mcuee commented Jun 19, 2022

That was to get the digital signature necessary for the kernel driver signing.

That's certainly a good point, although I don't think needed for AVRDUDE right now.

Indeed. The direction for non-Microchip tools should be to go with WinUSB Driver, using WinUSB Compat ID so that Windows can automatically install the WinUSB driver. Microchip tools are mostly using WinUSB now.

Ref: @mariusgreuel has written it well here. And he has provided alternative FW for USBasp, FabISP/USBtinyISP and micronucleus.

https://github.com/avrdudes/avrdude/wiki/The-story-on-libusb-for-Windows#recommendation-to-usb-device-vendors

If you require a generic USB driver (i.e. not a class driver, such as HID or CDC), choose WinUSB on Windows. If you choose to use the WinUSB driver, consider adding a Microsoft OS descriptor to your device firmware, so that the WinUSB driver is loaded automatically. You should not require your users to use tools such as Zadig.

BTW, for USBtinyISP, Adafruit has a signed driver package for libusb0.sys and that should still work. They mentioned that their code signing certificate has expired and not planned to renew.
Ref: https://github.com/adafruit/Adafruit_Windows_Drivers/releases

Alternative FW with WinUSB Compat ID.

@mcuee
Copy link
Collaborator

mcuee commented Jun 20, 2022

I can help to organize the github issues a bit better (to label them and link them, including closed issues) if you give me the access.

Offer happily accepted, thanks!

Thanks. I start to label the current issues and those have just been closed.

@mcuee
Copy link
Collaborator

mcuee commented Jun 20, 2022

Maybe we can move this to Discussion.

@MCUdude
Copy link
Collaborator

MCUdude commented Jun 20, 2022

@mcuee please do!

@mcuee mcuee converted this issue into discussion #1003 Jun 20, 2022
@mcuee mcuee added the non-technical Proposed change of non-technical nature (editorial stuff etc.) label Jun 20, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
non-technical Proposed change of non-technical nature (editorial stuff etc.)
Projects
None yet
Development

No branches or pull requests

4 participants