Für das Transistortester-Projekt hatte ich schon vor einiger Zeit eine spezielle Version des optiboot Bootloaders weiterentwickelt. Diese Version ist komplett in Assembler umgeschrieben und kann auch das EEprom beschreiben. Dabei passt der Bootloader in 512 Byte, selbst wenn ein Software-UART benutzt wird. Mit einem Linux System ist die Benutzung denkbar einfach. Zum Programmieren des Bootloaders auf einen Arduino UNO reicht ein "make atmega328p_isp" aus. Selbstverständlich muß ein ISP Programmer mit dem Board und dem Rechner verbunden sein. Als Besonderheit kann der Bootloader für TXD und RXD einen gemeinsamen Pin des ATmega benutzen (One-Wire), wenn die SOFT_UART Option benutzt wird. Für einen problemlosen Betrieb mit Standardprogrammen wie avrdude habe ich in der Dokumentation eine Schaltung vorgeschlagen, die zwischen den Rechner mit der normalen seriellen TTL-Schnittstelle (USB-seriell Wandler) und dem AVR mit dem gemeinsamen RXD/TXD Pin geschaltet wird. Die Schaltung verhindert, daß die vom Rechner gesendeten Daten an den eigenen Eingang der seriellen Schnittstelle zurückgeliefert wird. Damit ist keine spezielle Software erforderlich, die das Echo unterdrückt. Die ganze Entwicklung ist im subversion (SVN) Archiv des Transistortester Projekts (svn://www.mikrocontroller.net/transistortester) im Unterverzeichnis bootloaders abgelegt. Die PDF-Doku bootloader.pdf findet man im Unterverzeichnis bootloaders/Doku/german bzw. bootloaders/Doku/english . Bisher läuft die Makefile nur unter Linux, da einige Tools aus dem Linux-Werkzeugkasten benutzt werden, um die Lage des Bootloaders und die Fuse-Einstellungen automatisch abhängig vom gewählten Prozessor und der eigenes Größe zu ermitteln. Möglicherweise ist eine Benutzung unter Windows auch möglich, wenn Cygwin installiert ist.
:
Verschoben durch User
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.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.