ATtiny13A: Wo kommt der eine Takt her?

[Bernd_Stein]

Hallo zusammen,

wieder habe ich ein Problem. Wo kommt der eine Takt her ?

Eins vorweg :

Theoretisch 4,8Mhz, praktisch ist der interne RC-Oszilator aber nur mit
3,2Mhz, bei meinem ATtiny13A, bei 5V und ca. 20°C unterwegs. Um dies
festzustellen, habe ich meinen üblichen Trick verwendet ( Endlosschleife
-> Pin toggeln und ausmessen )

Heißt: *Ein Takt sind ca. 312,500ns *

Bei dem LA-Ausschnitt ist zu sehen, dass die LED-Gelb ( PB2 ), 2,333µS
nach der steigenden Flanke von PB1 folgt.



Für mein daherhalten, erzeugt diese Codesequenz 4 oder 6 Takte, bis die
steigende Flanke von LED-Gelb kommt:

_main: sbis PINB,1 rjmp _main sbi LED_PORT,led.ge ;LED-Gelb einschalten ( TEST )################################################## #######################

6T wären 1,875µs. Bleiben also noch 458ns, was locker ein Takt ist.
Deshalb meine Frage : "Wo kommt der eine Takt her?"

; .include "Header.inc" ;Label und Werte Zuweisungen .include "Hardware.inc" ;Hardware Label Zuweisungen ; ;Programmstart nach RESET ( Interrupt Vektoren Tabelle ) ; .CSEG ;Was ab hier folgt kommt in den FLASH-Speicher .ORG $0000 ;Programm beginnt an der FLASH-Adresse 0x0000.. rjmp _reset ;..mit der RESET-Vektortabelle .include "IRQt13.inc" ;Restliche Interrupt Vektortabelle .ORG INT_VECTORS_SIZE ;Programmadresse nach den ganzen IRQ-Vektoren ; ;IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIII ;IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIII ;I Erstinitialisierungen ;IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIII ;IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIII ; _reset: ; ;Ports Erstkonfiguration ; sbi DDRB,led.pla ;PORT-Bit als Ausgang f. PLA-LED sbi DDRB,led.ora ;PORT-Bit als Ausgang f. SLEEP-LED sbi DDRB,led.ge ;PORT-Bit als Ausgang f. TEST-LED ; ;Variablen initialisieren ( r0-r31 haben unbestimmten Inhalt ) ; ; ;HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHH ;HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHH ;H Hauptprogrammschleife ;HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHH ;HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHH ; ;sbi PINB,led.pla ;Systemtakt -> Gemessene Frequenz..######################################## ############################## ;rjmp pc-1 ;..mal 8 nehmen ################################################## ####################### _test: cbi PORTB,led.ora ;LED-Orange einschalten sbi PORTB,led.ora ;LED Orange ausschalten ldi xl,8 clr b _main: sbis PINB,1 rjmp _main sbi LED_PORT,led.ge ;LED-Gelb einschalten ( TEST ) ################################################## ####################### cbi LED_PORT,led.ge ;LED-Gelb ausschalten ( TEST ) ################################################## ###################### _main_1: sbic PINB,1 rjmp _main_1 sbi LED_PORT,led.pla ;LED-PLA einschalten ( TEST ) ################################################## ####################### cbi LED_PORT,led.pla ;LED-PLA ausschalten ( TEST ) ################################################## ####################### ; ;Systemtakt ( 4,8MHz ) durch X teilen ; in a,CLKPR ;Clock Prescaler Register laden.. sbr a,1<<CLKPCE ;..Sicherheitsprozedur.. cbr a,1<CLKPS3|1<<CLKPS2|1<<CLKPS1|1<<CLKPS0;.. out CLKPR,a ;..durchfuehren.. ldi a,$7F ;..CLKPCE loeschen.. and a,b out CLKPR,a inc b cpse b,xl rjmp _main rjmp _test ; rjmp PC ;Endlosschleife .EXIT ;Ende des Quelltextes

Bernd_Stein

[Holomino]

Ich hätte ja jetzt gesagt: Das ist ein Fall für den Simulator, in dem man sowohl Takte, als auch Zeiten von solchen Codefragmenten recht verlässlich vermessen kann.

[Bernd_Stein]

Ich hätte ja jetzt gesagt: Das ist ein Fall für den Simulator, in dem man sowohl Takte, als auch Zeiten von solchen Codefragmenten recht verlässlich vermessen kann.

Welcher?

Der im Atmel Studio 7 ( AS7 ) ist nicht so ganz dafür zu gebrauchen. Habe mir extra die neuste Version heruntergeladen. Was da genau unrund läuft berichte ich mal später.


Bernd_Stein

[Searcher]

Wo kommt der eine Takt her ?
...
....
Heißt: *Ein Takt sind ca. 312,500ns *
...
Für mein daherhalten, erzeugt diese Codesequenz 4 oder 6 Takte, bis die
steigende Flanke von LED-Gelb kommt:

