Tester für Spezialversion des AVR Bootloaders optiboot gesucht!

Ein kleiner Nachtrag, um den Einstieg in Tests zu erleichtern.
Die beigefügte optiboot.zip Datei kann man in den Unterordner 
hardware/arduino/arduino/avr/bootloaders des Arduino Sketch schieben und 
dort auspacken. Vorher sollte man den bestehenden Unterordner optiboot 
umbenennen, um eine Rückkehrmöglichkeit zum Originalzustand zu haben!
Selbst habe ich den Bootloader für ein Arduino-UNO Board schon 
erfolgreich getestet.
Bedingung für das Schreiben eines neuen Bootloaders ist natürlich auch 
hier ein angeschlossener ISP-Programmer. Dafür kann auch ein UNO-Board 
mit der Arduino-ISP Software aus den Beispielen dienen. Mit diesem so 
programmierten UNO-Board kann dann ein weiteres UNO-Board oder auch ein 
anderer ATmega mit einem Bootloader ausgestattet werden.
Das Schreiben des Bootloaders kann mit der Sketch Oberfläche bei den 
Werkzeugen gestartet werden. Dazu sollte der Programmer bei den 
Werkzeugen
vorher ausgewählt sein.
Für den Arduino-UNO wird standardmäßig die Datei optiboot_atmega328.hex 
aus dem optiboot Verzeichnis als Bootloader verwendet. Bei meiner 
optiboot Version werden übrigens am Ende der optiboot_atmega328.lst 
Datei die verwendeten Optionen protokolliert!
Damit kann man unter anderem die eingestellte Baudrate und die Frequenz 
der CPU Clock für die .hex Datei nachlesen.
Die Optiboot Zip Datei enthält übrigens schon alle Quellen und die 
Makefiles. Man kann also beliebige Bootloader (Prozessor, CPU-Frequenz, 
Baudrate ...) erzeugen.
Die PDF-Dokumentation findet man im SVN Archiv oder auch im gedoppelten 
github Archiv 
(github.com/svn2github/transistortester/tree/master/bootloaders/Doku/ger 
man).

Nach nochmaliger Überarbeitung habe ich zahlreiche zusätzliche 
Prozessoren in den Quellen berücksichtigt.
Hier die Liste der derzeit unterstützten Prozessoren:
ATmega8/16/32/64/88
ATmega162/163/164/165/168/169
ATmega323/324/325/3250/328/329
ATmega640/644/6450/649/6490
AT90CAN32/64/128
AT90PWM2/3
ATtiny84/85/88/861/1634
Oft wird auch die Picopower (P) Version berücksichtigt. Der Bootloader 
hat dafür zwar keine Besonderheiten, aber bei der ISP-Programmierung 
(mit avrdude) muß die andere Identifikations-Nummer des P-AVRs 
berücksichtigt werden.

Wenn Interesse besteht, könnte man auch die ATtiny's mit 4k Flash 
berücksichtigen. Die make Targets mit dem Anhängsel _isp (z.B. 
atmega328p_isp) habe ich weitgehend aus den Makefiles entfernt. Dafür 
muß jetzt der make Aufruf mit dem Parameter ISP=1 benutzt werden (make 
atmega823p ISP=1). Der Vorteil ist, daß die Auswahlliste übersichtlicher 
wird, die durch den Aufruf von z.B. "make atmega<TAB><TAB>" angezeigt 
wird. Natürlich ist mit <TAB> hier die Tabulator-Taste gemeint!

Im übrigen wünsche ich Allen ein frohes Weihnachtsfest!

Welchem höheren Zweck dient die Portierung nach Assembler? Wie steht's 
mit der Portierbarkeit dann zu anderen AVR Typen? Die meisten AVR 
Mikrocontroller haben doch Speicher satt mit >=32KB und den kriegt die 
Mehrheit der Hobbyprogrammierer wohl eher selten voll. Warum nur unter 
Linux kompilierbar?

