takten von Mikroprozessoren

"Markus" :

Die meisten Mikrocontroller schon. Schau doch mal ins Datenblatt.

M.

Hallo,

nur die sogenannten vollstatischen die keinerlei dynamische Speicherelemente intern verwenden. Da müsste dann für die Frequenz die Angabe 0 bis x MHz im Datenblatt stehen, wenn da aber z.B. 2 bis 40 MHz steht kannst Du Dich unter 2 MHz auf nichts verlassen. Es gibt noch andere Gründe, früher brauchten die ICs noch -5 V von extern um das Substrat negativ vorzuspannen, heute wird diese Spannung mit einer Ladungspumpe intern erzeugt, wenn die Pumpe aber mit dem (runtergeteilten) Takt versorgt wird ist auch eine Mindestfrequenz erforderlich. Wenn intern ein schnellerer Takt durch Frequenzvervielfachung erzeugt wird kann auch ein zu langsamer externer Takt zum Versagen führen.

Bye

"Markus" schrieb

Theoretisch bei "statischen" Mikros schon.

Zum Messen der Ausführungszeit von "Rechnungen", (gemeint sind wohl Befehlssequenzen) ist die Methode Unsinn. Startest du dein Programm schon mit 0,1Hz Takt bist du evtl schon zu Staub zerfallen bis bis deine Rechnung an die Reihe kommt. Und den Takt über Portpins und Multiplexer umschalten wirst du nicht sauber hin bekommen. Machs einfach wie die anderen auch - Übersetze deine Rechnung in Assemblecode und schau im Datenblatt wieviel Zyklen jeder Befehl dann braucht - Addiere alles zusammen und multipliziere mit der Ausführungzeit eines Prozessorzyklus.

Gruß

Hans-Georg

"Hans-Georg Lehnard"

Das ist dann aber nur eine Schätzung, weil manche Assemblercodes parallel (zyklisch versetzt) laufen können und manche nicht. Dann muss man genau wissen, welche Assemblercodes mit welchen "überlappen" können und ehrlich gesagt, das würde ich nicht hinkriegen. Auch nicht mit dem besten Datenblatt.

Man kann ja z.B. nen 40 kHz Takt mit nem 4060 oder NE555 erzeugen und den dann für den Code den man testen möchte abklemmen das sollte ja wohl gehen, sofern der Oszillator nicht innerhalb der CPU ist.

Mir ging es weiterhin auch noch darum, ob man es mit einem VDO hinbekommen kann, dass man die Frequenz senkt, wenn die CPU weniger rechnen muss. Das müsste ja theoretisch gehen, weil der stromverbrauch ja geringfügig bei "sinnvoller" CPU aktivität steigt. Macht die CPU immer das gleiche (Warteschleife) singt der Stromverbrauch. Also müsste man damit doch über einen VDO die Frequenz regeln können um strom zu sparen... naja war nur so ein Gedanke...

MfG,

Markus

oder natürlich per Code über einen Analogen output. Ist die Frage was am leichtesten relisierbar ist. Kennt jemand VDO's mit denen man auch um die 11 MHz hinbekommt?

Markus schrieb:

Meinst du VCO -> voltage controlled oszillator ?

"Andreas Ruetten"

Ja. Ich kannte das bisher nur als VDO voltage dependant osc. Deine Variante scheint aber gebräuchlicher zu sein.

MfG,

Markus

Hi!

Besser:

• Wenn man einen I/O Pin frei hat, den Pin während der Routine auf 1 setzen. Dann kann man einfach mit einem Oszilloskop messen -- toll für Interruptlatenz, etc.

• Im Fall von Microcontrollern hat man meistens Timer, die mit dem vollem Prozessortakt laufen. Wenn einer frei ist, nimmt man den zum Messen.

• Aktuelle CPUs haben i.d.r. eingebaute Performance-Counter. Für x86 z.B. RDTSC, unter Windows nimmt man besser GetPerformanceCounter() / GetPerfomanceFrequency()

|> Das ist dann aber nur eine Schätzung, weil manche |> Assemblercodes parallel (zyklisch versetzt) laufen |> können und manche nicht. Dann muss man genau |> wissen, welche Assemblercodes mit welchen |> "überlappen" können und ehrlich gesagt, das würde |> ich nicht hinkriegen. Auch nicht mit dem besten Datenblatt.

Dazu gibts entweder Simulatoren oder bei "richtigen" Prozessoren Performance-Counter. Und für den Rest kann man auch Profiling machen. Das geht auch ohne Modifikation des Codes (statistisches Profiling, siehe oprofile).

Mein Kollege hat dafür einige "where am I?"-pins definiert, die permanent am logic analyzer auflaufen und immer ein nettes Bild geben, was "da drin" gerade abgeht.

Ralph A. Schmid, DK5RAS schrieb:

Mache ich bei CPLDs auch, "wenn geht". Vor allem, wenn man da etwas komplexere Statemachines drin implementiert. Kann man am Ende ja wieder rausschmeißen.

Ich muß auch gestehen, daß ich noch nie Software im eigentlichen Sinne debuggt habe, mein Debugging läuft meistens auf | #ifdef DEBUG | printf('jumped into routine xyz\n'); | #endif hinaus... ;-)

Gruß Henning

"Henning Paul"

wenn man immer ein Display dabeihat.. ^^

Am Sat, 25 Nov 2006 17:38:57 +0100 schrieb Markus:

Ein UART nimmt sowas auch dankbar an, beim debuggen sollte dann auch irgendwas zum anzeigen in Reichweite sein.

Wobei printf recht viel Overhead mitbringt, wenn man ihn nicht sowieso braucht. Einzelne Byteausgabe auf den seriellen Port geht aber auch bei MCs

Lutz

Lutz Schulze schrieb:

Das war jetzt auch allgemein gesprochen, beim Programmieren am PC ist es eben je nach Programmiersprache ein anderer Befehl. In C printf(), in Matlab disp(), whatever.

Ich wollte damit nur ausdrücken, daß ich keinen Debugger wie gdb o.ä.verwende.

Gruß Henning

Markus schrieb:

Ich verrate dir ein Geheimnis. Jeder elektronische Oszillator ist voltage dependent. Besonders dann, wenn das ungelegen kommt...