So funktioniert es auch. Wenn ich das Delay jedoch reduziere (ab 100us)
kommt nur noch Schrott im Terminalprogramm auf dem PC an.
Die USART Checkliste habe ich bereits durch. Leider ohne Besserung.
Hat einer eine Idee was ich machen muss, damit ich das Delay entfernen
kann ohne das es Datenmüll gibt?
Habe gerade keinen 16 MHz Takt zur Hand, nur den internen RC-Oszillator
mit 8 MHz, sodass sich 9600 Bd stattdessen ergeben. Damit funktioniert
dein Test mit und ohne delay problemlos. Habe auch mal spaßeshalber das
Zeichen in jedem Durchlauf hochgezählt, um zu zeigen, das keins verloren
geht, auch das klappt.
Kann es sein, dass dein Terminalprogramm, UART-Treiber oder was auch
immer eine Macke hat und nicht mit "Rücken an Rücken" gelieferten
Zeichen klar kommt?
Auch wenn ich nicht viel Hoffnung habe dass es hilft, aber du könntest
* auf PC Seite nachsehen, ob auch wirklich 1 Stoppbit eingestellt ist
(diese Einstellung sollte eigentlich für den Empfänger egal sein. Auf
der anderen Seite: Wenn der Empfänger darauf besteht, dass auch
wirklich mindestens 2 Bitzeiten Ruhe ist ...)
* auf µC Seite auf 2 Stoppbits hoch gehen.
Die 2 Stoppbits auf µC Seite vergrößern die durch die UART sowieso
erzwungene Pause zwischen 2 Zeichen ein klein wenig.
Normalerweise ist es kein allzugroßes Problem, wenn die Einstellungen
nicht übereinstimmen. Benutzt der Sender ein längeres Stoppbit, so
verschafft er damit dem Empfänger einfach nur ein wenig mehr Zeit um die
empfangenen Bytes abzutransportieren.
Benutzt du UART/USB Wandler?
Thomas Burkhart schrieb:> Wie wärs mit nem Bautratenquarz?
Was sollte der denn ändern?
Wenn der Empfänger aufgrund zu großer Baudratentoleranz daneben liegt,
dann sollte er das unabhängig von der Dichte der Zeichenfolge sein.
Alles andere wäre unlogisch. Schließlich haben wir eine asynchrone
Übertragung, bei der jedes Zeichen neu synchronisiert wird.
Nein, die Toleranz bei 16 MHz und Vorteilerwert 51 ist 0,16 %,
das ist weit im Rahmen. Die Flanke des Stopbits kommt gerade mal
750 ns zu zeitig, bei einer Bitzeit von 52 µs. Er benutzt ja sogar
einen Quarz, bei mir lief das Ganze mit dem unkalibrierten 8-MHz-
RC-Oszillator jedoch auf Anhieb.
Jörg Wunsch schrieb:> Kann es sein, dass dein Terminalprogramm, UART-Treiber oder was auch>> immer eine Macke hat und nicht mit "Rücken an Rücken" gelieferten>> Zeichen klar kommt?
Danke fürs ausprobieren!
Ich hab es auch mal mit einem Notboock und anderem Terminalprogramm
probiert, das gleiche Problem. Von daher sollte es nich am Rechner oder
Terminalprogramm liegen.
So wie ich dich verstehe ist der Code selbst OK (?). Von daher bleibt
noch der UART-Treiber...
Karl heinz Buchegger schrieb:> Auch wenn ich nicht viel Hoffnung habe dass es hilft, aber du könntest ...
Ja, mit 2 Stoppbits habe ich bereits auf beiden Seiten probiert, hilft
leider nichts. Wenn ich die Baudrate im Terminalprogramm verändere ohne
sie im µC an zu passen bekomme ich trotzdem immer Daten rein. Allerdings
wirres Zeug.
Thomas Burkhart schrieb:> Wie wärs mit nem Bautratenquarz?
Ja wie schon erwähnt, der Fehler liegt jetzt schon bei geringen 0,2%.
Sollte also reichen.
Fly schrieb:> Ich hab es auch mal mit einem Notboock und anderem Terminalprogramm> probiert, das gleiche Problem.
Das ist in der Tat seltsam.
Das verschiebt die Zuständigkeit weiter zum AVR> Von daher sollte es nich am Rechner oder> Terminalprogramm liegen.
Seh ich auch so.
> So wie ich dich verstehe ist der Code selbst OK (?). Von daher bleibt> noch der UART-Treiber...
Vielleicht ein Problem beim MAX3221
Das dem die Ladungspumpe und damit die Spannungen einbrechen.
Machst du Pausen dazwischen, gibst du dem Teil Zeit, die Spannungen
wieder aufzubauen.
Defekter Kondensator oder so was in der Richtung.
Hast du den es mal mit einem Loop-Back auf seiten de uC versucht?
Würde nämlich auch darafu tippen:
Karl heinz Buchegger schrieb:> Das dem die Ladungspumpe und damit die Spannungen einbrechen.> Machst du Pausen dazwischen, gibst du dem Teil Zeit, die Spannungen> wieder aufzubauen.
Fly schrieb:> Wenn ich das Delay jedoch reduziere (ab 100us)> kommt nur noch Schrott im Terminalprogramm auf dem PC an.
Was bedeutet in diesem Zusammenhang der Begriff "Schrott"?
Sind es
a) ausgelassene Zeichen
b) veränderte Zeichen
Im Fall a) kann es sein, dass senderseitig neue Zeichen zu früh in den
USART hineingeschrieben werden. Im Fall b) handelt es sich jedoch eher
um ein Baudratenproblem oder elektrische Störungen.
Karl heinz Buchegger schrieb:> Das dem die Ladungspumpe und damit die Spannungen einbrechen.> Machst du Pausen dazwischen, gibst du dem Teil Zeit, die Spannungen> wieder aufzubauen.>> Defekter Kondensator oder so was in der Richtung.
Solch ein Ladungspumpenproblem hatte ich auch schon einmal bei den
Steuerleitungen. Wenn nämlich zwei Ausgänge gegeneinander geschaltet
sind, bricht die Spannungsversorgung des gesamten Bausteins zusammen,
selbst wenn die betreffenden Steuerleitungen nicht verwendet werden!
Dies kann hier wahlweise auf der PC- oder AVR-Seite der Fall sein.
Um solch einen Fehler auszuschließen bzw. zu diagnostizieren, empfehle
ich für einen Test, eine Verbindung mit nur zwei Leitungen (GND, TxD)
vorzunehmen. Es sollten auch an den Steckern keine Brücken für die
Handshake-Leitungen vorhanden sein.
Ggf. mit dem Oszilloskop die Datenleitung(en) auf ungültige
Spannungspegel hin überprüfen; Ladungspumpenausgang auf
Spannungseinbrüche überwachen.
Oder kann es sein, dass der Pegelwandler für 5V Versorgungsspannung
spezifiziert ist, aber mit 3V betrieben wird? Das wäre auch solch ein
Klassiker...
Vielleicht hats wer im Kopf. Bin jetzt zu faul das Datenblatt zu suchen.
Stimmt das wirklich, dass am MAX3221 die Kondensatoren 100n, 470n, 470n,
470n sind?
Kommt mir komisch vor, dass da einer wertmässig aus der Reihe tanzt.
Ja, ich habe auch gerade ins Datenblatt geschaut, jedoch in das von
Maxim. Dort steht wiederum explizit:
"However, do not increase C1 without also increasing the values of C2,
C3, and C4 to maintain the proper ratios (C1 to the other capacitors)"
Die von g457 aufgeführten Tabellenwerte werden auch von Maxim genannt:
http://datasheets.maxim-ic.com/en/ds/MAX3221-MAX3243.pdf
OK, Ok
Also das stimmt.
Kam mir nur seltsam vor, weil ich eigentlich was Symetrisches erwartet
hätte.
Gut, dann kanns das auch nicht sein.
Was aber nicht heißt, dass die Hypothese 'MAX' damit vom Tisch wäre. Den
Loopback Test würde ich immer noch machen. Aber nicht mit der Tastatur,
das gibt wieder delays, sondern mit einem Textfile drüber jodeln.
PC -> Kabel -> MAX -> Brücke -> MAX -> Kabel -> PC
Wenn das Ergebnis vernünftig aussieht, würde ich den MAX von der
Anklagebank runterlassen.
Fly schrieb:> So wie ich dich verstehe ist der Code selbst OK (?).
So sehe ich das auch.
Ich hab's übrigens mit einem STK500+501 und dem Pegelwandler auf dem
STK500 getestet. Gegenseite war Hardware-RS-232 (also kein USB)
und Kermit unter Linux.
Karl heinz Buchegger schrieb:> Machst du Pausen dazwischen, gibst du dem Teil Zeit, die Spannungen> wieder aufzubauen.
--> nein läuft volle lotte durch
Läubi .. schrieb:> Hast du den es mal mit einem Loop-Back auf seiten de uC versucht?
--> nein noch nicht, gute Idee mache ich. Und am besten auch die
Gegenprobe mit PC.
Andreas Schweigstill schrieb:> Was bedeutet in diesem Zusammenhang der Begriff "Schrott"?
--> c) Ich lasse den Controller laufen und schalte danach das
Terminalprogramm ein. Jetzt kommt z.B.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAA....
und nach vielleicht 20 sec. kommt
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP...
Dann noch was anderes und so weiter.
Jedesmal wenn ich das Terminalprogramm neu an mache kommt ein belibiges
Zeichen (A und P bevorzugt) das dann eine Weile wiederholt wird.
Andreas Schweigstill schrieb:> Um solch einen Fehler auszuschließen bzw. zu diagnostizieren, empfehle> ich für einen Test, eine Verbindung mit nur zwei Leitungen (GND, TxD)> vorzunehmen. Es sollten auch an den Steckern keine Brücken für die> Handshake-Leitungen vorhanden sein.
OK, muss ich prüfen, bin zur zeit nicht am Platz...
Andreas Schweigstill schrieb:> Oder kann es sein, dass der Pegelwandler für 5V Versorgungsspannung> spezifiziert ist, aber mit 3V betrieben wird? Das wäre auch solch ein> Klassiker...
Eingestellt ist 5V, messe es aber lieber nochmal nach...
Fly schrieb:> Karl heinz Buchegger schrieb:>> Machst du Pausen dazwischen, gibst du dem Teil Zeit, die Spannungen>> wieder aufzubauen.>> --> nein läuft volle lotte durch
Genau das meine ich ja.
lässt du full Speed laufen, hast du Fehler
Gibst du etwas Erholungszeit, hast du keine Fehler.
Das kann ein Zusammenhang sein, muss allerdings nicht. Einen Test wäre
es mir aber wert.
> --> c) Ich lasse den Controller laufen und schalte danach das> Terminalprogramm ein.
Schlechte Strategie!
Immer zuerst den Empfänger anmachen. Der Empfänger muss sich auf das
Startbit synchronisieren. Der kann aber bei dem ganzen 0/1 Gezappel auf
der Leitung nicht wissen, welche Flanke denn nun das Startbit ist. Also
nimmt er die nächst beste (erste) Flanke als Startbit und tastet ab dort
im Zeitraster ab. Da die Flanke, die der PC als Startbit annimmt aber
nicht wirklich das Startbit sein muss sondern einfach nur eine Flanke
aus irgendeinem Datenbit, steigt die PC-UART da 'schräg' in die
Übertragung ein.
Gibst du ein wenig Zeit zwischen den Bytes, dann schafft es die
Empfängeruart sich in dieser Pause korrekt auf das nächste Startbit
einzuklinken und ab dann läuft alles richtig.
-> auf eine mit Full-Speed laufende UART Verbindung kann man sich nicht
fehlerfrei einklinken. Die 100%-ige Synchronisierung findet erst mit der
ersten Übertragungspause statt, die länger als die Übertragungszeit
eines Bytes ist.
Edit: Hatte nicht fertig gelesen
> Jetzt kommt z.B. AAAAAAAAAAAAAAAAAA
Du kriegst ja das korrekte A, das dann nach einiger Zeit einem falschen
Zeichen Platz macht. Das würde wieder darauf hindeuten, dass das Timing
nicht stimmmt.
Fly schrieb:> Jedesmal wenn ich das Terminalprogramm neu an mache kommt ein belibiges> Zeichen (A und P bevorzugt) das dann eine Weile wiederholt wird.
Fällt dir an dem Bild was auf?
Je nachdem, zu welchem Zeitpunkt er den Empfänger einschaltet,
interpretiert er die gleiche Bitfolge mal als A, mal als P.
Wenn der Empfänger aber die ganze Zeit aktiv ist und sich trotzdem
verzählt, dann hat er irgendwie ein Synchronisationsproblem.
!!ES GEHT!!
Ich mag fast garnicht sagen wiso. Es lag genau daran:
Karl heinz Buchegger schrieb:>> --> c) Ich lasse den Controller laufen und schalte danach das>>> Terminalprogramm ein.>>>> Schlechte Strategie!>>>> Immer zuerst den Empfänger anmachen. Der Empfänger muss sich auf das>> Startbit synchronisieren. Der kann aber bei dem ganzen 0/1 Gezappel auf>> der Leitung nicht wissen, welche Flanke denn nun das Startbit ist. Also>> nimmt er die nächst beste (erste) Flanke als Startbit und tastet ab dort>> im Zeitraster ab. Da die Flanke, die der PC als Startbit annimmt aber>> nicht wirklich das Startbit sein muss sondern einfach nur eine Flanke>> aus irgendeinem Datenbit, steigt die PC-UART da 'schräg' in die>> Übertragung ein.>> Gibst du ein wenig Zeit zwischen den Bytes, dann schafft es die>> Empfängeruart sich in dieser Pause korrekt auf das nächste Startbit>> einzuklinken und ab dann läuft alles richtig.
Ich danke euch!