Interner Takt

[P. F. (pfuhsy)]

Hallo,

ich beschäftige mich schon seit längeren mit den µC. Jetzt hab ich mal 
testweise mein Ossi an ein Port gelegt welches einfach nur im Takt 
wechselt.
Wie kann das sein das der µC (ATtiny13) mit eingestelltem internen Takt 
von 128kHz einen Takt von 20kHz messe und bei einen eingestellten Wert 
von 9,6MHz,  1,5 MHz ? Hab ich ein Denkfehler ? Das sind doch keine 
Toleranzen !

[Torsten C. (torsten_c)]

Peter F. schrieb:
> einen Takt ... messe

An welchem Pin?

[spess53 (Gast)]

Hi

>Das sind doch keine Toleranzen !

Mit welchem Programm?

MfG Spess

[P. F. (pfuhsy)]

Ich messe an den Port wo die LED hängt.

[Rufus Τ. F. (rufus)]

Und was bringt den Port dazu, "im Takt zu wechseln"?

Läuft da vielleicht ein Programm, das den Port hin- und herschaltet?

[holger (Gast)]

>Wie kann das sein das der µC (ATtiny13) mit eingestelltem internen Takt
>von 128kHz einen Takt von 20kHz messe und bei einen eingestellten Wert
>von 9,6MHz,  1,5 MHz ?

Das sind die Zeiten die deine Befehle brauchen um
ausgeführt zu werden. Jede Programmzeile verbraucht Zeit.

[P. F. (pfuhsy)]

Rufus Τ. Firefly schrieb:
> Und was bringt den Port dazu, "im Takt zu wechseln"?
>
> Läuft da vielleicht ein Programm, das den Port hin- und herschaltet?
Ja. Ganz einfach Programm in der Hauptschleifen, weölche den Port 
einschalten und direkt wieder ausschaltet.

Vielleicht hab ich nicht richtig ausgedrückt. Ich habe eigentlich 
erwartet, dass meine LED mit den eingestellten Wert blinkt (128kHz oder 
9,6MHz).

[holger (Gast)]

>Vielleicht hab ich nicht richtig ausgedrückt. Ich habe eigentlich
>erwartet, dass meine LED mit den eingestellten Wert blinkt (128kHz oder
>9,6MHz).

Dann dürfte dein CPU pro Befehl genau 0 Zeit verbrauchen.
Das heisst sie ist unendlich schnell. Da liegst du aber
ganz weit daneben.

[P. F. (pfuhsy)]

Ist das falsch wenn ich denke ?
1. Programmzeile (ca. 7,8µs, bei 128kHz)
2. Programmzeile weitere 7,8µs
usw.

[Michael K. (Gast)]

Peter F. schrieb:
> Ich habe eigentlich
> erwartet

Dann schau Dir das compilierte ASM Listing an, schnapp Dir das 
Datenblatt und schreibe mal hinter jeden ASM Befehl der ausgeführt wird 
die Taktzyklen die der zur Abarbeitung braucht. Du wirst sehen das Du 
auf die reale Frequenz kommst.
Deine Vorstellung von den Abläufen in der MCU ist defekt und nicht der 
Oszillator.

[P. F. (pfuhsy)]

Ok. Dann heißt das im umkehrschluss, dass ich auch keinen "vollen" Takt 
am Port erwarten kann.

[holger (Gast)]

>Ok. Dann heißt das im umkehrschluss, dass ich auch keinen "vollen" Takt
>am Port erwarten kann.

Richtig.

[Peter II (Gast)]

Peter F. schrieb:
> Ok. Dann heißt das im umkehrschluss, dass ich auch keinen "vollen" Takt
> am Port erwarten kann.

wenn überhaupt dann maximal den halben Takt. Denn in einem Takt kann ja 
nur ein Befehl abgearbeitet werden. Und mit einem Befehl kann man nicht 
einen Kompletten Takt ausgeben.

[P. F. (pfuhsy)]

Ok danke.
Ich werde mir das ganze bei Gelegenheit mal als Assembler angucken.

[Rufus Τ. F. (rufus)]

Peter F. schrieb:
> Ja. Ganz einfach Programm in der Hauptschleifen, weölche den Port
> einschalten und direkt wieder ausschaltet.

In welcher Programmiersprache ist das geschrieben?

Quelltext?

[P. F. (pfuhsy)]

In C über AVR-Studio.

[spess53 (Gast)]

Hi

>Ist das falsch wenn ich denke ?
>1. Programmzeile (ca. 7,8µs, bei 128kHz)
>2. Programmzeile weitere 7,8µs
>usw.

Das gilt noch nicht einmal für Assembler, da ein Assemblerbefehl auch 2 
oder mehr Takte dauern kann. Und z.b in C kann eine Zeile auch mehrere 
Assemblerbefehle erzeugen.

MfG Spess

[Rufus Τ. F. (rufus)]

Peter F. schrieb:
> In C über AVR-Studio.

Würmer? Nase? Quelltext?

Und sieh Dir dann mal an, was Dein Compiler daraus für Assemblercode 
erzeugt.