Discussion:
[avrdude-dev] AVRDUDE+libusb, compiling and running on Windows
Didrik Madheden
2014-03-21 02:42:37 UTC
Permalink
Greetings. Today's adventure has been to install avrdude on a freshly
installed 64-bit Windows 7 installation. The subject of this e-mail is
twofold.

1) Trying to use the compiled version in avrdude-6.1-mingw32.zip, I
get an error about a missing libusb0.dll. I do know how to install
libusb. That is not the purpose of this request. Rather, I'm wondering
if it would perhaps be possible to conditionally link the libusb dll
using LoadLibrary and similar functions, so those who want to use
avrdude without USB support (for example for a serial only, or
parallel port programmer) can do so using the stock exe without
installing libusb. Of course, this requires R&D and possible
reorganization of the code, but I'm throwing it out there as a
possible idea.

2) I also gave compiling avrdude without libusb installed a try. I'm
guessing it was some time since someone tried this, as the compilation
failed. In particular, the failure is in dfu.c, flip1.c and flip2.c.
dfu.c defines a number of dummy functions, however, those don't match
the actual header definitions. (Haven't been updated in a while?)

However, these functions don't fix the problem entirely, as dfu.h
creates an empty struct and flip1/flip2 are accessing members of the
struct, and members of dev_desc (of type struct usb_device_descriptor)
directly. After defining stubs of the flip1/flip2 functions, I managed
to finally compile avrdude successfully without libusb present.

Where and how does one submit patches?

And finally, I'd like to suggest two long-term strategies for handling
this problem:

* For the binary (Windows) distribution, load the dll file
conditionally, as discussed above.

* For the source distribution, perhaps exclude non-supported
programming methods at build time instead of compiling them in as
stubs that generate an error at runtime. Is there an infrastructural
reason why this is done? To make avrdude.conf generation easier/less
error-throwing-prone?

/Didrik
Joerg Wunsch
2014-03-21 10:55:40 UTC
Permalink
Hello Didrik,
Post by Didrik Madheden
1) Trying to use the compiled version in avrdude-6.1-mingw32.zip, I
get an error about a missing libusb0.dll. I do know how to install
libusb.
You get it from the libusb-win32 project at SourceForge.net.
Post by Didrik Madheden
That is not the purpose of this request. Rather, I'm wondering
if it would perhaps be possible to conditionally link the libusb dll
using LoadLibrary and similar functions, so those who want to use
avrdude without USB support (for example for a serial only, or
parallel port programmer)
It might be possible to change it that way. But let's face it, how
many recent computer systems are around there that do offer parallel
or serial ports, and how many are there that offer only USB?

The Win32 binary is simply provided as a courtesy to Windows users who
often have (mental :) problems compiling something theirselves; as
such, it aims to cover the most predominant system configurations.
The primary focus of an opensource project is always to provide a
source code distribution, and leave it to others to ship binaries in
some way (possibly as part of some other packaging/bundling system for
their OS).

Dynamically loading libusb might have one other point though: some of
the USB programmers can be accessed without libusb, through some kind
of HID device access. By now, this only affects a few, but with Atmel
going to CMSIS-DAP compatible devices on their official tools lately
(embedded debugger EDBG on devkits; JTAGICE3 with firmware version
3.x; new Atmel-ICE dongle), this is certainly going to attract a lot
more interest.
Post by Didrik Madheden
2) I also gave compiling avrdude without libusb installed a try.
Yes, it has been reported before. There's a bug in AVRDUDE 6.1 that
prevents compiling without the presence of libusb.
Post by Didrik Madheden
Where and how does one submit patches?
Please, attach it to the open bug report:

https://savannah.nongnu.org/bugs/?41854
Post by Didrik Madheden
* For the binary (Windows) distribution, load the dll file
conditionally, as discussed above.
We won't do anything just for a single supported OS. If we do, we'll
do it for all supported OSes.
Post by Didrik Madheden
* For the source distribution, perhaps exclude non-supported
programming methods at build time instead of compiling them in as
stubs that generate an error at runtime. Is there an infrastructural
reason why this is done? To make avrdude.conf generation easier/less
error-throwing-prone?
Yes, it is. Albeit there are counter-examples, too. Parallel-port
programmers are indeed not generated into avrdude.conf if AVRDUDE
doesn't have parallel-port support on a particular OS (like, OSX for
example, which simply never ran on hardware that offers a parellel
port). However, it's probably much easier to tell the user his
software has been compiled without USB support, rather than yelling at
them, telling their programmer were simply not present in
avrdude.conf. Finally, for the JTAGICEmkII, it could be accessed
through both, RS-232 as well as USB.
--
cheers, Joerg .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
Didrik Madheden
2014-03-21 12:21:32 UTC
Permalink
Post by Joerg Wunsch
Post by Didrik Madheden
Where and how does one submit patches?
https://savannah.nongnu.org/bugs/?41854
Done.
Post by Joerg Wunsch
Post by Didrik Madheden
* For the source distribution, perhaps exclude non-supported
programming methods at build time instead of compiling them in as
stubs that generate an error at runtime. Is there an infrastructural
reason why this is done? To make avrdude.conf generation easier/less
error-throwing-prone?
Yes, it is. Albeit there are counter-examples, too. Parallel-port
programmers are indeed not generated into avrdude.conf if AVRDUDE
doesn't have parallel-port support on a particular OS (like, OSX for
example, which simply never ran on hardware that offers a parellel
port).
About that... Not everyone who's running the OSX operating system
choose to do so on an officially sanctioned white and shiny/brushed
aluminum box. This may not be a use case to care much about,
especially considering parallel ports have been dead for a few years,
but I like to point this out.

