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