Die Makefile für diese Optiboot Version ist derzeit nur unter Linux 
nutzbar, weil einige Linux-Tools benötigt werden, um die Lage des 
Bootloaders im Flash und die Fuses automatisch zu bestimmen. Die Fuses 
werden automatisch angepasst, wenn 1, 2, 4 oder 8 Boot-Pages gebraucht 
werden. Die Lage (Startaddresse) ist abhängig von der Flash-Größe des 
Prozessors und der Zahl der benutzten Bootpages.

Die Assembler-Version braucht mit der EEprom Unterstützung (.eep Files 
ladbar) etwa genau so viel Speicher wie die C-Version ohne die EEprom 
Unterstützung.
Für den konkreten Fall ATmega328-Familie bedeutet das, daß mit der 
EEprom-Unterstützung 1024 Byte statt 512 Byte vom C-Bootloader belegt 
werden!
Derzeit sind folgende Prozessoren getestet:
m8, m48p, m88, m168, m328p, m64, m128, m645, m169, t24a, t44a und t84a.
Weitere Tests sind in Arbeit.
Schwierigkeit macht derzeit der ATtiny88 (t88),
der will den Flash nicht vom Bootloader beschrieben haben.

Hab mein virtuelles Ubuntu hervorgeholt und konnte damit nach 
Installation von bc zwar compilieren, nur das Ergebnis funktionierte 
dann leider nicht immer. Meine eigene Schaltung läuft mit ATmega1284P 
bei 11.0592 MHz, high fuse wurde mit -U hfuse:w:0xDC:m auf Startadresse 
FC00 gesetzt. Hardware-USART0. Kann der aktuelle Stand überhaupt für den 
m1284p funktionieren?

Auch für einen Arduino Uno hab ich es versucht, ging mit Einschränkung. 
LED_START_FLASHES=10 z.B. verhinderte meistens den sync mit avrdude, 
ansonsten Ok.

Das hier ist die Ausgabe bei dem Makefile Aufruf:
bootloaders/optiboot $ make atmega1284p AVR_FREQ=11059200 ISP=1
avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega1284p
 -fno-diagnostics-show-caret -DBAUD_RATE=115200 -DLED_START_FLASHES=3 
-DSUPPORT_EEPROM=1 -DLED=n -DUART=0 -DSOFT_UART=0 \
        -DUART_RX=n -DUART_TX=n -DF_CPU=11059200 \
        -DBOOT_PAGE_LEN=1024 -c -o optiboot.o optiboot.S
In file included from optiboot.S:254:0:
pin_defs.h:468:4: warning: #warning "LED bit is set to default B0" 
[-Wcpp]
------------------------------------------------------------------------ 
---
BAUD RATE CHECK: Desired: 115200, Real: 115200, UBRR = 11, Error=0%
------------------------------------------------------------------------ 
---
######################################
Boot Loader start address: 0x1FC00
######################################

11059200 Hz operation with Baudrate 115200 configured.
avr-size optiboot.elf
   text     data      bss      dec      hex  filename
    480        0        0      480      1e0  optiboot.elf
Requires 1 Boot Pages, 1024 Bytes each
BOOTSZ=3
avr-objdump -h -S optiboot.elf > optiboot_atmega1284p.lst
avr-objcopy -j .text -j .data -j .version --set-section-flags 
.version=alloc,load -O ihex optiboot.elf optiboot_atmega1284p.hex
   Fuses in Makefile.isp are set to lfuse=0xFF, hfuse=0x9F, efuse=0xFD 
for atmega1284p
Bootloader HFUSE = 0x9E [0x9F], BootLoader Start is enabled to 0x1FC00
avrdude  -c stk500v2 -B 50 \
              -p atmega1284p -P usb -b 115200 \
              -e -u -U efuse:w:0xFD:m -U hfuse:w:0x9E:m -U 
lfuse:w:0xFF:m

avrdude: stk500v2_command(): command failed


