ATtiny13A: Wo kommt der eine Takt her?

Zitat:

---

Zitat von Searcher

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.


Anhang 34940

Zitat:

---

Zitat von Searcher

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

Zitat:

---

Zitat von Bernd_Stein

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.

Zitat:

---

Zitat von Bernd_Stein

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

Zitat:

---

Zitat von Searcher

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).


Searcher

---

Es ist schon ein Elend mit diesen Foren. Da hat man mal einen kompetenten Schreiber der sich der Sache annimmt, dann taugt die Forensoftware leider nichts.
Man investiert eine menge Arbeit und aus dem Bild wird dann nur noch ein " Piktogramm ". Oder die Forensorftware ist Top, aber es nehmen nur Trolle an der Diskusion teil.

Also nochmal etwas anders :

Meines Wissens her, ist bei einem Latch im transparenten Teil, der Eingang gleich dem Ausgang ( D = Q ). Das Latch ist in der High-Phase des Systemtaktes transparent, also ab der steigenden Flanke bis zur fallenden Flanke des Systemtaktes.

Höchstwahrscheinlich ist dies wieder nur ein Prinzipschaltbild und dass PINxn-Register speichert mit der steigenden Flanke immer nur den gespreicherten Zustand des Latches und nicht den im transparenten Moment, oder es ist grundsätzlich so, dass ein Latch nicht so schnell vom Latch-Zustand in den Transparenten umschaltet wie ich es jetzt annehme.

Anhang 34943

Dass man ein Latch nimmt und nicht ein zweites D-FF mit negiertem Takteingang, muss irgend etwas damit zu tun haben, dass man versucht kurze Pegelwechsel auszublenden, wir aber nur ein Prinzipschaltbild zu sehen bekommen, wo dies nicht ersichtlich ist.

So, schicke dies erstmal los bevor noch was schiefgeht.


Bernd_Stein

Zitat:

---

Zitat von Bernd_Stein

Da hat man mal einen kompetenten Schreiber der sich der Sache annimmt,...

---

Kompetent? Na ja, ich bin auch nur Hobbyist und versuche in diesem Fall aus dem Datenblatt klug zu werden.

Zitat:

---

Meines Wissens her, ist bei einem Latch im transparenten Teil, der Eingang gleich dem Ausgang ( D = Q ). Das Latch ist in der High-Phase des Systemtaktes transparent, also ab der steigenden Flanke bis zur fallenden Flanke des Systemtaktes.

Höchstwahrscheinlich ist dies wieder nur ein Prinzipschaltbild und dass PINxn-Register speichert mit der steigenden Flanke immer nur den gespreicherten Zustand des Latches und nicht den im transparenten Moment, oder es ist grundsätzlich so, dass ein Latch nicht so schnell vom Latch-Zustand in den Transparenten umschaltet wie ich es jetzt annehme.

---

Ich glaube, so langsam komme ich dahinter was Du meinst:
- Die positive Systemtaktflanke leitet die transparente Phase des ersten Synchronizerlatches ein
- Eine positive Systemtaktflanke übernimmt aber auch den Ausgang des ersten Synchronizerlatches in das PIN-Flip-Flop.

Es könnte also sein, daß der Eingang mit positiver Systemtaktflanke transparent durch das Latch zum Eingang des PIN-Flip-Flop geht und auch gleich mit der gleichen positiven Systemtaktflanke übernommen wird.?


Ich meine nein. Das Pin-Flip-Flop ist dem Schaltzeichen nach taktflankengesteuert, kann also nur während der Taktflanke auf den Eingang reagieren. Das Latch hat mit Sicherheit ein Propagation Delay (Laufzeit) in der der Eingang zum Ausgang durchgeschaltet wird. Hier behaupte ich jetzt, daß das länger ist als eine Taktflanke dauert. Auch wenn das Latch mit positiver Systemtaktflanke transparent wird, kann es nicht rechtzeitig den Eingang zum Ausgang durchschalten, so daß der Ausgang mit gleicher positiver Systemtakflanke auch gleich ins PIN-Flip-Flop übernommen wird. Ich versuche das jetzt nicht zu belegen, sondern verlasse mich da auf das Datenblatt Figure 10-3. Sozusagen Erklärung nach Datenblatt passend gemacht, aber für mich plausibel. Man könnte jetzt gängige D-Latch/Flip-Flop (taktzustandsgsteuerte/ taktflankengesteuerte) Datenblätter suchen und Laufzeiten und Flankenzeiten durchsehen - das überlasse ich Dir :-)