/Didrik
Joerg Wunsch
2014-03-21 12:26:02 UTC
Permalink
Post by Didrik Madheden
Done.
Thanks!
Post by Didrik Madheden
About that... Not everyone who's running the OSX operating system
choose to do so on an officially sanctioned white and shiny/brushed
aluminum box.
Still, that doesn't make the OS itself support the parallel port in
any way, even if it's physically present.

AVRDUDE can only sit on top of some OS-provided API to access the
port. OK, except on Windows, where there's only a crock since the OS
doesn't have an API ... I wouldn't want to pick this as an "how it
should be really done" example though.
--
cheers, Joerg .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
Jason Hecker
2014-04-11 23:15:52 UTC
Permalink
I too am having (mental) issues building avrdude for Win32 using
mingw32/msys. I *used* to be able to build and use it for supporting ftdi.

I have:

- Run Zadig to install the necessary libusb DLLs.
- Copied over lusb0_usb.h to the mingw32 include path.
-
Didrik Madheden
2014-04-15 07:54:59 UTC
Permalink
Post by Jason Hecker
I too am having (mental) issues building avrdude for Win32 using
mingw32/msys. I *used* to be able to build and use it for supporting ftdi.
- Run Zadig to install the necessary libusb DLLs.
- Copied over lusb0_usb.h to the mingw32 include path.
-
Didrik Madheden
2014-04-15 08:48:26 UTC
Permalink
In other words, ftdi.h (the header from libftdi, not part of avrdude)
Typo alert! That sentence is of course meant to say "includes usb.h".

And as for running the compiled binary, installing the libusb0 driver
through Zadig did work, however, doing this disables the regular
function of the chip as a serial port until the FTDI driver is
restored, which may be inconvenient if you need both. I had no luck
installing it as a filter driver, either.
... until after using Zadig. Brilliant.

However, the other problem with the libftdi is that it's hopelessly
slow. As a test, I tried reading the flash memory from an Atmega162,
which took 2.89 s using the serjtag version and 8.6 s using libftdi.

And also, programming does not seem to work with my freshly compiled
binary, even though reading does work and produces a correct output
file:

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.11s

avrdude.exe: Device signature = 0x1e9404
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be per
formed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: Device is not responding to program enable. Check connection.

avrdude.exe done. Thank you.

This is using a programmer defined as
programmer
id = "myprogrammer";
desc = "My programmer";
type = "ftdi_syncbb";
#ISP-signals
reset = 2;
sck = 5;
mosi = 3;
miso = 6;
#buff = 5;
#LED SIGNALs
#errled = ~ 12;
#rdyled = ~ 15;
#pgmled = ~ 14;
#vfyled = ~ 13;
;

The board contains a FT232RL connected to an Atmega162.
--
/Didrik
Jason Hecker
2014-04-18 06:48:08 UTC
Permalink
I have managed to wrangle avrdude.exe to work 'on my machine' and Win-32
for the purposes of it working with FTDI parts in MSSE/SPI mode.

I had to hack the Makefile to link to the .dll.a versions of files and make
some changes to the avrdude.conf file which I'll submit later.

Have a look here and try it out:

http://helix.air.net.au/index.php?cID=121
Post by Didrik Madheden
In other words, ftdi.h (the header from libftdi, not part of avrdude)
Typo alert! That sentence is of course meant to say "includes usb.h".
And as for running the compiled binary, installing the libusb0 driver
through Zadig did work, however, doing this disables the regular
function of the chip as a serial port until the FTDI driver is
restored, which may be inconvenient if you need both. I had no luck
installing it as a filter driver, either.
... until after using Zadig. Brilliant.
However, the other problem with the libftdi is that it's hopelessly
slow. As a test, I tried reading the flash memory from an Atmega162,
which took 2.89 s using the serjtag version and 8.6 s using libftdi.
And also, programming does not seem to work with my freshly compiled
binary, even though reading does work and produces a correct output
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.11s
avrdude.exe: Device signature = 0x1e9404
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be per
formed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: Device is not responding to program enable. Check connection.
avrdude.exe done. Thank you.
This is using a programmer defined as
programmer
id = "myprogrammer";
desc = "My programmer";
type = "ftdi_syncbb";
#ISP-signals
reset = 2;
sck = 5;
mosi = 3;
miso = 6;
#buff = 5;
#LED SIGNALs
#errled = ~ 12;
#rdyled = ~ 15;
#pgmled = ~ 14;
#vfyled = ~ 13;
;
The board contains a FT232RL connected to an Atmega162.
--
/Didrik
Loading...