Da ich den passenden Quarz nicht habe, kann ich leider nicht vollständig 
testen. Den ATmega1284 habe ich auf jeden Fall einsatzbereit und auch 
schon erfolgreich getestet. Wie man aus der Ausgabe sieht, wählt das 
make System eine andere hfuse (0x9E). Je nach Prozessor wird die hfuse 
oder die lfuse auf die passende Bootpartitions-Größe angepasst. 
Eigentlich sollte die zu große Bootpartition aber keine Probleme machen, 
der Atmega läuft durch den leeren Speicher bis zum Bootloaderstart. Die 
Start-Adresse 0x1FC00 ist die Byte-Adresse, die Wort-Adresse ist 0xFE00!

Das Problem mit dem sync bei Avrdude ist mir bekannt. Das Original von 
optiboot hat in einigen Fällen das Blinken abgebrochen, wenn 
RX-Daten-Beginn (Start-Bit) festgestellt wurde. Das macht meine Version 
derzeit nicht!
Der Standard-Wert von 3x Blinken hat bei mir aber keine Probleme 
gemacht.

Vor einigen Jahren haben wir eine spezielle Optiboot Version mit 
automatischer Baudratenerkennung gemacht, damit man für unterschiedliche 
Baudraten oder Quarze den selben Bootloader verwenden kann. Die Baudrate 
wird dabei aus dem STK_GET_SYNC (0x30) Befehl berechnet.
Wir verwenden den Bootloader auf unseren Mega328 basierten Boards und 
bis jetzt sind uns keinerlei Probleme bekannt. Hier ist der Quellcode zu 
finden:
https://github.com/watterott/Wattuino/tree/master/software/Optiboot

Diese Version hatte ich wahrscheinlich übersehen, als ich auf der Suche 
nach einer Bootloader-Version war, die EEprom programmieren kann und mit 
512 Byte auskommt. Aber das schafft diese Version aber auch nicht, oder?

Bei meiner Version kann man jetzt auch die Überwachung des RX-Bits in 
die Blink-Scheife integrieren, indem man die Anzahl des Blinkens negativ 
setzt. Das erfordert natürlich etwas mehr Speicher. Ich komme dennoch 
mit 512 Byte inklusive der EEprom-Unterstützung aus.
Die automatische Baudraten-Erkennung könnte ich gegebenenfalls auch noch 
einbauen, dann brauche ich wahrscheinlich bei Nutzung aller Optionen 
mehr als 512 Byte.

EEPROM-Unterstützung hat unsere Version nicht und mit AVR-GCC 5.4 sind 
noch 34 Bytes frei.

Mit der RX-Pin Überwachung in der Blinkschleife belegt die aktuelle 
Assembler-Version 486 Bytes, ohne Überwachung sind es 474 Byte. In 
beiden Fällen mit der EEprom Unterstützung für einen ATmega328(p).
Ohne EEprom-Unterstützung mit RX Überwachung sind es nur 440 Byte. Da 
ist also auf jeden Fall noch Luft für die automatische 
Baudraten-Ermittlung.
In der Wattuino Version ist, soweit ich das im Source erkennen kann, die 
Ermittlung der Baudrate nicht abschaltbar und nicht mit der 
Software-UART Lösung gemeinsam nutzbar. Damit könnte die Version nicht 
für ATtinys ohne Hardware-UART eingesetzt werden.

Für mein Vorhaben ist ein Bootloader mit EEprom-Unterstützung ein 
absolutes Muss-Kriterium oder anders gesagt der eigentliche Grund für 
das Ganze - es geht um Konfigurationstausch mit avrdude in einem 
entfernt verbauten Schaltkasten. Daher hab ich mir das hier angeschaut. 
Schade, dass die meisten mir bekannten Alternativen den EEprom links 
liegen lassen. Warum nur?

Was mir nun auffiel, dass mit 16 MHz Quarz in meiner Schaltung mit 
m1284p der Übertragungsfehler offensichtlich so groß ist, dass avrdude 
aus der Synchronisation fällt. Beim Uno jedoch nicht. Werden die Typen 
softwaremäßig unterschiedlich behandelt? (Hab den ganzen Quellcode nicht 
durchgepflügt.) Mit einem 14.7456 MHz Quarz geht es nun bis jetzt ohne 
weiteren Fehler.

