ich versuche, auf dem Arduino Uno R3 laufende Sketche an Attiny85 anzupassen. Klappt soweit. Vor ein paar Jahren habe ich das Gleiche mit demselben Uno und derselben Charge Attiny85 gemacht, und ich meine mich erinnern zu können, dass man den Bootloader nur ein einziges Mal brennen musste. Jetzt ist es so, dass der Upload eines Sketches ohne Neubrennen des Bootloaders nur geht, wenn man den unveränderten Sketch ein zweites Mal hochlädt, was natürlich wenig Sinn ergibt. Ändere ich auch nur eine Variable, kommt beim Hochladen folgende Meldung:
Der Sketch verwendet 2252 Bytes (29%) des Programmspeicherplatzes. Das Maximum sind 7616 Bytes.
Globale Variablen verwenden 32 Bytes (6%) des dynamischen Speichers, 480 Bytes für lokale Variablen verbleiben. Das Maximum sind 512 Bytes.
avrdude: verification error, first mismatch at byte 0x000a
0x24 != 0x36
avrdude: verification error; content mismatch
Fehlgeschlagenes Hochladen: Hochladefehler: exit status 1
Brenne ich dann den Bootloader neu, funktioniert es.
Ich benutze die IDE 2.3.1 auf Linux Mint und den Arduino Uno R3 als ISP. Der Bootloader ist "Optiboot". Ist der vielleicht nicht der Richtige? Blind probieren möchte ich nicht, weil ich nicht weiß, ob dabei die Attinys Schaden nehmen können. Wäre nett, wenn mir jemand in für Laien geeigneten Worten etwas dazu sagen könnte.
Wo finde ich die Core-Version?
Es passiert allerdings mit zwei Arduinos auf die gleiche Art. Einer ist ein genuiner Uno, der andere ein Clon namens M.J duino Uno R3.
Nein, an Avrdude Parametern habe ich nichts geändert. Wüsste gar nicht wo. Allerdings habe ich die IDE einmal wieder deinstalliert und neu installiert, ohne dass das etwas verändert hätte.
Ich habe gerade versucht, dein Problem nachzustellen, scheitere allerdings an der Installation des Cores. Die URL http://drazzy.com/package_drazzy.com_index.json leitet auf HTTPS um und verwendet dort ein ungültiges Zertifikat.
die zip-Datei heruntergeladen, entpackt, einen Ordner "hardware" im Sketch Ordner angelegt und die entpackte Datei dort hineinkopiert. Dann taucht sie im Boardmanager auf.
Bei der Arduino-App von Microsoft hat das allerdings nicht funktioniert. Ich rede hier von meinem Linuxrechner.
Also der Parameter "-D" ist dabei, wie Björn schrieb. Das muss dann wohl so sein.
Was ich mir noch vorstellen könnte ist, dass die Baudrate des ATtiny nicht genau genug mit dem USB-UART Adapter überein stimmt. Bei Verwendung des R/C Oszillators kommt das manchmal vor. Eventuell hilft es, die Versorgungsspannung auf 3,6V zu reduzieren oder am Chip für Zimmertemperatur zu sorgen (falls nicht bereits geschehen).
Also der Parameter "-D" ist dabei, wie Björn schrieb. Das muss dann wohl
so sein.
Ja, natürlich. Wäre unschön, wenn der gesamte Flash gelöscht werden würde. Hinweis: auch der Bootloader liegt im Flash...
Weil das so ist, funktioniert das nur so: der Bootloader löscht den Flash seitenweise, immer bevor er eine Seite beschreibt. Und er überschreibt sich natürlich selber nicht.
Übrigens wäre es auch recht ungewöhnlich, wenn ein Bootloader überhaupt so ein globales Löschkommando anbietet. Die Gefahr, das es versehentlich aufgerufen wird, wäre wohl zu hoch.
Was das eigentliche Problem betrifft: Zur Analyse der Problematik sollte der TO mal über ISP den Flash auslesen, und zwar nach dem zweiten (fehlgeschlagenen) Schreibversuch. Dieses Images und dazu die originalen Hexfiles der beiden Programmversionen dann mal hier hochladen.
Mit ein wenig Glück läßt sich aus dem Vergleich der drei Hexfiles auf die Fehlerursache schließen oder zumindest bestimmte mögliche Ursachen ausschließen.
Nun, die classic ATtiny haben keine Bootsektion, d.h. die Ausführung startet immer an Adresse 0x0000.
Um dennoch einen Bootloader zu implementieren, gibt es einen Trick. Der Bootloader schnappt sich den ersten Sprung von Adresse 0x0000 und packt ihn z.B. ans letzte Word der letzten Page unter dem Bootloader. An Adresse 0x0000 schreibt er stattdessen einen Sprung zu sich selber. Somit wird er immer zuerst ausgeführt.
Macht der Bootloader diesen Trick nicht, dann überschreibt er den Sprung mit der Applikation und ist danach nicht mehr erreichbar.
Daneben gibt es wohl noch die Möglichkeit, das durch ein spezielles Linkerscript machen zu lassen. D.h. die Applikation darf dann nur mit diesem Script gebaut werden. Dieses Script sollte daher in Optiboot dabei sein. Dieses Script muß auch an die Flashgröße des konkreten ATtiny angepaßt sein.
Weiterhin muß der Bootloader die Pages der Applikation immer absteigend löschen. Nur dann wird der Einsprung an 0x0000 als letztes gelöscht und ist somit sicher gegen einen Verbindungsabbruch (Stromausfall).
Nun, die classic ATtiny haben keine Bootsektion, d.h. die Ausführung
startet immer an Adresse 0x0000.
[...]
Macht der Bootloader diesen Trick nicht, dann überschreibt er den Sprung
mit der Applikation und ist danach nicht mehr erreichbar.
So weit ist das erstmal alles vollkommen richtig. Aber deine Schlussfolgerung ist es nicht.
Weiterhin muß der Bootloader die Pages der Applikation immer absteigend
löschen. Nur dann wird der Einsprung an 0x0000 als letztes gelöscht und
ist somit sicher gegen einen Verbindungsabbruch (Stromausfall).
Nein, er kann auch in ganz normaler Reihenfolge schreiben, muss eben nur "on the fly" patchen. Sprich: erste Page kommt vom Host, wird zum Backup-Ort geschrieben, Pageinhalt wird gepatched und dann an den eigentlichen Zielort geschrieben.
Die Sonderbehandlung für eine Page hat man immer drinne. Ob die als erstes oder letztes geschieht, ist egal.
Bezüglich des Problem des TO spielt diese ganze Problematik übrigens keine Rolle. Optiboot kann mit den Classic-Tinys durchaus korrekt umgehen. Außerdem würde der Mismatch-Fehler irgendwo auf Adresse 0..3 liegen, wenn dies hier das Problem wäre.
Optiboot kann mit den Classic-Tinys durchaus korrekt
umgehen.
Ich habe keine Beschreibung gefunden, wie der das macht. Für mich sieht er eher wie eine Black Box aus.
Aber irgendein Problem muß es ja geben, wenn er nur einmal funktioniert.
Heißt das, dass ein anderer Bootloader den beschriebenen Effekt
vermeiden würde? Welcher wäre dazu denn geeignet?
Wenn du einen Programmer hast, um einen Bootloader zu brennen, brauchst du doch keinen Bootloader mehr.
Ein Bootloader ist gedacht, um Arduinomodule über USB oder seriell ohne Programmer zu programmieren. Für pure Chips ist er sinnlos, verringert nur den Speicher.
Mit ATTinyCore kannst du "No Bootloader" wählen und mit Strg-shift-U das Programm hochladen.
Den Programmpunkt "Bootloader brennen" brauchtst du aber eventuell trotzdem einmal pro Chip, um über die Fuses den Takt einzustellen. Es ist eine Pseudofunktion, dabei werden nur die Fuses geschrieben, der Flashspeicher bleibt unberührt.
Und der allgemeine und auch hier vorliegende Anwendungsfall ist dann, daß man auf dem AVR gerne einen bootloader hätte, den man dann einmalig per Programmer drauf braten muß, weil halt ab Werk keiner drauf ist - was bei so gut wie allen AVRs der Fall ist. Die Maker-Sonderlocke "Arduino" ist nicht der Normalfall.
Und der allgemeine und auch hier vorliegende Anwendungsfall ist dann,
daß man auf dem AVR gerne einen bootloader hätte, den man dann einmalig
per Programmer drauf braten muß, weil halt ab Werk keiner drauf ist -
was bei so gut wie allen AVRs der Fall ist. Die Maker-Sonderlocke
"Arduino" ist nicht der Normalfall.
Oliver
Hat sich vielleicht in der Arduino-Szene noch nicht genug herumgesprochen, dass man Mikrochips auch ohne Bootloader programmieren kann. Und dass dazu nicht mehr gebraucht wird, als man braucht, um einen Bootloader neu zu brennen.
Auch die Arduinomodule ohne USB wie den Pro-Mini programmiere ich direkt ohne Bootloader. Zum Uploaden kurz zusätzlich die Umschalttaste zu drücken, ist ja kein merklicher Mehraufwand. Und man spart sich den ganzen Ärger mit den Inkompatibilitäten der Bootloader.
