avrdude: make program bricht ab

[Johannes B. (jubuntu79)]

Hallo zusammen,
bin neu hier und Anfänger in der Mikrocontroller-Programmierung.
Mithilfe eines Atmega32 steuere ich eine 7-Segment-Anzeige an.
Als Betriebssystem setze ich Xubuntu 15.10 ein. Ich arbeite mit avrdude 
auf dem Terminal.
Mit dem angehängten Dateien:
makefile
main.c
gelang es mir mittels

make all
make program

das Programm auf den Mikrocontroller zu spielen, unter der 
Voraussetzung, dass Codezeile 5 DDRD  = 0x00; auskommentiert ist (siehe 
unten).
Wenn ich das Programm erweiterte, trat dann oft ein Fehler auf:

(...)
Writing | #########################avrdude: butterfly_recv(): programmer is not responding
makefile:325: recipe for target 'program' failed
make: *** [program] Error 1

Komplette Ausgabe siehe angehängte Datei "ausgabe"
Zunächst suchte ich nach Programmierfehlern, aber nun stellte sich 
heraus, dass ab einer bestimmten Größe der .hex-Datei das Laden nicht 
mehr funktioniert.
a) Wenn ich Zeile 5 auskommentiere, funktioniert die Übertragung 
fehlerfrei und eine "1" wird in der 7-Segment-Anzeige angezeigt.
b) Wenn ich Zeile 5 einkommentiere, bricht die Übertragung mit oben 
genanntem Fehler ab.
c) Wenn ich Zeile 5 einkommentiert lasse und Zeile 3 und 4 
auskommentiere, lässt sich das Programm ebenfalls übertragen.
Als Programmer verwende ich den mySmartUSB light.
Herzlichen Dank im voraus für jegliche Unterstützung bei der Suche eines 
Fehlers, der für mich unerklärlich scheint.

main.c

#include <avr/io.h>

void main (void)
{
/* Zeile 1 */   DDRB  = 1 << DDB4;
/* Zeile 2 */   PORTB = 1 << PB4;  // Zeile 1
/* Zeile 3 */   DDRC  = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4) | (1 << DDB5) | (1 << DDB6);
/* Zeile 4 */   PORTC = (1 << PC0) | (1 << PC1) | (1 << PC2) | (1 << PC3) | (1 << PC6);
/* Zeile 5 */   // DDRD  = 0x00;
}

[Stefan F. (Gast)]

Die Fehlermeldung "programmer is not responding" hat überhaupt nichts 
mit dem Programm-Quelltext zu tun.

Ich denke, dein programmer ist defekt, oder die Verbindung zum µC, oder 
die Stromversorgung oder ein Schaltungsfehler.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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"

[Jörg W. (dl8dtl) (Moderator)]

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?

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Johannes B. (jubuntu79)]

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

4.2.0-30-generic

Version avrdude:
avrdude -v

avrdude: Version 6.1, compiled on Sep  8 2015 at 09:40:37
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/home/johannes/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping


avrdude: no programmer has been specified on the command line or the config file
         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

avrdude
  Depends: libc6
  Depends: libelf1
  Depends: libftdi1
  Depends: libreadline6
  Depends: libusb-0.1-4
  Suggests: avrdude-doc
  Conflicts: avrdude:i386

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

              
ii  avrdude                                     6.1-4build1                              amd64        software for programming Atmel AVR microcontrollers
ii  libgusb2:amd64                              0.2.6-1                                  amd64        GLib wrapper around libusb1
ii  libusb-0.1-4:amd64                          2:0.1.12-27                              amd64        userspace USB programming library
ii  libusb-1.0-0:amd64                          2:1.0.19-1                               amd64        userspace USB programming library
ii  libusbmuxd2:amd64                           1.0.9-1build1                            amd64        USB multiplexor daemon for iPhone and iPod Touch devices - library

[Jörg W. (dl8dtl) (Moderator)]

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