Als nächstes werde ich noch einen m128 und m32 testen.

No N. schrieb:
> Schade, dass die meisten mir bekannten Alternativen den EEprom links
> liegen lassen. Warum nur?

Das sind meistens Platzprobleme, mindestens dann, wenn der Bootloader in 
512 Byte untergebracht werden soll. Beim mega1284 wäre allerdings mit 
mindestens 1k Flash für den Bootloader genug Platz.

No N. schrieb:
> dass mit 16 MHz Quarz in meiner Schaltung mit
> m1284p der Übertragungsfehler offensichtlich so groß ist, dass avrdude
> aus der Synchronisation fällt.

Bei welcher Baudrate und wie sieht die Gegenseite der seriellen 
Schnittstelle aus?
Bei 16 MHz und 115.2kBaud ist der systematische Fehler für die Baudrate 
schon recht hoch (2.12%, real 117.647kBaud). Wenn die Gegenseite dann 
den Fehler in die andere Richtung macht? Bei niedrigeren Baudraten ist 
der Fehler geringer. Oder eben bei einem anderen Quarz auch. Die 
Baud-Zeit muß ein ganzzahliges Vielfaches von 8/F_CPU sein, dann passt 
es. Bei 16MHz und 115.2kBaud gibt es keinen günstigeren Teiler als 17.
Bei meiner Softwarelösung für den UART bleibt der Fehler zwar geringer 
(0.07%), aber bei hohen Baudraten macht die Zeit für den Wechsel von 
Sendebetrieb auf Empfang Probleme.
Ich werde aber auf jeden Fall noch Tests mit einer Auto-Baud Funktion 
machen. Das löst aber nicht das prinzipielle Problem mit dem 
Frequenz-Teiler.

Vielleicht nochmal zur Klarstellung. Compiliere ich deine Sourcen für 
einen m328p des Arduino Uno mit 16 MHz funktioniert ein Up-/Download 
scheinbar problemlos. Mache ich das Gleiche für einen m1284p mit 
Parametern AVR_FREQ=16000000 LED_START_FLASHES=3 LED=D4 TIMEOUT_MS=2000 
BAUD_RATE=115200 bricht avrdude ab. Mit einem Baudraten-Quarz, den ich 
sowieso nehmen wollte, geht's es ja. Nur warum der Unterschied im 
Verhalten zwischen beiden Mikrocontrollern? Mal schauen, wie es heute 
Abend beim m128 und m32 läuft.

Meine Meinung zu dieser Speichersparerei für den Bootloader habe ich 
schon oben geschrieben, halte das für viele µCtrl als sportlich 
übertrieben. Mir geht's um Funktionalität und Stabilität und nicht um 
den Wanderpokal, wer kann am meisten Speicher sparen.

No N. schrieb:
> Mache ich das Gleiche für einen m1284p mit
> Parametern AVR_FREQ=16000000 LED_START_FLASHES=3 LED=D4 TIMEOUT_MS=2000
> BAUD_RATE=115200 bricht avrdude ab.

Wenn Du in der Lage bist, die Baudrate nachzumessen, gibt es noch einen 
Spezial-Tipp. Mit dem Parameter TEST_OUTPUT=1 wird anstelle der normalen 
Bootloader-Funktion in einer Endlosschleife 'U'=0b01010101 ausgegeben. 
Das erzeugt mit der UART-Schnittstelle eine Frequenz mit der halben 
Baudrate.
Eigentlich ist auch noch die Erzeugung einer Frequenz mit AVR_FREQ/512 
mit einem Counter vorgesehen. Das kostet aber noch Programmierarbeit, da 
die Pínbelegung der Counter-Ausgänge sich von AVR-Familie zu AVR-Familie 
unterscheiden. In der SVN-Revision 763 habe ich den Beispiel-Code für 
ein Counter-Ausgabesignal deaktiviert, weil der für den ATmega1284 nicht 
läuft.
Für den ATmega1284 müßten die Befehle

