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 ?
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 !
Ä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.
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.
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.
> 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
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 !
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)