Forum: Mikrocontroller und Digitale Elektronik Clock - Kalibrierung bei Padauk PFS154


von Ralph S. (jjflash)


Lesenswert?

Ich werkel schon eine kleine Zeitlang immer wieder einmal an einem 
eigenen PFS-154 Programmer auf ATMegaxx8 Basis, der auch mittels 
absoluten Hobby-Bastelmaterialien aufbaubar sein soll.

Nun funktioniert das Flashen des Chips endlich stabil da stellt sich mir 
ein Problem (wieder einmal eines), das für mich unerwartet war.

Grundsätzlich hatte ich in meinem mir eigenene "Lastenheft" festgelegt 
gehabt, dass ich keine Clock-Kalibrierung wie der hervoragende 
EasyPdkProgrammer machen werde (schlicht weil ich den Aufwand dafür 
scheue und ich für "Basteleien" eine Taktabweichung von +-2,5% für 
akzeptabel halte).

Nun verstehe ich im Datenblatt grundsätzlich etwas nicht so ganz:
1
The program code for IHRC frequency calibration is executed only one time that occurs in writing the codes into MTP memory; after then, it will not be executed again.

;-) meine Englischkenntnisse sind halt nur Schulkenntnisse von vor 40 
Jahren: Interpretiere ich das so, dass der Kalibrierwert nur ein 
einziges mal geschrieben werden kann, oder heißt das, dass nach dem 
Start des Controllers der Wert von dort nur während der Laufzeit ein 
einziges mal ausgeführt werden kann?

--------------------------------------

Mein grundsätzliches Problem ist: Wenn ich ein Programm mit 
Autokonfiguration geschrieben habe und mit "EasyPDKProgrammer" geflasht 
habe (Auto Clock calibrate), stimmt der Takt bei Flashen des Codes mit 
meinem eigenen AVR-Programmer nicht:

Ein ==> CLKMD= 0x34 <=== sollte als Taktfrequenz dann eigentlich 8 MHz 
haben ( 16 MHz / 2 ), hat es aber nicht (wenn ich einen I/O Pin frei 
togglen lasse, schwingt dieser bei Programmierung mit meinem Programmer 
so ziemlich genau auf der hälfte der Taktfrequenz wie beim 
EasyPdkProgrammer).

---------------------------------------

Für mich ärgerlich, weil endlich endlich endlich der Code zuverlässig 
durch meinen eigenen Programmer geflasht werden kann.

Welchen Code muß ich einfügen (evtl. auch im Sourcecode des 
Controllerprogramms), damit der bei "SET IHRC / 2" auch tatsächlich mit 
8 MHz schwingt ?

von Ralph S. (jjflash)


Lesenswert?

Wie das immer so ist: nachdem ich einen Post hier abgesetzt habe.... und 
dann weiter "forsche" komme ich oft doch auf das Ergebnis:

      IHRCR = GET_FACTORY_IHRCR();

... und das ganze dann alternativ aufrufend, ob man eine 
Autocalibrierung durch den easypdkprogrammer haben mag oder eben nicht !

von W.S. (Gast)


Lesenswert?

Ähem....

nein, ganz so ist das nicht.

Also, diese Dinger werden nicht ab Werk kalibriert. Das als 
Ausgangspunkt.
Wenn man den Takt dieser Chips kalibrieren will, dann braucht es dafür 
ein Gerät, was den gerade erzeugten Takt mit einer Referenz vergleicht. 
Der Chip selber kann das aus sich heraus nicht. Ist ja nicht Baron 
Münchhausen mit seinem Zopf.

Das hat eine Konsequenz:
Wenn man irgend eine Taktkalibrierung vorsehen will, dann muß man in der 
Firmware irgend etwas vorsehen, das dazu benötigt wird. Soweit ich das 
bisher gelesen habe, geht das etwa so:
Ab Adresse 0:
   Kalibrierwert laden
   Kalibrierwert in's Hardware-Register schreiben
   CALL eine Testroutine am Ende des Programmbereiches
   GOTO zum eigentlichen Programmanfang
ab da kommt dann wohl die Interruptroutine

Und in besagter Testroutine muß man dann mit irgend einem Pin wackeln, 
so daß man damit von außen die zugrundeliegende Taktfrequenz messen 
kann. Dann kann man nämlich den allerersten Maschinenbefehl 
überprogrammieren und aus dem 3. Maschinenbefehl ein NOP machen. Das 
war's dann. Als Startpunkt nimmt man zuerst 255 als Kalibrierwert, weil 
man diesen dann beliebig reduzieren kann.

So. Eine derartige Routine zum Testen muß natürlich zum Programmer und 
dessen Meß-Routinen passen, sonst wird das nix. Folglich müßte man 
eigentlich für alle Projekte einen einheitlichen Startupcode bzw. 
Assembler-Rahmen-Code verwenden. Und all dieses bedarf eigentlich 
einer sauberen Dokumentation, damit sich alle drauf verlassen können. 
Und die hab ich bislang noch nicht gesehen.