Ich glaube also auch, daß immer nur der gespeicherte Zustand ins PIN-Flip-Flop übernommen wird und kein transparent durchgereichter.

Zitat:

---

Dass man ein Latch nimmt und nicht ein zweites D-FF mit negiertem Takteingang, muss irgend etwas damit zu tun haben, dass man versucht kurze Pegelwechsel auszublenden, wir aber nur ein Prinzipschaltbild zu sehen bekommen, wo dies nicht ersichtlich ist.

---

Da kann ich nichts zu sagen. Ich glaube jedoch nicht, daß man kurze Pegelwechsel von der µC Seite her versucht auszublenden.

Gruß
Searcher

Wenn ich auch mal eine andere Ansicht einbringen darf, würde ich sagen, das Latch übernimmt den Zustand an seinem Eingang und gibt ihn direkt an den Ausgang weiter. Ändert sich der Zustand am Eingang wieder, kommt irgendwann die steigende oder fallende Flanke, wo das Latch wieder die Information übernimmt. Die Information bleibt erhalten, selbst wenn sie am Eingang nicht mehr vorhanden ist. Mehr würde ich da nicht vermuten.

MfG

Hallo Moppi,
ich beziehe mich auf Figure "10-2. General Digital I/O" aus dem ATtiny13A Datenblatt. Der Synchronizer dort besteht aus zwei D-Flip-Flops. Das erste, an dem der Portpin der D-Eingang ist, ist ein taktzustandsgesteuertes. Nenn ich kurz Latch. Das zweite ist ein taktflankengesteuertes und nenne ich hier PIN-Flip-Flop. Das ist dann auch das PIN-Register für einen Portpin. Dessen D-Eingang ist der Ausgang des Latches.

Zitat:

---

Zitat von Moppi

... das Latch übernimmt den Zustand an seinem Eingang und gibt ihn direkt an den Ausgang weiter.

---

Aber nur wenn der Systemtakt "high" ist. Wenn Systemtakt low, dann ist das Latch nicht transparent.

Zitat:

---

Ändert sich der Zustand am Eingang wieder, kommt irgendwann die steigende oder fallende Flanke, wo das Latch wieder die Information übernimmt.

---

Welches Latch? Das erste im Sychronizer ist taktzustandsgesteuert. Das zweite, auch PIN-Flip-Flop übernimmt nur bei steigender Flanke.

Zitat:

---

Die Information bleibt erhalten, selbst wenn sie am Eingang nicht mehr vorhanden ist. Mehr würde ich da nicht vermuten.

---

Wenn die Information nicht bei einer fallenden Systemtakt Flanke am Eingand des ersten Latches anliegt, geht sie verloren, bzw wird ein falscher gepeichert. Wie oben schon mal erwähnt, meine ich, daß ein Signal, um es sicher zu erkennen, mindestens ein Systemtakt lang anliegen muß. Sie bleibt dann einen halben Systemtakt lang im Latch gespeichert. Hier kann das Signal sich am Portpin ändern ohne Auswirkung auf die Weitergabe zum PIN-Flip-Flop. Nach dem halben Systemtakt wird der gespeicherte Zustand vom PIN-Flip-Flop mit einer positiven Systemtaktflanke übernommen.

Gruß
Searcher

Zitat:

---

Zitat von Searcher

...
Ich glaube, so langsam komme ich dahinter was Du meinst:
- Die positive Systemtaktflanke leitet die transparente Phase des ersten Synchronizerlatches ein
- Eine positive Systemtaktflanke übernimmt aber auch den Ausgang des ersten Synchronizerlatches in das PIN-Flip-Flop.
...

Gruß
Searcher

---

Schön,

ich denke es liegt auch ein wenig daran, dass meine Screenshots hier eher wie Piktogramme erscheinen.



Deshalb habe ich hier mal versucht meine Überlegungen zum Best-Case-Fall deutlich zu machen und würde mich freuen deine Sichtweise hierzu zu erfahren :

https://www.edv-dompteur.de/forum/in...=4004#post4004


Bernd_Stein

Zitat:

---

Zitat von Bernd_Stein

ich denke es liegt auch ein wenig daran, dass meine Screenshots hier eher wie Piktogramme erscheinen.
Deshalb habe ich hier mal versucht meine Überlegungen zum Best-Case-Fall deutlich zu machen und würde mich freuen deine Sichtweise hierzu zu erfahren :

---

