[Bericht] Die unvollendete Nano Geschichte

Vor wenigen Tagen bekam ich Kontakt mit den "neuen" Nanos.

Es war, alles in allem, ein unbefriedigendes Erlebnis.

Arduino hat den Nano Bootloader ausgetauscht.
Das war eigentlich nicht schlimm. Aber das ganze Drumrum erscheint mir etwas befremdlich.

Erstmal die Vorteile des neuen Bootloaders:

• Falls man im Programm den WDT nutzt, verfing sich der alte Bootloader in einem WDT-Dauer-Reset-Loop. Denn ein Reset schaltet den WDT nicht aus, sondern setzt nur dessen Vorteiler auf den kleinstmöglichen Wert.
• Der neue Bootloader ist nur noch 1/4 so groß, es sollten also 1,5K mehr für Programme bereit stehen
• Doppelter Upload Speed
• Kürzere Verweildauer im Bootloader

Eigentlich ein guter Schritt in die richtige Richtung.

Leider ist dabei aber offensichtlich ein Missgeschick passiert:

Hi...., you are right, but the boards in production have been flashed with the old fuse setting, making the bootloader partition larger than needed (see arduino/Arduino@1cf34c8#commitcomment-27651798). So we can't change the maximum sketch size parameter without affecting the functionality on these boards, sorry.

Alle Nanos aus der aktuellen Produktion werden mit dem neuen Bootloader ausgeliefert, aber mit den alten Fuse Settings.
Damit ist Punkt 2 aus meiner Vorteilsliste hinfällig!
Wirklich schade!

Wir haben also ein lustiges Nano Durcheinander.

• Originale Nanos, in verschiedenen Konfigurationen
• China Nachbauten, in noch lustigeren Varianten

Ich bin gespannt, wie sich das weiter entwickeln wird!

Mein Vorgehen in der Sache:

• Alle Nanos, in meinem Zugriff, bekommen einen kleinen Aufkleber, um kenntlich zu machen, welche Variante man da gerade vor sich hat. z.B. Alte, "A", neue mit "N", für neu, und eigene mit "U" für UNO
• Alle Nanos, welche direkt über meinen Schreibtisch gehen, bekommen den UNO Bootloader per ISP eingepflanzt. Und einen kleinen Aufkleber mit einem großen "U" drauf. Ab dem Augenblick ist vor dem Upload eines neuen Programms immer der UNO als Ziel Board auszuwählen.

Denn ich gehe, über kurz oder lang, davon aus, dass die UNO Konfiguration irgendwann offiziell vollständig auf den Nano übertragen wird.

Für mich ist der Schritt, alle Nanos zum UNO zu machen, ok...
Und ihr wisst jetzt immerhin, wenn es klemmt, warum es klemmt.

Links:
bei Heise
Board Beschreibung

Danke für Deinen Bericht!

Fehler können passieren. Nur immer blöd, wenn eine riesen Produktion dahinter hängt und der daraus resultierende Rattenschwanz eine Behebung verhindert.
Auch hätte man den Nano bei solch signifikanten Änderungen ruhig umbenennen dürfen. Nano 1.1 oder irgendwas, was dem Anwender einen Anhaltspunkt gibt.

combie:
Für mich ist der Schritt, alle Nanos zum UNO zu machen, ok...

Demnach ist der UNO Bootloader bereits äquivalent zu dem "neuen" 2018er Nano Bootloader mit Optiboot und doppelter Baudrate?
Da ich den ATmega328p viel als SMD Variante verwende, würde ich dann ebenfalls flächendeckend, anstelle des "alten" Nano Bootloaders den des UNO verwenden.

Demnach ist der UNO Bootloader bereits äquivalent zu dem "neuen" 2018er Nano Bootloader mit Optiboot und doppelter Baudrate?

Soweit ich das in meiner boards.txt sehen kann, wird die gleiche Datei für den Bootloader verwendet. Sind also identisch.
Nur finden sich da die "falschen" Fusesettings und Speicherplatzangaben.

Hallo,

was ich nicht verstehe ist, warum wird überhaupt beim Bootloader zwischen Nano und Uno unterschieden? Ist doch der gleiche µC drauf.

Das wird wohl historische Gründe haben.

Und jetzt steht die Kuh auf dem Eis.

Danke für deine Analyse, die kommt gerade rechtzeitig. Hab bis jetzt nur mit Uno, Mega und ProMini gearbeitet und wollte bald mal einen Nano benutzten. Ist wohl doch nicht ganz so einfach....

Gruß

Scherheinz

Ach, im Grunde ist noch alles im grünen Bereich...

Man wählt den passenden Nano im Boards Menu, und es funktioniert.
Man darf nur nicht anfangen darüber nachzudenken.

Ist die Geschichte bei UNO R3 vs R4 nicht auch ein bisschen "kompliziert"?
Beim Uno R3 PDIP Ausführung (großer Chip) gibt es keine A6 und A7 (reine Analog Eingänge)
Beim Uno R3 mit dem QFP hat A6 und A7 aber nicht auf Pins
Beim Uno R4 ist das auf Pins geführt.

Gruß
DerDani

volvodani:
Ist die Geschichte bei UNO R3 vs R4 nicht auch ein bisschen "kompliziert"?
Beim Uno R3 PDIP Ausführung (großer Chip) gibt es keine A6 und A7 (reine Analog Eingänge)
Beim Uno R3 mit dem QFP hat A6 und A7 aber nicht auf Pins
Beim Uno R4 ist das auf Pins geführt.

Ich glaube das darfst nicht alles vermischen. Original Arduino UNO egal ob µC im DIP oder TQFP Gehäuse ist immer 100% Code kompatibel und Shield kompatibel. Ob die beiden zusätzlichen Pins vom 32pin Gehäuse rausgführt sind oder nicht. UNO R3 bleibt UNO R3. Man darf es nicht komplizierter machen wie es ist.
Der UNO R4 ist nicht von Arduino! Der ist von Elektor in Eigenregie entstanden.
Dort ist kein 328P sondern ein 328PB drauf. Der ist auch nicht Pin kompatibel.

Tipp:

Man kann das Nano Board Menue um einen Eintrag erweitern.

Dazu muss man die betreffende boards.txt suchen.

Bei mir in:

E:\Programme\arduino\portable\packages\arduino\hardware\avr\1.6.21\board 
s.txt

Ansonsten in:

%AppData%\Local\Arduino15\packages\arduino\hardware\avr\1.6.21\boards.txt

Alternativ:
Bei ausführlichen Meldungen zeigt einem die IDE, beim kompilieren, welche boards.txt sie verwendet.

Neben diese boards.txt legt man eine boards.local.txt mit folgendem Inhalt:

nano.menu.cpu.atmega328fullmem=ATmega328P (UNO Bootloader full Mem)

nano.menu.cpu.atmega328fullmem.upload.maximum_size=32256
nano.menu.cpu.atmega328fullmem.upload.maximum_data_size=2048
nano.menu.cpu.atmega328fullmem.upload.speed=115200

nano.menu.cpu.atmega328fullmem.bootloader.low_fuses=0xFF
nano.menu.cpu.atmega328fullmem.bootloader.high_fuses=0xDE
nano.menu.cpu.atmega328fullmem.bootloader.extended_fuses=0xFD
nano.menu.cpu.atmega328fullmem.bootloader.file=optiboot/optiboot_atmega328.hex

nano.menu.cpu.atmega328fullmem.build.mcu=atmega328p

Ide neu starten.
Nano auswählen
Prozessor "ATmega328P (UNO Bootloader full Mem)" auswählen
ISP dran, und Bootloader brennen.

Jetzt ist der Nano voll UNO kompatibel, und kann dennoch als Nano im Menue gewählt werden.

Frage: die boards.local.txt liegt immer im Verzeichnis mit Versionsnummer? d.h. bei einem Boards-Update müsste diese dann wieder in das neuere Verzeichnis umziehen oder gäbe es einen Trick, diese trotz Update nicht angreifen zu müssen?

fast OT: Gibt's eigentlich irgendwo eine Beschreibung was man an den Einstellungen so ändern kann, ich würde mir gern das Leben leichter machen und die vielen (für mich unnützen) Boards eliminieren. Will das aber nicht bei jedem board-Update nachziehen müssen.

Frage: die boards.local.txt liegt immer im Verzeichnis mit Versionsnummer? d.h. bei einem Boards-Update müsste diese dann wieder in das neuere Verzeichnis umziehen oder gäbe es einen Trick, diese trotz Update nicht angreifen zu müssen?

Du könntest dir eine eigene Boarddefinition anlegen...
Klug gemacht, bekommst du alle Vorteile eines Backup (IDE+ToolChain) aber deine Boards ändern sich nicht.

Ein anderer Trick fällt mir nicht ein.

Gibt's eigentlich irgendwo eine Beschreibung was man an den Einstellungen so ändern kann,

noch nicht fertig aber für ein paar Klicks in notepad++ schon ansehnlich...

boards_txt_neu.png702×767 44.6 KB

endlich keine Irrtümer beim NodeMCU 0.9 oder Mega ADK mehr, kein runterscrollen mehr ... fein
Beim googeln dann auch noch etwas für den Sonoff gefunden. Cool.

danke combie.

Schön, dass ich (irgendwie) helfen konnte....

Nachtrag:
Hier befindet sich auch eine Boardsmenü Überarbeitung, welche den Vorteil hat, dass die originalen Dateien nicht verändert werden müssen.