Frage: hast du denn dein Projekt oder wenigstens deine Algorithmen und 
die Schnittstelle zum PC hin dokumentiert?

W.S.

von Name (Gast)


Lesenswert?

Beim PFS154 und PFS173 gibt es einen Trimwert für die Clock, der im 
Flash abgelegt wird und dann per RCALL ausgelesen werden kann. Das macht 
"IHRCR = GET_FACTORY_IHRCR();".

Wie genau das ist, und für welche Betriebsspannung dieser ausgelegt ist, 
weiss ich nicht.

von W.S. (Gast)


Lesenswert?

Name schrieb:
> Beim PFS154 und PFS173 gibt es einen Trimwert für die Clock, der im
> Flash abgelegt wird

Und wer bittesehr hat diesen Wert dort abgelegt? Normalerweise hat das 
niemand, es sei denn, irgendwer hat diesen Chip bereits mal programmiert 
und bei dieser Gelegenheit auch den korrekten Trimmwert ermittelt.

W.S.

von bingo (Gast)


Lesenswert?

> Beim PFS154 und PFS173 gibt es einen Trimwert für die Clock

erinnert mich an den OSCCAL-Wert vom PIC12F675/-83 etc, der lag an der 
letzten Adresse des Flash

von Ralph S. (jjflash)


Lesenswert?

W.S. schrieb:
> Ähem....
>
> nein, ganz so ist das nicht.
>
> Also, diese Dinger werden nicht ab Werk kalibriert. Das als
> Ausgangspunkt.
> Wenn man den Takt dieser Chips kalibrieren will, dann braucht es dafür
> ein Gerät, was den gerade erzeugten Takt mit einer Referenz vergleicht.

Sag mal, du hälst mich wohl wirklich für absolut bescheuert und dämlich, 
oder? Zumindest stellst du nicht nur mich, sondern andere auch (und zwar 
permanent so hin).

Wortklaubereien nutzen da auch nichts. Natürlich ist das Ding nicht im 
Werk kalibriert worde, aber es hat einen Standardwert für JEDEN Chip 
gleich, egal aus welcher Charge der stammt und nach dem richtet sich 
JEDER dieser Chip. Das Datenblatt nennt das eben "factory calibrated" 
obschon die da garantiert nichts kalibriert haben. Die Dinger die ich 
getestet habe, lagen alle im Bereich ca. 1,5% zu langsam bei 
Zimmertemperatur.

Dass man für ein kalibrieren ein Gerät braucht weiß ich selbst und gerne 
wird das gegen den USB-Takt gemessen, weil ich aber mit einer USB2UART 
Bridge die Kommunikation herstelle geht das nicht. Punkt. Muß man also 
bei dem Billigprogrammer mit der Abweichung leben.

W.S. schrieb:
> Frage: hast du denn dein Projekt oder wenigstens deine Algorithmen und
> die Schnittstelle zum PC hin dokumentiert?

Für wen? Für dich? Du bist der einzige der danach fragt. Würdest du dir 
den Code anschauen wüßtest du sehr schnell wie da ausschaut, ich 
schreibe "sprechenden" Code.

Mir scheint so, als ob du eine Ausrede brauchst warum von dir seit 
Ewigkeiten nichts neues zu sehen ist: Es gibt ja keine Doku. Prinzipiell 
ist alles Dokumentiert und Kommentare in Quellcodes sind auch Doku. 
Ansonsten heißt so was recherche.

Im übrigen habe ich hier tonnenweise Dokumentation von meinen Projekten 
die nicht fertig geschrieben sind weil ich das nächste Projekt angehe.

Für dich jetzt : Programmer erwartet Zeichen "P" ... das ist für ihn der 
Start dass Programmiert werden soll, danach liest er die ID aus und 
sendet diese als Hex-Ascii Zeichen an den Host, dieser schickt dem 
Programmer dann die Anzahl zu flashender Bytes. Die Bytes werden in 
Blöcken versendet, von daher muß die Anzahl der Blöcke im Hostprogramm 
und im Programmer gleich sein.

"R" schaltet die Versorgungsspannung am Target ein (und startet dieses 
somit), "r" schaltet die Versorgungsspannung aus.

Das Hostprogramm basiert in Teilen noch aus meinen Anfängen zu CP/M 
Zeiten was man dem auch ansieht, aber es funktioniert ! Punkt !

Im Übrigen: für was benötigst du eine Doku? Du zerlegst doch eh jede 
Programmzeile von jedem schreibenden Mitglied des µC Forums, von daher 
wird dir doch sowieso alles schnell ersichtlich !

von Ralph S. (jjflash)


Lesenswert?

Name schrieb:
> "IHRCR = GET_FACTORY_IHRCR();".

Das ist genau der Wert, den alle nagelneuen Teile gleich haben... 
ausgemessen (leider nur 7 Stück) alle zwischen 1 bis 1.5% bei V_dd= 5V 
und Zimmertemperatur unter Sollwert! (smile, in China ist anscheinend 
wärmer)

von Ralph S. (jjflash)


Lesenswert?

Nachtrag: UART-Protokoll: 8N1 115200 Bd

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.