Go Down

Topic: [Bericht] Die unvollendete Nano Geschichte (Read 2378 times) previous topic - next topic

combie

Apr 19, 2018, 10:33 am Last Edit: Apr 19, 2018, 10:46 am by combie
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


Eigentlich ein guter Schritt in die richtige Richtung.

Leider ist dabei aber offensichtlich ein Missgeschick passiert:
Quote
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
Gefährlich, was Theorien aus Menschen machen können.
Schlimmer, was Menschen aus Theorien machen.

TriB

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.

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.

combie

#2
Apr 19, 2018, 11:27 am Last Edit: Apr 19, 2018, 11:33 am by combie
Quote
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.
Gefährlich, was Theorien aus Menschen machen können.
Schlimmer, was Menschen aus Theorien machen.

Doc_Arduino

Hallo,

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

Messschieber auslesen: http://forum.arduino.cc/index.php?topic=273445
EA-DOGM Display - Demos: http://forum.arduino.cc/index.php?topic=378279

combie

Das wird wohl historische Gründe haben.

Und jetzt steht die Kuh auf dem Eis.
Gefährlich, was Theorien aus Menschen machen können.
Schlimmer, was Menschen aus Theorien machen.

Scherheinz

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
Hier könnte ihre Werbung stehen

combie

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.
Gefährlich, was Theorien aus Menschen machen können.
Schlimmer, was Menschen aus Theorien machen.

volvodani

#7
Apr 20, 2018, 08:06 am Last Edit: Apr 20, 2018, 08:07 am by 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.

Gruß
DerDani
"Komm wir essen Opa!" - Satzzeichen retten Leben!

Doc_Arduino

#8
Apr 20, 2018, 11:13 am Last Edit: Apr 20, 2018, 11:13 am by Doc_Arduino
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.
Tschau
Doc Arduino '\0'

Messschieber auslesen: http://forum.arduino.cc/index.php?topic=273445
EA-DOGM Display - Demos: http://forum.arduino.cc/index.php?topic=378279

combie

#9
Jul 13, 2018, 01:36 pm Last Edit: Aug 18, 2019, 10:35 pm by combie
Tipp:

Man kann das Nano Board Menue um einen Eintrag erweitern.

Dazu muss man die betreffende boards.txt suchen.

Bei mir in:
Code: [Select]
E:\Programme\arduino\portable\packages\arduino\hardware\avr\1.6.21\board
s.txt


Ansonsten in:
Code: [Select]
%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:
Code: [Select]
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.
Gefährlich, was Theorien aus Menschen machen können.
Schlimmer, was Menschen aus Theorien machen.

noiasca

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.
how to react on postings:
- post helped: provide your final sketch, say thank you & give karma.
- post not understood: Ask as long as you understand the post
- post is off topic (or you think it is): Stay to your topic. Ask again.
- else: Ask again.

combie

Quote
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.


Quote
Gibt's eigentlich irgendwo eine Beschreibung was man an den Einstellungen so ändern kann,
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification
Gefährlich, was Theorien aus Menschen machen können.
Schlimmer, was Menschen aus Theorien machen.

noiasca

#12
Jul 13, 2018, 07:59 pm Last Edit: Jul 13, 2018, 08:03 pm by noiasca
noch nicht fertig aber für ein paar Klicks in notepad++ schon ansehnlich...



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.
how to react on postings:
- post helped: provide your final sketch, say thank you & give karma.
- post not understood: Ask as long as you understand the post
- post is off topic (or you think it is): Stay to your topic. Ask again.
- else: Ask again.

combie

#13
Jul 13, 2018, 08:17 pm Last Edit: Aug 24, 2020, 07:22 am by combie
Schön, dass ich (irgendwie) helfen konnte....
:smiley-mr-green:

--------

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

Gefährlich, was Theorien aus Menschen machen können.
Schlimmer, was Menschen aus Theorien machen.

Go Up