avrdude: make program bricht ab

Das Problem hängt vermutlich damit zusammen, dass der aufgerufene 
avrdude auf libusb 0.1 basiert, heutzutage aber libusb 1.0 üblich ist. 
Durch den erforderlichen Wrapper der APIs tritt der folgende Fehler 
zutage, den ich schon vor einigen Jahren ausgiebig analysiert hatte:

http://blog.gmane.org/gmane.comp.hardware.avr.avrdude.devel/month=20100601
Beitrag "Probleme mit usbprog"

Andreas S. schrieb:
> Durch den erforderlichen Wrapper der APIs tritt der folgende Fehler
> zutage, den ich schon vor einigen Jahren ausgiebig analysiert hatte:

Dort schreibst du aber, dass es durch eine hinreichend neue Version
von Linux-Kernel und libusb beseitigt sei.  Das war vor mehr als
5 Jahren, und mittlerweile dürften die entsprechenden Versionen doch
allemal durchweg vorhanden sein, oder?

Jörg W. schrieb:
> Das war vor mehr als
> 5 Jahren, und mittlerweile dürften die entsprechenden Versionen doch
> allemal durchweg vorhanden sein, oder?

Da Johannes nicht haarklein die genauen Versionsstände aller relevanter 
Komponenten aufgeführt hat, gehe ich davon aus, dass sich z.B. ein 
uralter Avrdude auf seinen Computer verirrt hat.

Andreas S. schrieb:
> ein uralter Avrdude auf

Sollte aber eigentlich egal sein, solange Kernel + libusb hinreichend
neu sind, denn die libusb wird dynamisch gelinkt.

Aber es ist natürlich korrekt, dass da nirgends ein Hinweis zu
finden ist, welche Versionen von Linux-Kernel, libusb und AVRDUDE
da benutzt worden sind.

Stefan U. schrieb:
> Die Fehlermeldung "programmer is not responding" hat überhaupt nichts
> mit dem Programm-Quelltext zu tun.

Natürlich hat die Fehlermeldung nicht unmittelbar etwas mit dem 
Quelltext zu tun, möglicherweise aber mit dem Kompilat dieser 
Quelltexte, so wie von mir ausführlich beschrieben. Auch damals gab es 
schon unbelehrbare Forenteilnehmer, die die unhaltbare Auffassung 
vertraten, dass eine datenabhängige Fehlfunktion der USB-Übertragung 
unmöglich wäre.

Andreas S. schrieb:
> Auch damals gab es schon unbelehrbare Forenteilnehmer, die die
> unhaltbare Auffassung vertraten, dass eine datenabhängige Fehlfunktion
> der USB-Übertragung unmöglich wäre.

Ist sie ja an sich auch :), aber ein Bug in einer Bibliotheksebene
kann (wie du ja gezeigt hast) dann schon dazu führen, dass da
irgendeine Abhängigkeit von den Daten entsteht.

Jörg W. schrieb:
> Ist sie ja an sich auch :), aber ein Bug in einer Bibliotheksebene
> kann (wie du ja gezeigt hast) dann schon dazu führen, dass da
> irgendeine Abhängigkeit von den Daten entsteht.

Ähnliche datenmusterabhängige Probleme entstehen aber z.B. auch bei 
manchen Übertragungsprotokollen, bei denen eine Taktrekonstruktion aus 
den Daten erfolgt. Gerade bei letzteren erlebt man es ja recht häufig, 
dass bei bestimmten optischen Dämpfungsverhältnissen einige Tastendrücke 
noch erkannt werden, andere aber nicht mehr.

Man findet auch im Mikrocontroller-Forum recht häufig Diskussionen über 
den Entwurf von Übertragungsprotokollen. Einige Anfänger wählen dann 
mehr oder minder willkürlich beliebige Werte für die Kennzeichnung von 
Paketanfang, -ende oder Escapezeichen. Sobald man sich jedoch überlegt, 
wie solche Sonderdaten auf den darunter befindlichen Schichten 
dargestellt werden, erkennt man sehr schnell, warum bestimmte 
Datenmuster sinnvoll sind und andere nicht. Leider ruft man damit aber 
wieder einige "Reinrauminformatiker" auf den Plan, die die "reine Lehre" 
vertreten und behaupten, dass Protokolle schlecht konstruiert seien, 
wenn eine Protokollschicht die Besonderheiten darüber oder darunter 
befindlicher Schichten berücksichtigen.

Hallo zusammen,
herzlichen Dank für die vielen Antworten. Die fehlenden Infos liefere 
ich gerne nach. Falls noch etwas fehlt, bitte schreiben.
Hab zu später Stunde noch keine Lösung gefunden, aber ich halte es auch 
für wahrscheinlich, dass es an der libusb liegt. Danke, @Andreas 
Schweigstill

Kernel:
uname -r

1

4.2.0-30-generic

Version avrdude:
avrdude -v

1

avrdude: Version 6.1, compiled on Sep  8 2015 at 09:40:37

2

         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

3

         Copyright (c) 2007-2014 Joerg Wunsch

4

5

         System wide configuration file is "/etc/avrdude.conf"

6

         User configuration file is "/home/johannes/.avrduderc"

7

         User configuration file does not exist or is not a regular file, skipping

8

9

10

avrdude: no programmer has been specified on the command line or the config file

11

         Specify a programmer using the -c option and try again

avrdude ist erstaunlicherweise von libusb-0.1-4:amd64 abhängig:
apt-cache depends avrdude

1

avrdude

2

  Depends: libc6

3

  Depends: libelf1

4

  Depends: libftdi1

5

  Depends: libreadline6

6

  Depends: libusb-0.1-4

7

  Suggests: avrdude-doc

8

  Conflicts: avrdude:i386

dpkg -l | grep -E "avrdude | libusb"

1

2

ii  avrdude                                     6.1-4build1                              amd64        software for programming Atmel AVR microcontrollers

3

ii  libgusb2:amd64                              0.2.6-1                                  amd64        GLib wrapper around libusb1

4

ii  libusb-0.1-4:amd64                          2:0.1.12-27                              amd64        userspace USB programming library

5

ii  libusb-1.0-0:amd64                          2:1.0.19-1                               amd64        userspace USB programming library

6

ii  libusbmuxd2:amd64                           1.0.9-1build1                            amd64        USB multiplexor daemon for iPhone and iPod Touch devices - library

Das sollte alles aktuell genug sein, als dass das von Andreas
beschriebene Problem mit den zero-length packets nicht mehr
zutrifft.