Ich denke, daß man hier auch alles deutlich darstellen kann, was nötig ist. Vielleicht nicht so komfortabel und mit einiger Formatiererei von Bildern verbunden. Aber es geht. Ich mag auch nicht forenübergreifend referenzieren.

Zum best case ist es nötig, daß das Signal, also das high an PB1 zu einem Zeitpunkt gerade vor einer fallenden Flanke des Systemtaktes angelegt wird. Dann wird es gelatcht (gespeichert). Das SBIS aus dem Assembler code muß dann zu Beginn der unmittelbar folgenden steigenden Systemtaktflanke beginnen. Dann ist auch das Signal in das PINxn übernommen worden (nach Fig. 10.3) und kann von SBIS gültig abgefragt werden. SBIS führt einen SKIP über den RJMP durch und schaltet die LED ein.

0,5T von fallender Falnke des Latches und speichern
2T vom SBIS (mit SKIP)
2T vom SBI zum LED einschalten.

Also 4,5 Systemtakttakte sehe ich als best case.

Gruß
Searcher

Zitat:

---

Zitat von 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 *

---

Jo okay wenn ich es also richtig verstehe möchtest du den Takt sprich die Zeit ermitteln. Und der Tiny läuft auf 4,8Mhz um wenige Khz würde ich mich jetzt nicht festlegen wollen siehe
DB
During reset, hardware loads the calibration data into the OSCCAL register and thereby auto-matically calibrates the oscillator. There are separate calibration bytes for 4.8 and 9.6 MHzoperation but only one is automatically loaded during reset (see section “Calibration Bytes” onpage 104). This is because the only difference between 4.8 MHz and 9.6 MHz mode is an inter-nal clock divider

3,2/4,8 = 0,66666 sprich 66,66%
3,2Mhz = 312,5ns
4,8Mhz = 208,3ns Taktzeit

Sonst lese er mal vom Tiny das OSSCAL aus was nach einem RESET reingeschrieben wurde siehe Seite 104
The signature area of the ATtiny13 contains two bytes of calibration data for the internal oscilla-tor. The calibration data in the high byte of address 0x00 is for use with the oscillator set to 9.6MHz operation. During reset, this byte is automatically written into the OSCCAL register toensure correct frequency of the oscillator.There is a separate calibration byte for the internal oscillator in 4.8 MHz mode of operation butthis data is not loaded automatically. The hardware always loads the 9.6 MHz calibraiton dataduring reset. To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCALregister must be updated by firmware. The calibration data for 4.8 MHz operation is located inthe high byte at address 0x01 of the signature area.

Zitat:

---

Zitat von Bernd_Stein

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

Anhang 34932

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

---

EIJJAAAAAAIJJAIIIIIIIIII da is ja so einiges im Argen.
1. Woher sollen wir wissen was in deinen Includes steht bzw ob es überhaupt sinnvoll ist ?

2. Includes entweder komplett vorne und hinten anfügen aber nicht unbedingt irgendwo im Programm.

3. Wenn du mit INT arbeitest was meinst du was du bei der Initialisierung noch brauchst ?
DEN STACKPOINTER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

4. Was steht in der ISR als Rücksprung bzw ist das RETI eingetragen ? Wenn nicht läuft er dir dein CTRL die gesamten ISR-Routinen durch, bisher sind sie für uns alle UNSICHTBAR siehe Punkt 1, und wenn da irgendwas steht wird das
gnaaaadenlos abgearbeitet was dann zu unerwarteten Effekten führen kann wie zb ein RESET des gesamten CTRL. Besonders wenn ein RET/RETI ausgeführt wird ohne den SP angelegt zu haben.

5. Sieh dir mal an wie ich es Bibliotheken gepackt habe https://www.roboternetz.de/community...328-Bibliothek

6. Zu
.ORG INT_VECTORS_SIZE ;Programmadresse nach den ganzen IRQ-Vektoren
was komplett falsch verstanden worden ist
EINMAL folgendes lesen https://www.mikrocontroller.net/topic/265926

7. Was meinst du wie sehr ein Taster prellt ? Da arbeitet er die Befehle folgend auf SBIC/S sofort mehrmals ab deshalb ist absolut unelegant einen Taster ohne Wartezeit oder Entprellroutine so abzufragen.
Sollte das Signal natürlich DIGITAL vorliegen ist es so durchaus normal. Leider fehlt der Kommentar was die Ursache zum Auslösen ist.

8. Zum Systemtakt änder verweise ich auf S.28 des DB wie dort 100%ig zu verfahren ist und nicht irgendwie https://ww1.microchip.com/downloads/...oc/doc2535.pdf