1

 ASBI  DDRD, DDD7

2

 ldi   r24, (1<<COM2A0)

3

 AOUT  TCCR2A, r24

4

 ldi   r24, (1<<CS20)

5

 AOUT  TCCR2B, r24

bei Zeile 579 in optiboot.S eingefügt werden, um ein Ausgangssignal an 
PortD, Pin 7 mit der Frequenz 16000000/512 = 31250Hz.
Dazu muß natürlich PD7 für die Benutzung frei sein.

Wenn die Taktfrequenz stimmt, müßten die 31.25kHz genau stimmen.
Am TX-Ausgang erwarte ich ein 58.824kHz Signal.

Nun ist auch eine Auto-Baud Funktion beim neuen Optiboot wählbar.
Dabei wird die STK_GET_SYNC Byte-Folge analysiert.
Die Auto-Baud Funktion wird immer ins Programm eingebaut, wenn eine 
Baudrate von unter 100 Baud bei der Erzeugung angegeben wird. Die 
einfachste Form der Baudraten-Messung wird bei einer Baudrate unter 50 
genommen. Bei einer Baudrate unter 60 wird zusätzlich eine 
Zeitüberwachung mit eingebaut.
Bei einer Baudrate unter 80 wird eine aufwendigere Prüfung des 
empfangenen Bytes durchgeführt, um eine falsche Synchronisierung der 
seriellen Schnittstelle auszuschließen. In allen Fällen wird die 
Baudrate aus der Übertragungszeit von 2 Bits bestimmt.
Wenn die angegebene Baudrate unter 100 aber über 79 liegt, wird die 
gleiche
Prüfung wie bei unter 80 durchgeführt, die Baudrate wird aber aus der 
Übertragungszeit von 4 Datenbits bestimmt.
Die Auto-Baud Funktion ist sowohl mit der Hardware UART Schnittstelle 
als auch mit der Software UART Lösung nutzbar.
In 512 Byte passt die Optiboot Version zusammen mit der EEprom 
Unterstützung, mit einer einfachen Auto-Baud Funktion, mit dem Hardware 
UART und ohne die LED-Blinkfunktion.
Für einen ATmega328p (Arduino UNO) also:
make atmega328 BAUD_RATE=52 LED_START_FLASHES=0

Weitere Informationen findet man in der PDF-Dokumentation.

In der Zwischenzeit habe ich deinen Code für verschiedene AVR Typen 
compiliert und im erfolgreichen Einsatz. Vielen Dank. Meine ersten 
Schwierigkeiten kamen von nicht akzeptierten Einstellungen.

Vielen Dank für die Rückmeldung!
Für den ATmega1284 und alle anderen Prozessoren mit mehr als 512 Byte 
Mindestgröße für den Bootloader ist die neue automatische 
Baudratenerkennung sinnvoll. Damit wird dann für den 16MHz Betrieb jede 
Baudrate zwischen 1200 und 115200 automatisch erkannt (HW-UART). Beim 
ATmega1284 sind dann folgende Einstellungen sinnvoll:
make atmega1284p BAUD_RATE=86 LED_START_FLASHES=-3
Durch die negative Zahl beim LED_START_FLASHES wird das Blinken 
abgebrochen,
sobald ein serielles RX Signal erkannt wird.

Für einen ATmega328 oder ATmega8 sollte auf das Blinken der LED 
verzichtet werden, wenn die automatische Baudraten-Anpassung zusammen 
mit der EEprom Unterstützung genutzt werden soll. Zusätzlich muß auch 
eine einfachere Form der Baudraten-Messung gewählt werden, damit das 
Programm in 512 Byte passt.
make atmega328p BAUD_RATE=56 LED_START_FLASHES=0

