Moin Moin!
Ich stecke grad etwas fest in meinem kleinen Projekt ;) Also ich habe
einen kleinen Seriell-Parallel-Umwandler gebastelt, bei dem ich für das
Schieberegister und den Zähler natürlich einen Takt benötige. Dieser
kann, wie ich festgestellt habe, nicht durch einen Quarz oder einen
Timerbaustein o.ä. erzeugt werden, da die Daten an der seriellen
EIngangsseite ja asynchron eintreffen. Also wird mit Hilfe des
Flip-Flops der Takt aus den eintreffenden Daten erzeugt. Ehrlich gesagt
habe ich mir das nicht selber überlegt, sondern aus einem Elektor
Artikel kopiert ;) Mein Problem ist nun, dass (siehe Oszilloskopschirm
im Anhang) der Takt zu spät kommt. In diesem Beispiel habe ich eine '4'
gesendet, also dezimal 52 = 0x34 = 0b00110100. Eigentlich kommt der Takt
auch nicht zu spät, sondern der High-Pegel des ersten Taktes dauert
einfach zu lange. Standardmäßig ist der Takt auf Low, und wenn das
Starbit kommt, beginnt der Takt ja auch zu "arbeiten". Nur eben, dass
der erste High-Pegel zu lange dauert. Hat jemand eine Idee was hier
falsch läuft? :)
Vielen Dank für Eure Hilfe!!!
Hi,
eine RC-Oszillator für UART ? Brrr. Nun ja. Welche Baudrate willst Du
realisieren ? Die Verzögerungsglieder könnten evtl. kürzer Dimensioniert
werden. Da solltest Du mal den Signalverlauf checken.
Der Signalpegel vor dem Startbit ist nicht erkennbar. Ist der da "1"
oder "0" ? Ist das für eine bestimmte Aufgabe (Schule?), da dies mit
einem Mikrokontroller viel einfacher gemacht werden könnte.
Niemand schrieb:> Welche Baudrate willst Du realisieren ?
9600 Baud
Niemand schrieb:> Die Verzögerungsglieder könnten evtl. kürzer Dimensioniert> werden.
Du meint also R2 und R4 verkleinern? Welche Zeitkonstante wäre sinnvoll?
Niemand schrieb:> Der Signalpegel vor dem Startbit ist nicht erkennbar. Ist der da "1"> oder "0" ?
High, also "1"
Niemand schrieb:> Ist das für eine bestimmte Aufgabe (Schule?), da dies mit> einem Mikrokontroller viel einfacher gemacht werden könnte.
Ich weiss, dass es mit einem µC viel einfacher wäre, wollte diese
Aufgabe aber gerne mal mit Standardlogik bewältigen :)
Das Oszibild legt nahe, dass deine eingestellte Geschwindigkeit zu groß
ist.
Geh mal am PC auf halbe Geschwindigkeit. Was ist momentan eingestellt?
mfg mf
Mini Float schrieb:> Das Oszibild legt nahe, dass deine eingestellte Geschwindigkeit zu groß> ist.> Geh mal am PC auf halbe Geschwindigkeit. Was ist momentan eingestellt?
Ich hatte immer 9600 Baud am PC eingestellt (8N1). Nun bin ich mal auf
4800 Baud gegangen, der Effekt bleibt jedoch der gleiche :(
Ich habe nun nochmal andere Zeichen gesendet ('1', '2' und '3') und die
Scopeschirme angehängt. Egal, was ich sende, der Takt ist zu Beginn
immer zu lange auf High-Pegel...
Wird dein Oszillator bei fehlendem Eingangssignal gestoppt? Habs jetzt
nicht durchgespielt. Wenns so ist, dann wird der erste Takt nicht die
gewünschte Länge haben, denn du sperrst den Oszillator -> der Kondi wird
komplett geladen/entladen jenseits der Hysterese!
Besser ist es bei solchen Schaltungen, den Oszillator freilaufend zu
gestalten und ihn nur zu synchronisieren. Oder höhertakten und
runterteilen und im Teiler dann den Reset zur Synchronisation zu
benutzen. Dann bist du schon halb bei einer PLL.
Ich hatte vor sehr lange Zeit mal was erstellt.
Vielleicht kannst du es brauchen.
Der Clock wird mit dem Startbit vom RS-232 synchronisiert. Nach einem
Byte wird jeweils ein Strobe-Signal ausgegeben für die Speicherung des
Byte.
Signal DATEN -> sind empfangene Daten von RS-232
Signale CLOCK und STROBE -> sind sind für Schieberegister o.Ä.
Johannes schrieb:> Also wird mit Hilfe des> Flip-Flops der Takt aus den eintreffenden Daten erzeugt. Ehrlich gesagt> habe ich mir das nicht selber überlegt, sondern aus einem Elektor> Artikel kopiert ;)
Hallo,
Elektor her oder hin, das ist Unsinn. Taktregenerierung aus Daten der
COM-Schnittstelle funktioniert nicht, weil je nach Daten bis zu 8 Nullen
oder Einsen aufeinanderfolgen können, während dessen gibt es keine
Datenflanken, auf die synchronisiert werden könnte - ganz unabhängig
davon, welche Schaltung. Wo nichts ist gibt es auch nichts zu
synchronisieren, und nach 8 Datenbits ist der Takt längst weggelaufen.
Taktregenerierung ist nur mit Codierungen möglich, die bei jedem Bit
eine Flanke erzeugen, oder die bei Bedarf eine Null/Eins
dazwischenschieben.
Das ist in USARTs alles schon eingebaut. Es hat keinen Sinn, das Rad neu
zu erfinden, besonders dann, wenn man es viereckig ausführt.
Gruss Reinhard
Abdul K. schrieb:> Wird dein Oszillator bei fehlendem Eingangssignal gestoppt? Habs jetzt> nicht durchgespielt. Wenns so ist, dann wird der erste Takt nicht die> gewünschte Länge haben, denn du sperrst den Oszillator -> der Kondi wird> komplett geladen/entladen jenseits der Hysterese!
Das habe ich jetzt mal nachgeprüft und an IC2/9 bzw. C3 gemessen.
Tatsächlich liegt es daran, dass der Kondensator in Ruhe auf 5V liegt
und dementsprechend lange braucht um sich zu entladen. Problematisch
ist, dass meine Platine eigentlich schon fertig ist. Hat also jemand
eine Idee, wie ich das Problem auf möglichst einfache Weise lösen
könnte? Funktionieren wird es wohl, wenn ich die Datenpakete schneller
hintereinander sende, doch es wäre gut, wenn es auch funktioniert, wenn
ich einzelne Zeichen über ein Terminalprogramm sende, bei denen der
zeitliche Abstand voneinander dann durchaus größer ist. Hmm... jetzt
wirds kniffelig ;)
Könnte es sein, dass die Polarität von deinem seriellen Signal falsch
ist? Es sieht so aus, als ob der Takt mit der ersten steigenden Flanke
und nicht mit dem Startbit anspringt.
Reinhard Kern schrieb:> [..]> Das ist in USARTs alles schon eingebaut. Es hat keinen Sinn, das Rad neu> zu erfinden, besonders dann, wenn man es viereckig ausführt.>
Im Prinzip kann man die Schaltung durchaus bauen!
Zur Info:
Herkömmliche UARTs synchronsisieren an der ersten Flanke des Bytes -
also am Startbit! Danach laufen sie frei mit bis zum Stopbit. Wonach sie
wieder auf das Startbit warten.
Problem: Ist nur ein Stopbit vorhanden und werden die Daten ständig
aufeinanderfolgend empfangen, kann diese gängige Mimik das Stopbit nicht
eindeutig finden. Es kann dann eine Weile dauern, bis der UART korrekt
synchronisiert.
Johannes schrieb:> Das habe ich jetzt mal nachgeprüft und an IC2/9 bzw. C3 gemessen.> Tatsächlich liegt es daran, dass der Kondensator in Ruhe auf 5V liegt> und dementsprechend lange braucht um sich zu entladen. Problematisch> ist, dass meine Platine eigentlich schon fertig ist. Hat also jemand> eine Idee, wie ich das Problem auf möglichst einfache Weise lösen> könnte? Funktionieren wird es wohl, wenn ich die Datenpakete schneller> hintereinander sende, doch es wäre gut, wenn es auch funktioniert, wenn> ich einzelne Zeichen über ein Terminalprogramm sende, bei denen der> zeitliche Abstand voneinander dann durchaus größer ist. Hmm... jetzt> wirds kniffelig ;)
Eventuell kannst du IC1C und IC2C einfach tauschen im Layout? Sollte
dann der Lösung schon sehr nahe kommen.
Abdul K. schrieb:> Eventuell kannst du IC1C und IC2C einfach tauschen im Layout? Sollte> dann der Lösung schon sehr nahe kommen.
Wie soll ich die denn dann verschalten? Das eine Gatter hat einen und
das andere zwei Eingänge.
Hm. Ganz so einfach ist es doch nicht, da dein Oszillator nicht auf
einem Vielfachen schwingt. Hmmmmmmmmmm: Mach parallel zu C3 drei oder
vier Dioden in Reihe bzw. eine Zenerdiode oder LED, sodaß der Kondi
nicht mehr voll aufgeladen wird, aber noch oberhalb der Schwelle settlen
darf. Das sollte gehen.
Da wäre auch noch ein freies Gatter.
Die maximale Spannung für C3 würde ich lieber mit einer Diode zu einem
Spannungsteiler einstellen. Wenn P1 dafür zu niederohmig ist, statt der
Diode einen Transistor als Emitterfolger.
Einfacher wäre heute aber ein kleiner µC.
IMG_0124.jpg
(84 KB)
schematics.png
(190 KB)
