Announcement: there is an English version of this forum on Ich wollte mein Selbstbauprogrammiergerät um die Funktionen für den AVR128DA28 erweitern, komme jetzt aber bei den Fuses nicht weiter. Im 'Preliminary Data Sheet' sind die betreffenden Passagen, wie sie z.B. für die 'megaAVR® 0-series' normal dastehen, nicht zu finden, es fehlt also im Kapitel NVMCTRL ein Absatz 'Fuse Write Command' sowie für NVMCTRL.CTRLA in der Tabelle ein Eintrag der Art "WFU Write fuse (only accessible through UPDI)". Übersehe ich da etwas und/oder weiß jemand mehr?
Wozu ein Programmiergerät für einen UPDI-µC. Ein USB/Seriell-Adapter und eine Diode reichen doch.
Wilhelm M. schrieb: > Wozu ein Programmiergerät für einen UPDI-µC. Weil er es schon hat und erweitern will. > Ein USB/Seriell-Adapter und > eine Diode reichen doch. Echt?! Die können wirklich seriell fehlende Kapitel in Datenblätter einfügen? Merke: Wer Antworten auf nie gestellte Fragen gibt, muß auch in der Lage sein, Fragen zu seinem Stuß zu beantworten. SCNR
Ja, in der Tat: ich will bei diesem, über viele Jahre gewachsenen Gerät bleiben, zumal es durch einfachen Tastendruck zwei Controller programmieren kann. Auch lassen sich komplexe Abläufe wie z.B. Frequenzabgleich im Zielsystem einfach ergänzen. Den Aufwand, eine zweite Bedienebene zu installieren, zu erlernen und dann zu handhaben, erspare ich mir. Bei dieser Gelegenheit möchte ich aber auf die Eingangsfrage verweisen, die ist leider noch immer offen.
S. Landolt schrieb: > Ich wollte mein Selbstbauprogrammiergerät um die Funktionen für den > AVR128DA28 erweitern Warum jetzt? Was spricht dagegen, einfach zu warten, bis es ein brauchbares Datenblatt gibt?
Die Header-Dateien geben nicht zufällig etwas Preis? Edit: Grad geschaut, leider nicht.
:
Bearbeitet durch User
Im Quellcode von pyupdi habe ich gerade gelesen, dass die Fuses beim DA EEPROM-basiert sind. (application.py, Zeile 434). Also EEWR benutzen? Edit: Steht auch im Datenblatt unter 10.3.2.2: "The Fuse programming is identical to the EEPROM programming, but it can be performed only via the UPDI interface."
:
Bearbeitet durch User
Breitbildfan schrieb: > Echt?! Die können wirklich seriell fehlende Kapitel in Datenblätter > einfügen? Wovon redest Du?
S. Landolt schrieb: > für die 'megaAVR® 0-series' normal dastehen, nicht zu finden, es fehlt > also im Kapitel NVMCTRL ein Absatz 'Fuse Write Command' sowie für > NVMCTRL.CTRLA in der Tabelle ein Eintrag der Art "WFU Write fuse (only > accessible through UPDI)". > Übersehe ich da etwas und/oder weiß jemand mehr? Habe es auch gesucht und nicht gefunden, es muss also ganz normal zu programmieren sein. Schau mal nach: Kapitel 7.2 - Memory Map und dann Kapitel 7.8 - Configuration and User Fuses So wie ich das verstanden habe, wird es wie NVM (z.B. USERROW) mit entsprechendem Offset programmiert.
:
Bearbeitet durch User
an c-hater: Ich habe fünf Stück hier vor mir und möchte damit arbeiten. an Marc V.: Diesbezüglich habe ich bereits einiges durchprobiert, ohne Erfolg; setze mich aber nochmals dran. an Florian S.: Dann werde ich es auch einmal in dieser Richtung versuchen. Erstmal vielen Dank an alle, die sich die Mühe machten zu antworten.
Florian S. schrieb:
> "The Fuse programming is identical to the EEPROM programming ...
So ist es - verbindlichen Dank!
S. Landolt schrieb: > Florian S. schrieb: >> "The Fuse programming is identical to the EEPROM programming ... > > So ist es - verbindlichen Dank! Kein Problem. Das Datenblatt könnte in der Hinsicht präziser sein, z.B. im Blockdiagramm zum Speicherlayout (10-1) wo es den Anschein erweckt, die Fuses gehörten weder zum Flash noch EEPROM. Ich schaue mir den AVR-DA auch gerade etwas näher an und wäre früher oder später vermutlich auf das gleiche Problem gestoßen.
an Florian S.: Nach zwei Jahrzehnten 'normaler' AVR8 und einem Jahr megaAVR® 0-series war ich darauf fixiert, Fuses müssten speziell angesprochen werden. AVR128DA28: die neuen Eigenschaften, laut Datenblatt, können sich sehen lassen; was man von den Errata leider nicht sagen kann. Aber, gemessen: interner RC-Oszillator bei 2.0 V 3.989 MHz, bei 5.0 V 3.991 MHz - gut!
S. Landolt schrieb: > Aber, > gemessen: interner RC-Oszillator bei 2.0 V 3.989 MHz, bei 5.0 V 3.991 > MHz - gut! Naja, die Abhängigkeit von der Spannung hatte schon Atmel bei den "neueren" alten Teilen ganz gut im Griff. Viel spannender wäre der Temperaturgang, ob sich da etwas Nennenswertes zum Positiven getan hat...
Angehängte Dateien:
-
RC_Oszillator.png
76 KB
> ... Temperaturgang ...
Siehe Anhang.
Vielleicht messe ich auch mal nach, aber für mich ist das ein
nachgeordnetes Kriterium.
S. Landolt schrieb: > Siehe Anhang. Das sieht doch gut aus. Deutlich besser als selbst bei "neuen" alten. > Vielleicht messe ich auch mal nach Naja, beim Messen sollte es ja mit einiger Wahrscheinlichkeit nochmal deutlich besser aussehen als im DB... DAS allerdings war auch früher schon so. Es ist eben nur so, dass man sich nicht auf das verlassen kann, was man an einem oder einigen wenigen Exemplaren misst...
Florian S. schrieb: > S. Landolt schrieb: >> Florian S. schrieb: >>> "The Fuse programming is identical to the EEPROM programming ... >> >> So ist es - verbindlichen Dank! > > Kein Problem. Das Datenblatt könnte in der Hinsicht präziser sein, z.B. > im Blockdiagramm zum Speicherlayout (10-1) wo es den Anschein erweckt, > die Fuses gehörten weder zum Flash noch EEPROM. Ich schaue mir den > AVR-DA auch gerade etwas näher an und wäre früher oder später vermutlich > auf das gleiche Problem gestoßen. Ja, das stimmt. Das Datenblatt ist nicht unbedingt das präziseste. Ich stand vor dem gleichen Problem und werde die Fuses als Eeprom Programmieren. Es hat funktioniert! :-)
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.