ATMEGA "Propagation delay"

[Detlev T. (detlevt)]

Hallo Leute,

bei Logik-ICs finde ich häufig eine Angabe zum "Propagation Delay", also 
der Zeit zwischen Eingang des Taktes und der Änderung des Ausganges. In 
den Datenblättern der ATMEGAs finde ich dazu nichts. Deshalb folgende 
Frage, Angenommen ich habe folgenden Code:

clr r16
ser r17
out DDRB, r17
out PORTB, r16
out PORTB, r17 
out PORTB, r16
out PORTB, r17 
out PORTB, r16
out PORTB, r17

Wie würde jetzt das Signal an den Portpins in Bezug auf den Systemtakt 
aussehen? Irgendeine feste Phasenbeziehung muss es da doch geben.

Vielen Dank schon einmal für alle Antworten.

Gruß, DetlevT

[Dummy (Gast)]

Detlev T. schrieb:
> Irgendeine feste Phasenbeziehung muss es da doch geben.

Das einfachste wäre eigentlich, das nachzumessen.
Wozu ist das für Dich wichtig?

[AVRnixblicker (Gast)]

Es gibt in den Datenblättern Schaltbilder der I/O-Ports.
Daraus geht prinzipiell die Struktur mit den Gattern und
Latches hervor. Eine exakte Aussage bis auf die Nanosekunde
und darunter gibt es nicht. Da sich die Ports und deren
Struktur bei den AVR-CPUs unterscheiden, dürfte eine
allgemein gültige Auskunft nicht möglich sein. Zumal es
auch unterschiedliche Herstellungsprozesse gibt.
Da hilft nur Messen - und zwar Pin für Pin.
Und die externe Beschaltung nicht vernachlässigen.
Temperatur und Betriebsspannung dürfte auch Einfluss
auf die Signallaufzeiten haben.

[Detlev T. (detlevt)]

Hallo dummy,

vor allem ist es Neugier. Ich habe folgenden Thread entdeckt: 
Beitrag "AVR VGA Terminal"

Da wird ein 74HC165 (8-Bit-Schieberegister mit Parallelem Eingang) mit 
demselben Taktsignal wie der ATMEGA betrieben. Via Portpin werden neue 
Werte geladen. Damit das Ausgangssignal stimmt, also das erste Bit in 
etwa genau so lange ausgegeben wird wie die nachfolgenden, müsste die 
low-high-Flanke des Portsignals möglichst kurz nach dem low-high des 
Systemtaktes kommen. Ganz schlecht wäre eine Phasenverschiebung ~180°.

Da das Projekt funktioniert, kann es so, wie es die Leute gemacht haben, 
wohl nicht ganz falsch gewesen sein. Aber vielleicht kann man das ja mit 
Daten untermauern - und eventuell noch etwas korrigieren.

Gruß, DetlevT

PS: @AVRNixBlicker: Das ist ein guter Tipp. Werde ich machen.

[Detlev T. (detlevt)]

@AVRNixBlicker

Erkennen konnte ich da nix, weil nicht erkennbar ist, auf welche Flanke 
das interne Flipflop reagiert. Ich habe aber zufällig (die Dinger sind 
auch dick, die kann man gar nicht komplett kennen)dabei den Abschnitt 
"Instruction Execution Timing" entdeckt und demnach hat ein Befehl 
offenbar kurz nach der steigenden Flanke des Taktsignals "fertig". Ich 
gehe daher davon aus, dass die Änderung am Portpin auch immer kurz nach 
der steigenden Taktflanke geändert wird. Wie viel später weiß ich zwar 
immer noch nicht, aber mir reicht eigentlich diese Information.

VIelen Dank, DetlevT

[Anja (Gast)]

Hallo,

wenn Dir das Timing wichtig ist weil Du externe Hardware synchronisieren 
willst solltest Du einen Prozessor nehmen bei dem dies spezifiziert ist. 
Z.B. hier:

http://ww1.microchip.com/downloads/en/DeviceDoc/39631E.pdf

Siehe Seite 344 Figure 26-7

Dummy schrieb:
> Das einfachste wäre eigentlich, das nachzumessen.

Das funktioniert vielleicht für Bastellösungen bei Serienfertigung 
braucht man garantierte Min und Max-Werte fürs Timing.

Gruß Anja

[Detlev T. (detlevt)]

Hallo Anja,

es geht mir ums "Basteln". Ich bin froh, die AVRs einigermaßen zu 
kennen, mit PICs will ich nicht anfangen. Außerdem scheint es mit, dass 
ein PIC mehr als einen Takt pro Befehl braucht. Damit wäre so etwas hier 
ohnehin nicht zu gebrauchen, weil ich dann die Takte wieder mit einem 
zusätzlichen Flip-Flop synchronisieren müsste. Das könnte ich dann aber 
auch gleich beim ATMEGA machen.

Trotzdem Danke für deine Mühe.

Gruß, DetlevT

[Joe G. (feinmechaniker)]

Detlev T. schrieb:
> Damit das Ausgangssignal stimmt, also das erste Bit in
> etwa genau so lange ausgegeben wird wie die nachfolgenden, müsste die
> low-high-Flanke des Portsignals möglichst kurz nach dem low-high des
> Systemtaktes kommen.

Kritisch ist eigentlich "nur" das erste Pixel. Dann folgen ja 8 x 80 
Befehle genau Taktsynchron. Die Verzögerung bis zum ersten Pixel wird 
über den TIMER1COMPB Interrupt eingestellt.
Hier, Beitrag "CP/M auf ATmega88" wird gerade eine 
zugehörige Hardware auf der Basis des obigen Thread diskutiert.
Joe

[Detlev T. (detlevt)]

Hallo Joe,

dem ist sicher nicht so. Das wiederholt sich bei jedem Byte. 
Problemmacher ist hier der asynchrone "Load"-Eingang.

Die Lösung liegt aber wohl nah. Beim 74HC166 ist der Load-Eingang im 
Gegensatz zum 74HC165 mit dem Takt synchronisiert. (Ich habe aber 
bislang nur einen kurzen Blick ins Datenblatt geworfen).

Den CP/M Thread habe ich sporadisch verfolgt. Ich werde einmal vorbei 
schauen und sehen, ob meine neue Erkenntnis da von Nutzen sein kann.

Gruß, DetlevT