Druckbare Version
Mal eine rein theoretische Überlegung:
Kann man für einen Atmega8 ein Programm entwerfen, welches in der Lage ist die (eigene) CPU Taktrate intern und selbständig zu ermitteln? Mit "intern und selbständig" meine ich, dass dabei kein externes Bauteil (bzw. Peripherie) als Hilfsmittel genutzt werden darf.
Gegenfrage: Kannst du in einem geschlossenen Raum ohne Fenster (und in den keine anderen Umwelteinflüsse wie Geräusche dringen) eine Aussage über die Tageszeit machen?
Nein.
Zur Zeitmessung (und eine Frequenzmessung ist eine Zeitmessung) benötigst du eine Referenz. Ohne Zusatzbeschaltung klappt das nicht.
mfG
Markus
Hei Mann. Was für eine schicke Frage! Erstens - rein theoretisch ist doch Käse, das mach doch erst Sinn, wenn es (*ggg*theoretisch*ggg*) auch wirklich ginge! Und ich bin schon sicher dass es geht, habs mal eben kurz überflogen (Datenblatt ATmega8A_8159D–AVR–02/11) - aber nicht in letzter Konsequenz ausgearbeitet.Zitat:
... rein theoretische ... die (eigene) CPU Taktrate intern und selbständig zu ermitteln ...
Lösungsansatz: Es gibt verschiedene Taktquellen im Controller die Du anzapfst oder installierst bzw. nicht anzapfst oder nicht installiert hast.
Setzen wir mal voraus, dass Du einen externen Quarz angehängt und gefused hast (ohne fuses is nix los !). Nun wird ein Timer initialisiert, wohl ohne prescaler. Der WDT wird initialisiert. Der Timer sollte mit der WDT-Dimensionierung so abgestimmt werden, dass er innerhalb eines WDT-Zyklus nicht überläuft. Der Timer sieht in der - weiter unten genannten EEPROM-Zelle nach, ob die leer ist - und wird >>nur dann<< auf "Stand-ins-EEPROM-schreiben" gestellt, wenn die Zelle leer ist.
Timer und WDT so schnell es geht hintereinander starten. Der Timerstand wird möglichst schnell in einem Loop ausgelesen und ins EEPROM geschrieben, wohl immer ins gleiche Register (das vorletzte oder so - das man später eh kaum mehr braucht - besser keins von den vorderen Plätzen und KEINESFALLS das erste).
Irgendwann schlägt der WDT zu - und dann kann der Timer nix mehr wegschreiben. Aus dem letzten Wert in der genannten EEPROM-Zelle - und den Auslegungswerten für den WDT bzw. Timer lässt sich mit einer gewissen Toleranz die CPU-Frequenz errechnen. Die Timerinitialisierung in Abhängigkeit von leerer oder geschriebener EEPROM-Zelle sichert den Zelleninhalt nach dem Messlauf für eine spätere Auswertung *ggg*.
Es ist eine ziemlich unpraktische Lösungsidee, sicher eher nur für den von Dir angedachten "theoretischen" Fall.
Schreib mal wenn Du das durchgedacht hast, ob Du ähnlicher Meinung bist.
Ja.Zitat:
Zitat von markusj
Dem würde ich nicht zustimmen. Viele µC haben z.B. den Watchdog Timer, der über eine festen internen Oszillator verfügt. Damit hast du eine Referenz.Zitat:
Zitat von markusj
Man könnte am Programmanfang einen Timer laufen lassen, der über den Watchdog gestoppt wird. Aus dem Timerwert kannst du dann die Systemclock ableiten.
Würde meiner Meinung reichen, ist im Moment aber nur eine theoretische Überlegung.
Edit: Oberallgeier war schneller. Es gibt übrigens auch den WDT Interrupt ohne Reset. Dann kannst du dir die ganze EEPROM Orgie sparen.
In gewissen Grenzen geht es: der Watchdog timer hat einen unabhängigen festen Takt. Es ließe sich also z.B. die Zeit bis zum Auftreten eines Watchdog Resets messen. Allerdings ist der Takt nicht besonders genau - das reicht also nur für eine Grobe Messung, um z.B. einen 8 MHz von einem 16 MHz Quarz zu unterscheiden.
Eine andere Möglichkeit wäre ggf. noch die Zeit für das Schreiben ins EEPROM - das wird aber auch nicht genauer, kommt aber ohne einen Reset aus, wäre also eher einfacher zu programmieren.
Au weia - das hatte ich ganz vergessen. Hatte leider WDT noch nie genutzt. Aber klar - sonst wäre der ja nur die allerletzte Möglichkeit und kein Sicherungsmittel.Zitat:
... Es gibt übrigens auch den WDT Interrupt ohne Reset ... die ganze EEPROM Orgie sparen ...
Danke für den Hinweis, for_ro.
Der Mega8 hat keinen WDT - Interrupt. Den gibt es erst bei den etwas neueren µCs.
Den Umweg über das EEPROM kann man sich aber trotzdem sparen, denn beim WDT Reset wird des RAM nicht zurück gesetzt.
Die Idee mit dem Watchdog ist gut, den hatte ich nicht berücksichtigt. Fraglich ist nur, ob der WDT zu Peripherie gehört ...
mfG
Markus
Zitat:
... kein externes Bauteil (bzw. Peripherie) als Hilfsmittel genutzt werden darf.
Zitat:
Zitat von markusj
Markus, vielleicht postest Du mal ein Bild von einem DEINER Controller. Ich gehe nämlich davon aus, dass keiner der hier verwendeten Controller irgendeine Art Auf- oder Anbau hätte, in dem der Watchdog sitzt. Vielleicht hast Du nen schwarzwälder Atmel-Clon, auf dem ein Holzhäuschen sitzt, in dems tickt und aus dem es bei abgelaufenem Watchdogtimer Kuckuck schreit?Zitat:
Zitat von markusj
......Anhang 25093
Geht nicht, der verdammte Vogel ist geflüchtet und ich muss ihn erst einfangen. Recht herzlichen Dank für den Lacher, YMMD.Zitat:
Zitat von oberallgeier
Btw, die Aussage kam nicht ganz ohne Grund: Alles jenseits des Prozessorkerns ist eigentlich Peripherie. Auch neben Timern und ADC eben auch der WDT. Siehe Überschrift "Peripheral Features" auf der ersten Seite des Datenblatts.
mfG
Markus
Hallo
Das ist aber doch zu pingelig, denn auch das Flash und das SRam sind nicht Teil der CPU und deshalb peripher:
Bild hier
(Blockbild des Mega32)
Ich denke, alles was innerhalb des Gehäuses sitzt gilt nach diesen Regeln:
"Mit "intern und selbständig" meine ich, dass dabei kein externes Bauteil (bzw. Peripherie) als Hilfsmittel genutzt werden darf."
Gruß
mic
Zitat:
... Alles jenseits des Prozessorkerns ist eigentlich Peripherie ...
Ach danke, spart mir Etwas. Aber der Ärmste hat sich sowieso ins Knie geschossen, sein(e) Controller(welt) ist ja äusserst seltsam - schon die Bonddrähte, ja sogar die Buspfade sind jenseits des Cores. Aber dieses Hin- und Her war mir eh schon zu flach geworden.Zitat:
Zitat von radbruch
Hallo!
@ rossir
Ohne Zeitreferenz ist Messung einer Frequenz unmöglich, also sinlose Diskussion über alles anderes, als die Messzeit. ;)
War selbst skeptisch, ob das geht. Sehe jetzt aber Möglichkeiten. Danke dafür!
Die Idee der Bestimmung durch Zeitmessung, besser Taktzyklenzählen beim EEPROM Schreiben finde ich gut.
Im Prinzip werden hier physikalische Sachverhalte, Konstanten oder Grenzen (bzw. Kenn- oder Produktionsgrößen) des Chips selbst genutzt!
Gibt es da noch mehr? Angefixt - die Hoffnungslosigkeit des Unterfangens ist jetzt verflogen - durch euren ersten Input fällt mir noch Folgendes ein:
1) Das Rauschen an analogen Eingängen.
2) Irgendwer hält ein Patent auf das Erzeugen von (echten) Zufallszahlen (nur wenige Bits pro Sekunde) aus dem Jitter zwischen der Taktfrequenz und intern Irgendwas. Hatte ich nicht so recht verstanden und hab den Link vergessen.
Man könnte evtl. als Zeitbasis für Frequenzmessung bekannte interne Propagationszeit nehmen, ist aber wegen Exemplarstreuung ungenau. ;)