Ein Vorteil der automatischen Baudratenwahl besteht darin, daß die 
serielle Schnittstelle auch bei Betrieb mit dem internen RC-Generator 
(meist 8 MHz) ohne Kalibrierung der Frequenz genutzt werden kann.
Außerdem kann problemlos eine niedrigere Baudrate für die Übertragung 
genutzt werden, wenn bei der höchst möglichen Baudrate Probleme 
auftauchen.
Übrigens kann die automatische Baudraten-Anpassung auch zusammen mit 
einer Software UART Lösung genutzt werden. Das braucht aber etwas 
zusätzlichen Speicherplatz.

Kann es sein, dass dein Code nicht für UART1 funktioniert? Hab hier eine 
Schaltung mit ATmega128, getaktet mit 11059200Hz, LED an PE1 und dessen 
zweiter UART mit dem PC verbunden ist. Beim Starten blinkt die LED nicht 
und Kommunikation mit avrdude klappt nicht. Da PE1 auch Teil von UART0 
ist und man nur kleinste Unterberechungen im Dauerleuchten sieht, deutet 
das für mich  auf einen Bug hin. Ein Compilieren mit den C-Sourcen ging 
nicht. Ne Idee?

Birger Z. schrieb:
> Ne Idee?

Ja, aus Versehen wurde für die ATmega128 Familie der zweite UART Port 
nicht unterstützt. Die korrigierte pin_defs.h Datei ist jetzt im 
SVN-Archiv hochgeleaden.
Mit dem folgenden Make Aufruf ergeben sich die beigefügten Dateien:
make atmega128 UART=1 LED=E1 LED_START_FLASHES=-3 AVR_FREQ=11059200 
BAUD_RATE=82

Bei BAUD_RATE=82 wird eine automatische Baudraten-Anpassung benutzt. 
Getestet habe ich übrigens mit einem 11 MHz Quarz und den Baudraten 
57600 und 115200 für PD2(RXD1) und PD3(TXD1). Natürlich ist auch 19200 
Baud benutzbar.

Birger Z. schrieb:
> Ein Compilieren mit den C-Sourcen ging
> nicht

Die C-Quellen habe ich zusätzlich auch getestet:
make atmega128 UART=1 LED=E1 LED_START_FLASHES=-3 AVR_FREQ=11059200 
BAUD_RATE=82 SUPPORT_EEPROM=1 C_SOURCE=1
Die Tests mit verschiedenen Baudraten waren auch erfolgreich. Es wird 
nur 792 Byte statt 602 Byte bei der Assembler-Version verbraucht, was 
bei diesem Prozessor nicht weiter schlimm ist, da ohnehin mindestens 
1024 Byte für den Bootloader zur Verfügung stehen.
Die Makefile ist derzeit nur unter Linux nutzbar, da bei Windows einige 
Tools nicht zur Verfügung stehen, die für die automatische Ermittlung 
der Startadresse und der Fuses benutzt werden. Möglicherweise ist eine 
Anpassung der Makefile für Windows möglich, wenn Cycwin für die 
fehlenden Tools installiert wird.

Die obige optiboot_atmega128.hex funktioniert schon mal - Danke. Nur 
leider kann ich die aktuellen Sourcen aus dem SVN selber nicht mehr 
compilieren. Arbeite dazu mit 'nem virtuellen Ubuntu. Bricht mit 
Klammer-Fehlern in optiboot.S Zeilen 824 u. 878 ab, die ich nicht 
verstehe. Programmiere üblich nur in C. Übersehe ich etwas?

Birger Z. schrieb:
> Übersehe ich etwas?

