avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving avrdude to Git ?


From: Joerg Wunsch
Subject: Re: Moving avrdude to Git ?
Date: Thu, 2 Dec 2021 23:42:38 +0100

Trying a mass-reply to all the answers that arrived.

As greuelm@mgtek.com wrote:

> It is certainly too much work for a single person, and I really do
> appreciate that you are donating your spare time to keep avrdude alive!

Thanks!

> Speaking of testing, I was wondering what kind of tests you do. As there is
> nothing in the repo I assume its all manual? Looking at the sheer amount of
> programmer and devices, it cries out for automation to create some relief
> here. Do you have any thoughts on this?

Yes, it's manual.

There are three issues I'm seeing with automating this:

1) Setting up a kind of CI environment takes quite a bit of time.

2) Setting up a kind of CI environment takes quite a bit of hardware.

3) Setting up a kind of CI environment requires (rack) space.

About 1), I can only spend my time either in infrastructure work
(moving to a different development platform), CI setup (have seen it
at my previous employer how much it takes), or improving AVRDUDE
itself. So far, whenever I find the time and energy at all, I decided
for the latter.

As of 2), I do own a number of hardware setups and programming
dongles, many of them donated (a lot by Atmel/Microchip), but not
enough to cover a decent combination of tests. So for example, lately
I used a simple ATmega16 board to test changes on the USBasp,
USBtinyISP, ft245r, and linuxspi programmers. For other tests, I used
some of these programmers to test against a small ATtiny10 development
board. If this ought to be automated, all the respective setups need
to be available in a semi-static setup.

About 3), whenever I test something, I throw it together on my (home
lab) desk. This is not really very stable (mechanically), sometimes
even uses battery power (I've got plenty of old laptop 18650 cells),
but nothing that could be installed permanently.


> One thing I did while adding WinUSB support to libusb was packet tracing,
> and doing a simple actual vs. expected compare. I am wondering if one could
> create some I/O level (serial, usb, hid) test adapters and record from a
> known good system, do a replay/compare for automated testing and then stick
> the whole thing into a CI pipeline. I haven't thought this through,
> though...

That can certainly be done, but it's also easily possible that changes
to AVRDUDE could cause different I/O level traces but are still
legitimate, as they cause the same net result (e.g. by using a
different packet size).


As greuelm@mgtek.com wrote:

> Thank you for kind reply. I'd be happy to help out with the Windows builds.

That's great to hear!

> Currently, my Windows builds use MSVC, which is obviously the first choice
> on Windows, but it required a lot of hacks to get it working.

Wes (the Microsoft guy I mentioned) once started MSVC porting, see
patch #8790. However, he never responded to my analysis/comments made
in that patch tracker. Some of his changes seem to be completely
unreasonable to me (like #ifdefing out linuxgpio, or dropping
setvbuf), others just need a bit of work (like autoconf replacement).

Feel free to use his changes as a base. But I'd like you to take over
responsibility for the Windows stuff then, as I cannot even test that.

> The cross compiler builds with MinGW under
> Ubuntu/WSL are the simplest, however, I try to avoid MinGW due to the lack
> of PDB symbols, which is really a no-go for me on Windows.

MinGW turned out to be "good enough" for me, that's why I even did it
that way. Nobody else volunteered to run Windows release builds,
despite of many users asking for it.

But if there's a MSVC path, I wouldn't mind, as long as it doesn't break
the GCC path for unixoid systems.

> Some of the patches I made for Visual Studio look identical to what Wes Witt
> made. I wonder how he fixed the pthread (and other Posix) dependencies.
> Could you give me access to his patches?

I added you to the team, so I think you ought to be able to access them now.


As Xiaofan Chen wrote:

> For smaller projects it is not a big problem. I migrated libusb-win32
> and libusbk from Sourceforge to github. But then I have to manually
> migrate the issues in github. Luckily we have not many issues
> in Sourceforge. We keep the mailing list in Sourceforge.

As Github doesn't offer mailing lists, I also tend to just keep this
list here alive.

Many commits refer to certain patches or bug reports. That's why I'm
interested in migrating even closed issue tracker items to a new
platform when we want to move over to something new. We have somewhat
above 500 bug tracker items, I don't think anyone would want to
convert them manually. ;)

> I am not so sure libusb is a good comparison or not to avrdude, but I
> think it is an important project but we are really short of maintainers
> and reviewers.

I think it's mostly in the same boat as AVRDUDE: many people use it,
but it's too small to attract enough active developers, so to get into
a "self-living" state.

> Moving to github may help a bit but will not fundamentally change
> the issues projects like libusb and avrdude are facing.

I can fully understand you (and appreciate your continued work on
libusb as well!).


As Xiaofan Chen wrote:

> CMSIS-DAP has two version, one for HID and the other
> with WinUSB.
> 
> For HID devices, we recommend HIDAP and not libusb.
> https://github.com/libusb/libusb/wiki/FAQ#Does_libusb_support_USB_HID_devices

AVRDUDE also uses hidapi if available.

> As mentioned in the other reply, it is good to move away
> from libusb-0.1 API to libusb-1.0 API.

Well, it's going to be quite a bit of work. Someone :) has to do the
conversion.

Some of the individual drivers already use it if it has been found
(USBasp, ft245r) but others would need to be converted.

-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]