Vorschlag wenn du ohne große INIT usw usf deinen Systemtakt ermitteln möchtest wie folgt

INIT:
SBI DDRX , Y ; 2Takte

Start:
SBI PORTX , Y ; 2Takte
CBI PORTX , Y ; 2Takte
SBI PORTX , Y ; 2Takte
CBI PORTX , Y ; 2Takte
SBI PORTX , Y ; 2Takte
CBI PORTX , Y ; 2Takte
rjmp Start ; 2Takte

Beim RJMP bleibt das Bit etwas länger gelöscht ist aber nicht weiter schlimm man könnte daran erkennen wann das Programm wieder von vorn beginnt. So eine Art Synch....

PS: Dein nicht erklärbarer Takt kommt von deiner Software und von nichts anderen !!!! ASM macht nur das was DU, der Programmierer geschrieben hast, auch wenn mal etwas vergessen wurde

- - - Aktualisiert - - -

Zitat:

---

Zitat von Bernd_Stein

Es ist schon ein Elend mit diesen Foren. Da hat man mal einen kompetenten Schreiber der sich der Sache annimmt, dann taugt die Forensoftware leider nichts.
Man investiert eine menge Arbeit und aus dem Bild wird dann nur noch ein " Piktogramm ". Oder die Forensorftware ist Top, aber es nehmen nur Trolle an der Diskusion teil.

Also nochmal etwas anders :

Meines Wissens her, ist bei einem Latch im transparenten Teil, der Eingang gleich dem Ausgang ( D = Q ). Das Latch ist in der High-Phase des Systemtaktes transparent, also ab der steigenden Flanke bis zur fallenden Flanke des Systemtaktes.

Höchstwahrscheinlich ist dies wieder nur ein Prinzipschaltbild und dass PINxn-Register speichert mit der steigenden Flanke immer nur den gespreicherten Zustand des Latches und nicht den im transparenten Moment, oder es ist grundsätzlich so, dass ein Latch nicht so schnell vom Latch-Zustand in den Transparenten umschaltet wie ich es jetzt annehme.

Anhang 34943

Dass man ein Latch nimmt und nicht ein zweites D-FF mit negiertem Takteingang, muss irgend etwas damit zu tun haben, dass man versucht kurze Pegelwechsel auszublenden, wir aber nur ein Prinzipschaltbild zu sehen bekommen, wo dies nicht ersichtlich ist.

So, schicke dies erstmal los bevor noch was schiefgeht.


Bernd_Stein

---

Das Problem hat NIX, 0 mit der HW des CTRL zu tun !!!!

Aber um die Informationslage etwas zu verdichten kann man ganz vereinfacht sagen das Daten erst auf den PORT/DDR/PIN gelegt/abgefragt werden wenn der nächste Systemtakt kommt. Dies soll sicherstellen das die Daten immer und zu jeden Zeitpunkt KONSISTENT sind.

Man stelle sich vor dies wäre nicht so und am Eingang/Ausgang wird es ASynchron geändert was das für ein Durcheinander in UNSERER SW geben würde. Manche Programmteile würde immer ausgeführt manche gar nicht und andere wiederum nur ab und an und manch andere nur mit gaaaanz viel Glück.

Siehe ADC wenn 10bit ausgelesen werden sollen wird das Datenwort, also die 10Bit = 8 Bit low und 2 Bit High, MUSS ADCL als erstes gelesen werden und erst wenn ADCH gelesen WORDEN ist wird ADCH:L für den ADC freigegeben wieder Ergebnisse dort zu hinterlegen damit die Datensätze konsistent bleiben.

Zitat:

---

Zitat von Searcher

...
Also 4,5 Systemtakttakte sehe ich als best case.

Gruß
Searcher

---

Oh, ja stimmt. Was habe ich wieder für ein Quatsch gedacht. Das zeichne ich konkret den Codeablauf Takt für Takt auf und interpretiere es dann doch falsch.

@avr_racer
Das war erstmal eine zu geballte Informationsflut, die ich mir einmal durchgelesen habe. Du scheinst ja mächtig viel in AVR8ASM zu programmieren, was ja schon mal gut ist. Das DB zu zitieren ist schon mal nicht schlecht, aber mit dem Verstehen des englischen hapert es leider bei mir. Werde evtl. irgendwann später auf dein Post eingehen, jetzt will ich aber auch mal weiterkommen.


Bernd_Stein