_main: sbis PINB,1 rjmp _main sbi LED_PORT,led.ge ;LED-Gelb einschalten ( TEST )################################################## #######################

Ablauf meiner Ansicht nach:
- steigende Flanke an PB1
- es dauert max. 1,5 Takte bis Status im PIN Register steht
( ww1.microchip.com/downloads/en/DeviceDoc/doc8126.pdf , 10.2.4 Reading the Pin Value )
- SBIS braucht einen Takt wenn PIN noch LOW ist
- RJMP braucht zwei Takte zum Springen nach _main
- Zwei Takte von SBIS wenn PIN jetzt high ist
- Zwei Takte von sbi LED_PORT,led.ge

1,5T + 1T + 2T + 2T + 2T = 8,5 Takte

worst case: 8,5T * 312,5ns = 2656,25ns

Gruß
Searcher

[Siro]

Hallo Bernd_Stein,

Ich prüfe auch immer als erstes ob meine CPU richtig läuft.
"Instruction Cycle Time". Bei den vielen Einstellungen in Registern liegt man gerne mal falsch.

Dazu toggle ich aber lediglich einen Pin 3 mal und dann kommt der Loop
So kann ich sicher gehen, dass innerhalb der 3 Signale kein Laufzeitverzögerungen/Takte usw. zusätzlich drin sind.
Mit dem Ossi schaue ich mir das Signal dann an. Normalerweise ergibt dies 3 symetrische Impulse
und dann folgt eine etwas längere Pause wegen dem Loop oder Jump.

loop:
Pin High
Pin Low
Pin High
Pin Low
Pin High
Pin Low
jump loop

Das der RC Oszillator derart daneben liegt kann ich mir kaum vorstellen,
statt 4,8 Mhz nur 3,2 Mhz ist eher unwahrscheinlich
Laut Datenblatt kann er 10 Prozent abweichen
somit läge die Frequenz bei 4,8-0,48 = 4,32 MHz
Dieser lässt sich aber noch kalibrieren.
Ob er dadurch dann derart verschoben werden kann bin ich mir aber nicht sicher.

Siro

[wkrug]

Ich weiss jetzt zwar nicht, ob der tiny 13 einen PWM Generator hat, wenn ja würde ich da mal eine vom Prozessortakt abhängige PWM ausgeben lassen.
Der Timer läuft unabhängig vom Prozessorkern und somit auch von Interrups und Kommando Taktzyklen.

Damit sollte sich eine qualifizierte Aussage über den Takt treffen lassen.

[Bernd_Stein]

@Searcher
Danke, jetzt sehe ich den Worst-Case-Fall ebenfalls so.

Ich überlege mir später den " Best-Case-Fall", also die kürzeste Ausführungszeit.

Mein ( ein ) Problem mit dem Simulator vom AS7 ist, dass beim Rücksetzen des Programmzählers am Breakpoint, der Befehl zwar ausgeführt wird, aber der PC diesen Befehl nicht mitzählt :



Edit: Die ist auch richtig, da der PC ja auf Null ist und somit erstmal nur " 1st Instruction Fetch " ausgeführt wird, aber in diesem Fall störend.

EDIT : -> Quatsch, der PC müsste gezählt werden, aber der Befehl nicht ausgeführt.

>>
Ich prüfe auch immer als erstes ob meine CPU richtig läuft.
"Instruction Cycle Time". Bei den vielen Einstellungen in Registern liegt man gerne mal falsch.

Dazu toggle ich aber lediglich einen Pin 3 mal und dann kommt der Loop
So kann ich sicher gehen, dass innerhalb der 3 Signale kein Laufzeitverzögerungen/Takte usw. zusätzlich drin sind.
Mit dem Ossi schaue ich mir das Signal dann an.
>>

@Siro
Ich mache es so ähnlich, deshalb die auskommentierte Codesequenz :

;sbi PINB,led.pla ;Systemtakt -> Gemessene Frequenz..########################
;rjmp pc-1 ;..mal 8 nehmen ########################


>>
Ich weiss jetzt zwar nicht, ob der tiny 13 einen PWM Generator hat, wenn ja würde ich da mal eine vom Prozessortakt abhängige PWM ausgeben lassen.
Der Timer läuft unabhängig vom Prozessorkern und somit auch von Interrups und Kommando Taktzyklen.

Damit sollte sich eine qualifizierte Aussage über den Takt treffen lassen.
>>

@wkrug
Halte dies für zu Aufwändig. Siehe Antwort zu @Siro

Sorry, für die Formatierung, habe jetzt aber keinen Bock da weiter herum zu experimentieren. Ein korreturversuch muss reichen.


Bernd_Stein

[Searcher]

Hallo Berd_Stein,

