Hallo zusammen, ich stehe vor einem Rätsel. Soweit ich das sehe, ist der Arduino Uno und Nano (mit 328p) hardwaremäßig identisch, außer dass beim Nano noch analoge Ausgänge mehr raus geführt sind. Wenn ich nun den Bootloader für den Uno brenne, wird als high fuse 0xDE (256 words) programmiert. Wenn ich den Nano brenne, wird stattdessen 0xDA (1024 words) gebrannt. Komischerweise wird aber bei beiden Vorgängen das identische Image gebrannt. Da kann doch was nicht stimmen? Wenn ich mir nun das Image anschaue, so fängt dieses bei 7E00 an. Daraus würde ich schließen, dass 0xDC (512 words) richtig wäre. Wie kann ich aus dem Image des Bootloaders den richtigen Bootvekor ermitteln und warum wird der beim Arduino unterschiedlich gesetzt, obwohl der Prozessor der gleiche ist? Ist das überhaupt korrekt so? Drauf gekommen bin ich dadurch, weil ein Sketch, der auf dem Uno läuft, auf dem Nano nicht läuft. Ich verwende aber gar keinen Analogpin, weshalb da ja kein Unterschied sein dürte. Der Sketch belegt auch nur 53%, bzw. 55% des Speichers, weshalb mir auch nicht klar ist, warum das mit der Bootloadergröße zusammen hängen soll.
Klaus W. schrieb: > Da kann doch was nicht stimmen? Doch, das stimmt alles! Eigentlich ein Dummes Versehen der Entwickler. Irgendwann haben sich sich entschieden, den Bootloader des UNO auch für den Nano einzusetzen. Haben dann aber vergessen die Fuses umzudrehen. Und Unmengen davon ausgeliefert. Doofe Situation. Unbereinigt. Ich habe mir so beholfen, dass ich das Nano Prozessor Menue der IDE um einen Eintrag "ATmega328P (New Bootloader full Mem)" erweitert habe. Dazu muss man neben die originale boards.txt Datei eine boards.local.txt anlegen, mit follgendem Inhalt:
1 | nano.menu.cpu.atmega328fullmem=ATmega328P (New Bootloader full Mem) |
2 | |
3 | nano.menu.cpu.atmega328fullmem.upload.maximum_size=32256 |
4 | nano.menu.cpu.atmega328fullmem.upload.maximum_data_size=2048 |
5 | nano.menu.cpu.atmega328fullmem.upload.speed=115200 |
6 | |
7 | nano.menu.cpu.atmega328fullmem.bootloader.low_fuses=0xFF |
8 | nano.menu.cpu.atmega328fullmem.bootloader.high_fuses=0xDE |
9 | nano.menu.cpu.atmega328fullmem.bootloader.extended_fuses=0xFD |
10 | nano.menu.cpu.atmega328fullmem.bootloader.file=optiboot/optiboot_atmega328.hex |
11 | |
12 | nano.menu.cpu.atmega328fullmem.build.mcu=atmega328p |
Mit dieser Magie erscheint der Menupunkt in der IDE. Beim Bootloader brennen wird der UNO Bootloader aufgespielt, und die Fuses gesetzt. Also: Im Menue Nano mit "New Bootloader full Mem" auswählen. Einmal Bootloder brennen, mit einem ISP Adapter Danach immer den Menuepunkt, bei diesem Nano wählen. Klaus W. schrieb: > Drauf gekommen bin ich dadurch, weil ein Sketch, der auf dem Uno läuft, > auf dem Nano nicht läuft. Ich verwende aber gar keinen Analogpin, > weshalb da ja kein Unterschied sein dürte. Der Sketch belegt auch nur > 53%, bzw. 55% des Speichers, weshalb mir auch nicht klar ist, warum das > mit der Bootloadergröße zusammen hängen soll. Das ist ein anderes Problem. Meine Glaskugel sagt: Du verwendest Pin 13 als Eingang.
Die beiden nutzen verschiedene Bootloader. Der Uno nutzt Optiboot und der Nano den alten AtmegaBoot (?). Soweit ich es noch im Kopf habe, ist der Optiboot etwas kompakter.
ufuf, dann könnte ich aber auch gleich den Eintrag für die Fuses ändern. Die Frage ist eher, welchen Sinn das hat dass die Fuses unterschiedlich sind? Wenn das ein Fehler der Programmierer ist, was ist dann richtig? Ich kann das Fusebit einfach ändern, dann läuft auch mein Sketch. Hat also nix mit Pin13 zu tun. Die Frage ist nur, wenn ich das Fusebit einfach ändere, kann es dann irgendwann Probleme geben, weil er des Bootloader selbst überschreibt? Die Frage die noch offen ist, wie ich den richtigen Fuse-Wert ermitteln kann, wenn ich nur das Image habe? Patrick, es wird exakt das gleiche Image gebrannt. Nur die Fuses unterscheiden sich.
Angehängte Dateien:
-
2018-10-10_175619.png
34 KB
Klaus W. schrieb: > Patrick, es wird exakt das gleiche Image gebrannt. Nur die Fuses > unterscheiden sich. LOL. Und BOOTRST?
:
Bearbeitet durch User
Klaus W. schrieb: > Die Frage ist eher, welchen Sinn das hat dass die Fuses unterschiedlich > sind? Habe ich versucht zu erklären.... Und nein, ich werde mich nicht an der Stelle für das Entwicklerteam rechtfertigen. Nimm es so, wie es ist... oder ... Klaus W. schrieb: > Die Frage ist nur, wenn ich das Fusebit > einfach ändere, kann es dann irgendwann Probleme geben, weil er des > Bootloader selbst überschreibt? Ich habe dir eine funktionierende Konfiguration gepostet. Ok, du magst sie nicht verwenden.... Auch gut.
Arduino Fanboy D. schrieb: > Klaus W. schrieb: >> Die Frage ist nur, wenn ich das Fusebit >> einfach ändere, kann es dann irgendwann Probleme geben, weil er des >> Bootloader selbst überschreibt? > Ich habe dir eine funktionierende Konfiguration gepostet. > Ok, du magst sie nicht verwenden.... > Auch gut. Ich will nicht einfach eine funktionierende Konfiguration, sondern ich will verstehen was ich da mache.
Dann muss ich meine Frage noch ein drittes Mal stellen: Wie kann ich den Startwert des Bootloaders/Fusebit aus dem Image erkennen? Wie ich oben ja schon geschrieben habe, sehe ich eine Diskrepanz zwischen ermitteltem Wert und offensichtlich richtigem Wert. Du schreibst, 0xDE sei richtig. Meine Beobachtung aus dem Image wäre 0xDC. Meinem Verständnis nach wäre bei 0xDE die Hälfte des Bootloaders VOR dem Einsprung. Wo liegt der Denkfehler? So ganz erschließt sich mir sowieso die Boot start address nicht. Diese liegt wohl dann bei 0x3F00. Im Hex des Images fängt dieser aber bei 0x7E00 an. Wo kommt der Unterschied her?
Klaus W. schrieb: > So ganz erschließt sich mir sowieso die Boot start address nicht. Diese > liegt wohl dann bei 0x3F00. Im Hex des Images fängt dieser aber bei > 0x7E00 an. Wo kommt der Unterschied her? Da ist kein Unterschied. Deine Zahlen sind falsch interpretiert. Deine 0x7E00 ist eine Byteadresse. Im Datenblatt werden Wortadressen (z.B. 0x3F00) genannt. Darum der doppelte Wert. Ansonsten: Du hast alles richtig erkannt. Und ich weiß auch nicht wie ich es dir erklären kann, ohne mich genauso oft zu wiederholen, wie du fragst. Also nochmal: Wie schon gesagt, ein Versehen der Entwickler. Sie haben einen Bock geschossen, und wir müssen damit leben, oder machen es richtig, sind dann aber nicht mehr kompatible mit dem Rest der (Arduino) Welt. Der Bootloader belegt nur den 1/2 konfigurierten Bereich. Der Der Bereich zwischen Einsprungpunkt und Bootloader wird beim Chip erase mit 0xffff gefüllt. Und dieses entspricht einem NOP Das führt dazu, dass obwohl der Einsprungspunkt, für den Bootloader, falsch ist, der Prozessor über die NOPs bis zum Bootloader läuft und dieser dann ausgeführt wird. Die Probleme beginnen böse zu werden, wenn das Programm so lang wird, dass es in den Bereich ragt. Um das zu verhindern, ist der upload.maximum_size des original Nano so klein eingestellt. Es bringt nichts die Einstellung zu verändern, ohne die Fuses anzupassen. Und genau das habe ich versucht dir zu zeigen.
Danke! Das war eine gute Erklärung. Jetzt hab ich es verstanden. Sogar wo mein Fehler lag. Dann noch eine Frage zu der Konfiguration des Arduino: Was bedeuten die Werte für maximum_size und maximum_data_size? maximum_size sieht ja nach der maximalen Größe des Sketches aus. Aber die 2048? und Gibt es einen besonderen Grund, weshalb Du eine neue Konfiguration gemacht und nicht die alte fehlerhafte abgeändert hast? Ich denke das dürfte auch gehen, oder führt das zu irgendwelchen Problemen?
Klaus W. schrieb: > maximum_data_size Das ist die RAM Größe. Damit die IDE schreien kann, wenn du zu viel davon verplemperst Klaus W. schrieb: > Gibt es einen besonderen Grund, weshalb Du eine neue Konfiguration > gemacht und nicht die alte fehlerhafte abgeändert hast? Ich denke das > dürfte auch gehen, oder führt das zu irgendwelchen Problemen? Warum soll ich die originalen Menüpunkte verfälschen, wenn ich doch problemlos einen neuen hinzufügen kann? Brichst du immer alle Brücken hinter dir ab, wenn du links abbiegst?
Arduino Fanboy D. schrieb: > Brichst du immer alle Brücken hinter dir ab, wenn du links abbiegst? Nein, nur beim abbiegen nach rechts.
Marc V. schrieb: > Nein, nur beim abbiegen nach rechts. Wieso willst du nach rechts abbiegen? Ich traue dir einen Haufen zu, aber das nicht.
Arduino Fanboy D. schrieb: > Brichst du immer alle Brücken hinter dir ab, wenn du links abbiegst? Nö, aber falsche Einträge berichtige ich. Falsch bringen sie mir eh nix.
Klaus W. schrieb: > Arduino Fanboy D. schrieb: > >> Brichst du immer alle Brücken hinter dir ab, wenn du links abbiegst? > > Nö, aber falsche Einträge berichtige ich. Falsch bringen sie mir eh nix. Es gibt verschiedene "falsch". Hier ist es falsch, einen Menüpunkt zu ändern. Es wäre richtig, den Arduinoentwicklern zu sagen, wie sie die Kuh vom Eis bekommen. Dann erledigt sich das Problem beim nächsten Update von selber.
Was mir zum Thema Bootloader auf AVRs einfällt: Ich liebe Kommandozeilen die mindestens 100 Zeichen lang sind. Besonders wenn ich sie eintipppen soll. Ein Leben ohne Bootloader ist vorstellbar aber sinnlos. (?)
Arduino Fanboy D. schrieb: > nano.menu.cpu.atmega328fullmem.upload.maximum_size=32256 Bist du sicher, daß das richtig ist? Der Bootloader hat eine Größe von 512 Words, was 1024 Byte entspricht.. Die maximale Upload-Size wäre dann 31744 Bytes-
Harry L. schrieb: > Arduino Fanboy D. schrieb: >> nano.menu.cpu.atmega328fullmem.upload.maximum_size=32256 > > Bist du sicher, daß das richtig ist? Naja, falls nicht, dann wäre das ja seit Anbeginn des Uno "falsch" (der natürlich exakt diese Werte nutzt). Das ist im Übrigen "meine" Methode - statt einer neuen "boards.local" wähle ich den "Uno" aus, schreibe den Bootloader auf den Nano, und verpasse diesem einen Aufkleber "Uno". Funktioniert seit langer Zeit eigentlich problemlos... [Optiboot-Doku bzw. Github sagt übrigens "512 bytes"] > Der Bootloader hat eine Größe von 512 Words, was 1024 Byte > entspricht.. > Die maximale Upload-Size wäre dann 31744 Bytes-
:
Bearbeitet durch User
Sorry....falsch gedacht. Lt. Fuses sind es tatsächlich 256 Words, und dann stimmt das so natürlich. Hatte nicht auf dem Schirm, daß der Bootloader tatsächlich so klein ist.
Jan L. schrieb: > Das ist im Übrigen "meine" Methode - statt einer neuen "boards.local" > wähle ich den "Uno" aus, schreibe den Bootloader auf den Nano, und > verpasse diesem einen Aufkleber "Uno". Ein durchaus gangbarer Weg! Nur dass man dann bei einem Nano den UNO wählen muss, scheint mir ein semantischer Bock zu sein. Aber immerhin "könnte" ein aufmerksamer Leser durch meinen Vorschlag mitbekommen haben, wie man die Boarddefinitionen erweitern/überschreiben kann, ohne die original Dateien zu verändern. Auch die platform.txt Einträge lassen sich über eine platform.local.txt erweitern/überschreiben. Damit kann man auch lustige Spielchen machen. Wie z.B: C++14 aktivieren Assembler Dump generieren float in printf(), scanf() usw aktivieren
Arduino Fanboy D. schrieb: > Jan L. schrieb: >> Das ist im Übrigen "meine" Methode - statt einer neuen "boards.local" >> wähle ich den "Uno" aus, schreibe den Bootloader auf den Nano, und >> verpasse diesem einen Aufkleber "Uno". > > Ein durchaus gangbarer Weg! > > Nur dass man dann bei einem Nano den UNO wählen muss, scheint mir ein > semantischer Bock zu sein. > Naja, halte ich hier aber für eher unerheblich - ich nehme einen so veränderten Nano aus der Kiste, und muss nun erkennen, dass er verändert ist. Deswegen der Bepper auf dem Nano. Steht einfach ‚Uno‘ drauf, das genügt bislang, dass der entsprechende Groschen fällt (‚Board in der IDE ändern‘). Der zusätzliche, ordentliche Nano-Eintrag in boards.local wählt sich ja auch nicht automatisch aus, sondern muss erinnert werden...
Arduino Fanboy D. schrieb: >> wähle ich den "Uno" aus, schreibe den Bootloader auf den Nano, und >> verpasse diesem einen Aufkleber "Uno". > Ein durchaus gangbarer Weg! > Nur dass man dann bei einem Nano den UNO wählen muss, scheint mir ein > semantischer Bock zu sein. Aus dem Grunde habe ich in der IDE einen neuen Eintrag gebaut "Nano Optiboot". Da gibt es ja auch einen Unterschied beim upload der SW, Nano 57.600, Uno / Nano-Optiboot 115.200 bps. Liefern die Chinesen eigentlich schon Nanos mit dem neuen Bootloader?
Manfred schrieb: > Aus dem Grunde habe ich in der IDE einen neuen Eintrag gebaut "Nano > Optiboot". Da gibt es ja auch einen Unterschied beim upload der SW, Nano > 57.600, Uno / Nano-Optiboot 115.200 bps. Was dann aber auch wieder von den Entwicklern blödsinn ist. Ist ja der gleiche Mikrocontroller. Macht dann ja gar keinen Sinn, unterschiedliche Baudraten zu verwenden. > Liefern die Chinesen eigentlich schon Nanos mit dem neuen Bootloader? Bei mir war gar nix drauf. Ich musste mir den Bootloader erstmal selbst drauf spielen.
Klaus W. schrieb: > Was dann aber auch wieder von den Entwicklern blödsinn ist. Das ist wohl der Historie geschuldet... (mit all ihren Irrtümern in der Vergangenheit)
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.