Forum: Mikrocontroller und Digitale Elektronik AVR128DA: fuse bits ändern


von S. Landolt (Gast)


Lesenswert?

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?

von Wilhelm M. (wimalopaan)


Lesenswert?

Wozu ein Programmiergerät für einen UPDI-µC. Ein USB/Seriell-Adapter und 
eine Diode reichen doch.

von Breitbildfan (Gast)


Lesenswert?

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

von S. Landolt (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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?

von Florian S. (sevenacids)


Lesenswert?

Die Header-Dateien geben nicht zufällig etwas Preis?

Edit: Grad geschaut, leider nicht.

: Bearbeitet durch User
von Florian S. (sevenacids)


Lesenswert?

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
von Wilhelm M. (wimalopaan)


Lesenswert?

Breitbildfan schrieb:
> Echt?! Die können wirklich seriell fehlende Kapitel in Datenblätter
> einfügen?

Wovon redest Du?

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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
von S. Landolt (Gast)


Lesenswert?

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.

von S. Landolt (Gast)


Lesenswert?

Florian S. schrieb:
> "The Fuse programming is identical to the EEPROM programming ...

So ist es - verbindlichen Dank!

von Florian S. (sevenacids)


Lesenswert?

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.

von S. Landolt (Gast)


Lesenswert?

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!

von c-hater (Gast)


Lesenswert?

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

von S. Landolt (Gast)


Angehängte Dateien:

Lesenswert?

> ... Temperaturgang ...
Siehe Anhang.
Vielleicht messe ich auch mal nach, aber für mich ist das ein 
nachgeordnetes Kriterium.

von c-hater (Gast)


Lesenswert?

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

Bitte 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
Noch kein Account? Hier anmelden.