Ich hab mir den Ablauf nochmal durch den Kopf gehen lassen und meine, daß der worst case eigentlich nur 7,5T lang sein kann. Ich gehe dabei davon aus, daß der externe Pegel kurz nach fallender Flanke des System Clock, etwa bei Zeitpunkt "A" high wird. Das SBIS wird zum Zeitpunkt B ausgeführt. Da kann der Zustand noch nicht im PIN Register stehen sondern wird erst im Zeitpunkt C dort stehen.



Also zweiter Versuch zum Ablauf:
- steigende Flanke an PB1
- es dauert max. 1,5 Takte bis Status im PIN Register steht
( ww1.microchip.com/downloads/en/DeviceDoc/doc8126.pdf , 10.2.4 Reading the Pin Value )
- SBIS beginnt einen halben Systemtakt nach steigender Flanke an PB1 und braucht einen Takt wenn PIN noch LOW
- RJMP braucht zwei Takte zum Springen nach _main
- Zwei Takte von SBIS wenn PIN jetzt high ist
- Zwei Takte von SBI LED_PORT,led.ge

0,5T + 1T + 2T + 2T + 2T = 7,5 Takte

worst case: 7,5T * 312,5ns = 2343,75ns

In der vorherigen Rechnung bin ich davon ausgegangen, daß SBIS zum Zeitpunkt C ausgeführt wird. Da kann dann aber schon der "echte" Zustand von PB1 im PIN Register stehen und der RJMP zur _main wäre nicht nötig.

Gruß
Searcher

[Bernd_Stein]

Hallo Berd_Stein,

Ich hab mir den Ablauf nochmal durch den Kopf gehen lassen und meine, daß der worst case eigentlich nur 7,5T lang sein kann. Ich gehe dabei davon aus, daß der externe Pegel kurz nach fallender Flanke des System Clock, etwa bei Zeitpunkt "A" high wird. Das SBIS wird zum Zeitpunkt B ausgeführt. Da kann der Zustand noch nicht im PIN Register stehen sondern wird erst im Zeitpunkt C dort stehen.

Um so genauer man sich mit dieser Sache auseinandersetzt, um so verwirrender wird es für mich.
Ich sehe es leider nicht so für den Worst-Case-Fall, da du ja

1. zum Zeitpunkt A richtigerweise erstmal angenommen hattest, dass der Signalpegel low ist.

2. Ja, zum Zeitpunkt C wird sbis ausgeführt, aber sbi ja noch nicht.

3. Dein jetziges Szenario mit High-Pegel direkt nach der fallenden Flanke des Systemtaktes ist genau das, was im DB beschrieben ist und wir in Figure 10-3 zu sehen bekommen.

Was ich jedoch blöd gemacht finde, denn woher weiß den PINxn, dass es den Zustand erst einen Takt später vom LATCH übernehmen soll und nicht zeitgleich, wenn LATCH sich im tranparenten Abschnitt ( High-Phase des Systemtaktes ) befindet ?

In dieser Zeit ist ja D direkt an Q vorhanden und somit auch an D von PINxn.

Diese Frage kam mir auf, als ich selbst mal ein Signalverlauf aufgezeichnet habe und und nicht wusste wie sich jetzt PINxn verhält ( siehe Punkte ).
Ich habe jedoch den LATCH-Bereich straffiert, da ich den Transparentenbereich für irrelevant halte.



Ich Suche schon verzweifelt nach einem günstigen Bitmustergenerator ( pattern generator ), finde jedoch nichts günstiges ( um die 50€ ).


Bernd_Stein

[Searcher]

Was ich jedoch blöd gemacht finde, denn woher weiß den PINxn, dass es den Zustand erst einen Takt später vom LATCH übernehmen soll und nicht zeitgleich, wenn LATCH sich im tranparenten Abschnitt ( High-Phase des Systemtaktes ) befindet ?

Habe ich dem Text aus dem DB unter der Grafik entnommen. Latched wird bei fallender Flanke und ins PIN Register einen halben Takt später mit steigender Flanke geschrieben.

Consider the clock period starting shortly after the first falling edge of the system clock. The latch
is closed when the clock is low, and goes transparent when the clock is high, as indicated by the
shaded region of the “SYNC LATCH” signal. The signal value is latched when the system clock
goes low. It is clocked into the PINxn Register at the succeeding positive clock edge. As indicated by the two arrows tpd,max and tpd,min, a single signal transition on the pin will be delayed
between ½ and 1½ system clock period depending upon the time of assertion.

3. Dein jetziges Szenario mit High-Pegel direkt nach der fallenden Flanke des Systemtaktes ist genau das, was im DB beschrieben ist und wir in Figure 10-3 zu sehen bekommen.

Nicht ganz. Für den worst case muß der Einlesebefehl (in Figure 10-3 das in) bzw Abfragebefehl (dein SBIS) einen Systemtakt früher beginnen damit der "echte" PB1 Zustand noch nicht im PIN Register steht und ein RJMP ausgeführt wird. Der SBIS danach bekommt dann den echten PB1 Zustand, macht den SKIP und kann die LED einschalten.

Gruß
Searcher