ATtiny13A: Wo kommt der eine Takt her?

[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

[Bernd_Stein]

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.

Hast wahrscheinlich nicht sehen bzw. genau erkennen können was ich selbst da aufgezeichnet hatte. Es ging mir um diese Punktsituationen, wo dass Signal ( Data ) z.B. wieder weg ist und nun dass Latch aber zeitgleich mit der Übnahmeflanke für dass PINnx ebenfalls wieder weg ist.

Was wird da jetzt vom PINxn-D-Flip-Flop übernommen?

Wenn man dass Latch durch ein weiteres D-Flip-Flop mit negiertem Takteingang nehmen würde, wäre diese Situation eindeutig.

Jetzt kam mir die Idee, dass es evtl. erwünscht ist, dass das Signal länger als mindestens einen halben Takt sein sollte um als " erwünscht " zu gelten und somit Punkt links doch eher eine Null erkennt und Punkt rechts eher eine Eins ? Ach ich weiß auch nicht was die sich dabei gedacht haben.

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

Das lass ich mir später noch mal durch den Kopf gehen, jetzt ist erstmal der Kessel am Pfeifen


Bernd_Stein

[Searcher]

Hast wahrscheinlich nicht sehen bzw. genau erkennen können was ich selbst da aufgezeichnet hatte.

Weiß nicht genau. Die letzte Grafik ist bei den Handskizzen nicht lesbar. PNG Format ist meist besser als JPG bei Zeichnungen.

Es ging mir um diese Punktsituationen, wo dass Signal ( Data ) z.B. wieder weg ist und nun dass Latch aber zeitgleich mit der Übnahmeflanke für dass PINnx ebenfalls wieder weg ist.

Was wird da jetzt vom PINxn-D-Flip-Flop übernommen?

Ich bin mir wirklich nicht sicher, was Du meinst.

Vom PINxn-D-Flp-Flop wird das mit der positiven Übernahmeflanke übernommen, was zu dem Zeitpunkt am Latch Ausgang ausgegeben wird. Das, was da ausgegeben wird, ist ein halber Systemtakt lang im Latch gespeichert worden.

Es spielt also keine Rolle, ob das Signal (Data) zur positiven Übernahmeflanke für PINnx wieder weg ist, da es ja im Latch gespeichert ist. Um ein Signal zu erfassen, muß es bei einer fallenden Systemtaktflanke an PB1 anliegen, da dann im Latch gespeichert wird (am Ende des gestrichelten Bereichs in Fig. 10-3).

Da man von außen ja nicht unbedingt weiß, wann eine fallende Systemtaktflanke kommt, muß ein Signal mindestens einen Systemtakt lang anliegen damit es sicher bei einer fallenden Systemtaktflanke erwischt wird und das Latch es dann speichern kann.

Gruß
Searcher