Normalerweise wird NRWWSTART in der Datei optiboot.h definiert. 
Möglicherweise wird die verwendete avr-gcc Version von dem Ausdruck 1UL 
in Zeile 79 der Datei optiboot.h gestört.
Probeweise bitte Zeile 79 ändern:
77: /* the total Bootloader area (8 Boot pages) is NRWW */
78:  #ifdef _ASSEMBLER_
79:   #define NRWWSTART  (((FLASHEND+1)  - (BOOT_PAGE_LEN * 8)) & 
0xffff)
80:  #else
81:   #define NRWWSTART  (((FLASHEND+1UL)  - (BOOT_PAGE_LEN * 8)) & 
0xffff)
82:  #endif
Meine avr-gcc Version 7.2.0 hat auch den 1UL Ausdruck verkraftet, kommt 
aber auch mit der geänderten Version zurecht.

Mit (FLASHEND+1) statt (FLASHEND+1UL) klappt's wieder.

Wieso nimmst du LED_START_FLASHES=-3? Die -3 verursacht eine Warnung. 
Was bewirken hier negative Zahlen?

Mein avr-gcc --version gibt sowohl unter Windows als auch Unbuntu 16.04 
LTS 4.9.2 aus. Hast du dir die 7.2.0 selber compiliert?

Die Vorgabe einer negativen Anzahl von Wiederholungen aktiviert eine 
zusätzliche Überwachung des RX-Eingangs. Das Blinken wird dann 
abgebrochen, wenn ein Startbit detektiert wird.
Bei einer positiven Anzahl wird auf jeden Fall die angegebene Anzahl 
geblinkt, bevor der serielle RX-Eingang beachtet wird.
Bei der negativen Anzahl können auch viele Blink-Zyklen (bis 256) 
vorgegeben werden, ohne dass es zu Schwierigkeiten beim Download kommt. 
Allerdings wird dadurch auch der Start des Anwenderprogramms 
entsprechend verzögert.

Birger Z. schrieb:
> Hast du dir die 7.2.0 selber compiliert?

So weit ich mich erinnern kann nicht. Ich habe wohl ein fertiges Paket 
avr-gcc-7.2.0-1-x86_64.pkg.tar.xz im Netz gefunden. Dazu passt wohl auch 
avr-libc-2.0.0-1-any.pkg.tar.xy und 
avr-binutils-2.29.1-1-x86_64.pkg.tar.xz .
Interessant ware die neue Version wegen der Unterstützung neuerer 
AVR-Typen.

Da über die übliche Ubuntu Paketverwaltung z.Z. der avr-gcc 4.9.2 
verteilt  wird, würde ich doch dafür plädieren, nicht Features eines 
ganz frischen Compilers zu nehmen.

Es gibt noch neuere AVR Typen? Dachte, die Entwicklung für diese 
8-Bitter ist am Ende angelangt, auch nach dem abermaligen Verkauf von 
Atmel.

Birger Z. schrieb:
> Es gibt noch neuere AVR Typen?

Ich meinte keine ganz neue AVR, sondern eine Serie ATtiny von Anno 2014 
wie
t1634, t841 oder t167, die nach meiner Erinnerung nicht alle von älteren 
arg-gcc Versionen unterstützt wurden. Außerdem unterscheiden sich die 
avr-gcc Versionen durch unterschiedliche Optimierung, was natürlich für 
die Assembler-Quelle keine Rolle spielt. Die Optimierung ist aber beim 
Transistortester-Projekt (C-Quellen) wichtig.

Übrigens kann der optiboot Bootloader nun auch für die Prozessoren 
ATmega8U2, ATmega16U2, ATmega32U2, ATmega16U4 und ATmega32U4 verwendet 
werden. Natürlich nur für die serielle Schnittstelle (RXD1, TXD1) und 
nicht für die USB-Schnittstelle. Dann können die Daten trotzdem mit 
einem zusätzlichen USB-Seriell Wandler über die USB-Schnittstelle zum 
ATmega geschickt werden.
Wenn für den Download der Programm-Daten die serielle Schnittstelle 
statt der ebenfalls vorhandenen USB-Schnittstelle (UVCC, D-, D+, UGND) 
verwendet wird, steht deutlich mehr Flash-Speicher für das 
Anwenderprogramm zur Verfügung. Natürlich kann das Anwenderprogramm 
trotzdem die USB-Schnittstelle verwenden.