Hallo Leute,
kann mir wer einen Tipp geben.
Problem: Ich habe ein Programm für einen ATTINY12 geschrieben, welches
auch gut läuft .... aber bei einigen Platinen habe ich das Problem das
das Programm nicht mehr in der vorgesehenen Geschwindigkeit abläuft da
sich die Frequenz des int. Oszillators geändert hat bzw. die
Programmierung verloren hat. Ich kann die Oszillatorfrequenz neu aus dem
Speicher lesen und programmieren .... dann läuft alles wieder für ca. 3
Monate bis 1/2 Jahr ... dann kommt der Fehler wieder.
Über zeitnahe Infos wäre ich sehr froh ;-)
Vielen Dank und Grüße aus Tirol von
Walter Lidschreiber
Walter Lidschreiber schrieb:> Ich kann die Oszillatorfrequenz neu aus dem> Speicher lesen und programmieren
Was meinst Du damit?
Da das bereits alles schon mal erklärt wurde, möchte ich auf diesen
Beitrag verweisen:
Beitrag "Re: DCC Decoder"
ATTiny12 und ATTiny15 sind betreffs Calibration des internen
RC-Oszillators identisch.
Die Routine, die ich zur Calibration von Tiny12 und Tiny15 verwendet
habe, sieht so aus:
1
RESET:
2
ser temp ;Referenzwert ($FF) für ungültiges Calbyte
3
ldi zl,low(flashend*2) ;Zeiger auf Flash-Ende (letzte Flash-Zelle Low,
4
ldi zh,high(flashend*2);da schreibt ATLEL und mein ISP-Programm das Calbyte hin)
5
lpm ;Calbyte vom Flash einlesen
6
cpse r0,temp ;Calbyte gültig (ungleich $FF)?
7
out osccal,r0 ;ja, Oszillator kalibrieren
Das damals verwendete Eigenbau-ISP-Programm las bei jedem "Brennen" das
(exemplarabhängige) Calibrationsbyte aus dem Signaturespace des AVRs
(siehe dazu die Tabelle "Low-voltage Serial Programming Instruction Set"
im Kapitel Memory Programming, Low-voltage Serial Downloading im
Datasheet des Tiny12 oder Tiny15) und legte es ins Low-Byte der letzten
Flash-Zelle. Dort wird es dann von der Calibrationsroutine (erster Block
der Reset-Routine) gefunden und in das Register OSCCAL eingetragen.
Modernere AVRs machen das beim Hardware-Reset automatisch.
...
Hallo Hannes,
kann ich dir meine Programmierung (Datei) mal schicken und Du "baust"
die
vin dir geschriebene RESET-Programmierung dort ein .... ein Freund hat
das Programm für mich geschrieben - dar hat aber keine Zeit (Lust) mehr
sich um das Problem zu kümmern. Bei mir steht in RESET natürlich etwas
anderes und ich möchte das Programm durch falsche Eingaben nicht
"zerstören" ;-) .... es läuft ja sonst einwandfrei !!
Gerne bin ich auch bereit die Arbeitsleistung zu bezahlen - ich brauche
dringend Hilfe !!
Mit lieben Grüßen aus Tirol - Walter Lidschreiber
Hallo Hannes,
kann ich dir meine Programmierung (Datei) mal schicken und Du "baust"
die von dir geschriebene RESET-Programmierung dort ein .... ein Freund
hat
das Programm für mich geschrieben - dar hat aber keine Zeit (Lust) mehr
sich um das Problem zu kümmern. Bei mir steht in RESET natürlich etwas
anderes und ich möchte das Programm durch falsche Eingaben nicht
"zerstören" ;-) .... es läuft ja sonst einwandfrei !!
Gerne bin ich auch bereit die Arbeitsleistung zu bezahlen - ich brauche
dringend Hilfe !!
Mit lieben Grüßen aus Tirol - Walter Lidschreiber
Sorry, Deine erste Anfrage hatte ich übersehen...
Walter Lidschreiber schrieb:> kann ich dir meine Programmierung (Datei) mal schicken und Du "baust"> die von dir geschriebene RESET-Programmierung dort ein ....
Das nützt Dir nichts, denn das ist nur die halbe Miete. Denn beim
Flashen des Controllers muss ja auch das individuelle Calibrationsbyte
aus dem Controller gelesen werden und ins Flash des Controllers
geschrieben werden, wo es meine Routine dann finden soll.
Wenn es sich um einen einzelnen Controller handelt und nicht um eine
Serie, bietet sich folgender einfache Weg an:
- Mittels ISP-Programm Calibrationsbyte des zu flashenden
Controllers auslesen
- In Reset-Routine des Programms (also hinter die Interrupt-
Sprungtabelle) zwei Programmzeilen einfügen:
1
ldi r16,$xx ;($xx ist das zuvor ermittelte Calibrationsbyte)
2
out osccal,r16 ;Wert in Calibrationsregister schreiben.
- Quelltext neu assemblieren (Build).
- Neu entstandene Hexdatei mittels ISP-Programm in Controller übertragen
(flashen).
Wenn ich das machen soll, dann brauche ich nicht nur den Quelltext,
sondern auch den zu flashenden Controller, denn es muss ja das
exemplarabhängige Calibrationsbyte aus dem Controller ausgelesen werden.
...
Hannes, weißt du wie gut der Oszillator der 12-er ist?
Ist das noch einer von den alten oder schon ein neuerer, der weniger
Temperatur-Drift hat.
Denn das hier
> dann läuft alles wieder für ca. 3 Monate bis 1/2 Jahr
klingt für mich schon verdächtig nach Sommer/Winter 'Betrieb'.
Dann hilft auf lange Sicht nur ein Quarz.
Hallo Hannes,
also wenn ich nun richtig verstanden habe:
1) mit ISP-Programm das Calibrationsbyte auslesen
2) dieses dann mit den 2 Programmzeilen in mein Programm
(in die Resetroutine) schreiben z.B. $34
3) Controller mit der neuen Datei programmieren
d.h. vor dem programmieren des Controllers muß ich jedesmal vorher das
Byte auslesen und implizieren !!!
Da gibt es keine Routine !! ...... lt. Beitrag "Re: DCC Decoder"
Ich muß nämlich ca. 100 Platinen programmieren und in Geräte einbauen
;-)
.... und jedes verwendete ATiny12 hat ein anderes Calibrationsbyte ;-(
Liebe Grüße von Walter aus Tirol
und vielen Dank für deine Mühen
Karl Heinz Buchegger schrieb:> Hannes, weißt du wie gut der Oszillator der 12-er ist?
Nicht gut, UART wüede ich damit ungern machen wollen.
> Ist das noch einer von den alten oder schon ein neuerer, der weniger> Temperatur-Drift hat.
Es ist der erste nach dem AT90S1200, also ein alter...
> Dann hilft auf lange Sicht nur ein Quarz.
Dann hat der Controller aber nur noch 3 nutzbare I/O-Pins.
Walter Lidschreiber schrieb:> d.h. vor dem programmieren des Controllers muß ich jedesmal vorher das> Byte auslesen und implizieren !!!
So ist das.
> Da gibt es keine Routine !! ...... lt. Beitrag "Re: DCC Decoder"
Nein, auf die High-Bytes im Signature-Space (da wo die Calibrationsbytes
stehen) kann nur ein (brauchbarer) Programmer zugreifen. Das Programm im
AVR hat darauf keinen Zugriff. Werksneue (calibrierbare) AVRs hatten das
Calibrationsbyte zusätzlich in der letzten EEPROM-Zelle und der letzten
Flash-Zelle (Low-Byte und High-Byte) gespeichert. Diese geht aber beim
Erase verloren. Dummerweise führen viele ISP-Programme vor jedem Flashen
Erase aus, was die Nutzung der vorbereiteten Calibration verhindert.
Und auf das (auch noch flüchtige) Register OSCCAL kann nur das Programm
im AVR zugreifen.
Meine Routine nahm das Calibrationsbyte aus dem Low-Byte der letzten
Flash-Zelle. Das ging aber nur, weil mein damals benutztes
Eigenbau-ISP-Programm (in QBASIC geschrieben) beim Flashen das
Calibrationsbyte aus dem Signaturespace des AVRs gelesen hat und in die
letzte Flash-Zelle (L und H) geschrieben hat. Der Programmer von
AVR-Studio kann das zwar auch, ist dabei aber recht
bedienerunfreundlich, da man die Adresse explizit (in Hex) angeben muss.
Ein Auswahlfeld mit "letzte Flash-Adresse" hätte die Sache vereinfacht.
>> Ich muß nämlich ca. 100 Platinen programmieren und in Geräte einbauen
Du kannst mir gerne den Quelltext schicken, damit ich meine Routine
einbaue. Du musst Dir aber trotzdem einen Weg suchen, wie Du Deinen
Programmer dazu bringst, die letzten beiden Bytes im Flash durch das
auszulesende exemplarabhängige Calibrationsbyte zu ersetzen.
Alternativ kann dazu auch die letzte EEPROM-Zelle genutzt werden. Dann
muss die Routine eben statt des Flash das EEP euslesen. Dazu muss aber
BOD (Brown Out Detect) aktiviert werden, da sonst das EEP vergesslich
werden kann.
> ;-)> .... und jedes verwendete ATiny12 hat ein anderes Calibrationsbyte ;-(
Das ist nunmal aufgrund der Fertigungstoleranzen so. ATtiny 12 und '15
mussten von Hand calibriert werden, ebenso ATMega8, '16, '32, ATTiny26,
wenn der interner Oszillator auf 2, 4 oder 8 MHz eingestellt wurde. Die
automatische Calibration beim Reset funktionierte nur für 1 MHz.
Man sollte aber beachten, dass Tiny12 und Tiny15 obsolet sind. Die
Nachfolger Tiny13 und Tiny25/45/85 haben bedeutend bessere Eigenschaften
und müssen auch nicht mehr von Hand calibriert werden. Vielleicht kann
Deine Software ja auf Tiny13 umgestellt werden.
...
@ Walter Lidschreiber
Hallo!
Leider kennen wir Deine Anwendung nicht. Eine "Selbstjusierung" kommt
wohl nicht in Frage? Bei vielen UART-Anwendungen sieht man
Auto-Baud-Funktionen. Kann sich Dein Tiny z.B. beim Einschalten aus
irgend einem externes Signal seinen eigenen Takt ausrechnen, und sich
dann selbst das Calibration-byte ermitteln?
