mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ursachen von Datenschwund bei RS232?


Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei verschiedenen RS232-Geräten habe ich das Problem, dass manche
Geräte-Kombinationen nicht ohne Fehler kommunizieren können, also daß
mindestens eines von ihnen sich nicht an den Standard hält.
Beispielsweise funktionert die Relaiskarte 8fa von Conrad (19200 Baud)
problemlos an den onboard-Ports vom PC, aber nur zu 90 % mit einem
USB2-RS232-Adapter und zu 0 % mit einem USB1-RS232-Adapter. Die Fehler
die auftauchen sind sowohl fehlende Bytes als auch gekippte Bits.

Mit anderen Geräte wie dem DMM V820 funktioniert es über alle
Ports/Adapter problemlos (bei nur 2400 Baud, aber über Lichtschranke).

Woran kann das liegen? Sind es Phasen-Fehler oder Amplituden-Fehler
oder eine Mischung von beiden?

Es müßte doch Untersuchungen zu dem Thema geben, aber ich konnte noch
keine finden. Kann jemand entsprechende Links posten?

Autor: Peter M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn es sich hauptsächlich / ausschliesslich um Fehler bei Verwendung
von USB <--> RS-232 Wandlern handelt ist ein zeitliches Problem bei der
Umsetzung sehr wahrscheinlich !!!

Peter

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hatte ähnliche Probleme mit den FTDI Chips. Bei solchen USB-R232
Konvertern musst du in den Treiber-Settings die Buffer-Größe,
Übertragungsgeschw., etc. einstellen, dass diese auch richtig
funktionieren.

Denke nicht, dass der Fehler in so ner niedrigen Schicht (Amplitude,
usw.) liegt - soweit sollten sie die Dinger getestet haben.


mit freundlichen Grüßen,
aleX

Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich verwende write + tcflush zum Schreiben, select + read zum Lesen
und cfsetispeed, cfsetospeed, tcsetattr sowie ioctl zum Setzen der
Settings. An der Treiber-Schicht liegt es deshalb definitiv nicht.
Zudem haben die Datenpakete beim der 8fa nur eine Länge von 4 Byte und
die passen sicherlich in jeden Puffer.
Zudem kenne ich das Problem in der Firma auch PC-abhängig; d. h. mit
einigen billig-Mainboards funktioniert's nicht, mit anderen (u.
gleicher Software) funktioniert es problemlos.

Ist die Ursache Phasen-Fehler oder Amplituden-Fehler
oder eine Mischung von beiden?

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche SOftware verwendest du denn am PC? Eine selber geschriebene oder
ein "normales" Terminal Programm? Mit dem von
http://bray.velenje.cx/avr/terminal/ hatte ich einige Probleme zusammen
mit USB-RS232 Konvertern. Da funktionierte das, das jemand im Forum
vorgestellt hat deutlich besser (
http://www.mikrocontroller.net/forum/read-8-155472.html ) . Vielleicht
hilft'z ja.

mit freundlichen Grüßen
aleX

Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze selbst geschriebene Programme.
Ich habe nochmal nachgesehen: Kippende Bits gibt's wohl praktisch
nicht, aber es gehen Bytes verloren. Es sieht nach einem
Synchronisations-Fehler des UARTs aus und anscheinend synchronisieren
die Adapter viel schlechter als die Onboard-Ports.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde nicht von einem Hardwarefehler ausgehen, sondern halte
Programmierfehler für sehr viel wahrscheinlicher. Diese können aufgrund
allgemeiner Verständnisprobleme und der relativ mäßigen Dokumentation
der Schnittstellenprogrammierung durchaus auftreten.
Der eine wesentliche Unterschied zwischen USB-RS232-Konvertern und
anders angeschlossenen seriellen Schnittstellen ist die eingeschränkte
Reaktionsgeschwindigkeit auf externe Ereignisse; aufgrund der gepollten
Natur des USB ist hier nur eine Granularität im Millisekundenraster
möglich, was bei 9600 Baud immerhin der Übertragungszeit eines
einzelnen Bytes entspricht.

Große Probleme treten auf, wenn moderne serielle Schnittstellen mit
byte-orientierten Protokollen betrieben werden, wenn also sehr kleine
Datenpakete von nur wenigen Bytes versandt werden und knappe
Timeoutwerter verwendet werden.
Dann wirkt sich das Hardware-Fifo negativ aus, das in allen neueren
Schnittstellenbausteinen seit dem 16550 verwendet wird. In so einem
Fall ist es hilfreich, das Fifo komplett abzuschalten oder zumindest
die Interrupttriggerschwellen auf den kleinstmöglichen Wert zu setzen.

Hinzu kommt noch die Tatsache, daß ohne sonderliche Maßnahmen unter
Windows Timer mit einer Granularität von 10 msec betrieben werden, was
bei 9600 Baud bereits der Übertragungszeit von 10 Bytes entspricht.

Nein, empfangsseitige Synchronisationsfehler der UART (egal welcher, ob
nun in einem USB-Seriell-Adapter oder einer Onboard-Schnittstelle) kann
man bei hinreichend genauer Baudrate des Senders ziemlich definitiv
ausschließen.

Nun ist Linux (det hättste ja ooch sajen könn, wa?) was anderes als
Windows, und wie man dort beispielsweise die Fifos der seriellen
Schnittstelle beeinflusst, entzieht sich gänzlich meiner Kenntnis - ich
würde aber trotz des zunächst auf Hardware hinweisenden Fehlverhaltens
von einem Softwarefehler ausgehen. Oder gar von einem Treiberproblem
...

Was genau magst Du eigentlich mit der Unterscheidung zwischen
"USB2-RS232-Adapter" und "USB1-RS232-Adapter" meinen? Von wem sind
denn die darin verbauten Controllerchips?

Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> der relativ mäßigen Dokumentation
> der Schnittstellenprogrammierung durchaus auftreten.

Das Serial Programming Howto und die Man-Pages sind nicht mäßig sondern
ausführlich.


>Große Probleme treten auf, wenn moderne serielle Schnittstellen mit
>byte-orientierten Protokollen betrieben werden, wenn also sehr kleine
>Datenpakete von nur wenigen Bytes versandt werden und knappe
>Timeoutwerter verwendet werden.
>Dann wirkt sich das Hardware-Fifo negativ aus, das in allen neueren
>Schnittstellenbausteinen seit dem 16550 verwendet wird. In so einem
>Fall ist es hilfreich, das Fifo komplett abzuschalten oder zumindest
>die Interrupttriggerschwellen auf den kleinstmöglichen Wert zu
setzen.

Das ist hier beim 8fa nicht der Fall, weil Bytes physikalisch verloren
gehen; die sind nicht irgendwo in einem Puffer und tauchen später auf
sonder überhaupt nicht. Sowas wie Puffer-Überlauf scheidet auch aus,
denn auch bei 4 MBaud und 80 Byte Datenpaketen habe ich die zwischen
zwei Schnittstellen nicht.


>Was genau magst Du eigentlich mit der Unterscheidung zwischen
>"USB2-RS232-Adapter" und "USB1-RS232-Adapter" meinen? Von wem
sind
>denn die darin verbauten Controllerchips?

Ohne die Gehäuse (gegossen) aufzufräsen kann ich nur die
Kernel-Meldungen angeben:
USB 2.0-Adapter: ftdi_sio 3-1:1.0: FTDI FT232BM Compatible converter
USB 1.1-Adapter: usb 2-2: PL-2303 converter

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ALso ich kann nur zu den FTDI was sagen .. da musst du bei den Treibern
sehr wohl was einstellen ... BufferGröße, TimeOuts, etc. !

Hatte bei falschen Settings z.B. immer das Problem, dass ab dem 27.
Byte abhängig von der Übertragungsgeschw. verschieden viele Bytes
verschwunden sind - die sind auch nicht mehr aufgetaucht ... sondern
waren einfach weg!

Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hatte bei falschen Settings z.B. immer das Problem, dass ab dem 27.
>Byte abhängig von der Übertragungsgeschw. verschieden viele Bytes
>verschwunden sind - die sind auch nicht mehr aufgetaucht ... sondern
>waren einfach weg!

Dann ist da ein Puffer vollgelaufen, so dass nachfolgende Daten nicht
reingeschrieben wurden, oder die haben die schon vorhandenen
überschrieben.
Jedenfalls empfängt der UART die Daten autonom und gibt die dann als
Byte per IRQ weiter, so daß kein Byte verloren geht, solange es keinen
Puffer-Überlauf gibt.

Welche Settings hast Du denn verändern müssen?

Autor: Alexander Höller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Natürlich zuerst mal die Baudrate, Handshake, etc richtig eingestellt
udn bei den Advanced Settings hab ich folgendes verändern müssen:

Latency Timer: 1msec (Default: 16)

und bei niedrigen Baudraten, musste ich ab und zu die Sende- &
Empfangsbuffer kleiner machen (Default: jeweils 4096 Byte)

Funktioniert mit diesen Settings jetzt aber bei allen Baudraten prima
udn fehlerfrei (Hauptverantworlich schien bei mir der Latency Timer
gewesen zu sein)

mit freundlichen Grüßen,
aleX

Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Latency Timer: 1msec (Default: 16)

Welche Zeit ist damit gemeint? Ist das 1/refresh_rate(USB_bus)?


> und bei niedrigen Baudraten, musste ich ab und zu die Sende- &
> Empfangsbuffer kleiner machen (Default: jeweils 4096 Byte)

Bei der Buffer-Größe kann bei den paar Bytes nichts durch Überlauf
verloren gehen. Dass durch kleinere Buffer mehr Bytes gelesen werden
ist doch wiedersprüchlich, oder gibt's dafür irgendeine
nachvollziehbare Begründung?

Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also durch Testen mit verschiedenen Rechnern/Adaptern und gleichen
Treibern unter verschiedenen Betriebssystemen bin ich mir ziemlich
sicher, dass es am Timing liegt. Beispiel Relaiskarte 8fa:

Auf einem dritten PC (Supermicro 370DL3, dual P III 1000) mußte ich
feststellen, dass es mit den onboard-Ports nicht richtig
funktioniert, obwohl sonst damit alles geht und auch ein Selbst-Update
eines MCs, der die Daten (60 kB) mit einem RAMloader und Bit-Banging
über RS232 einliest, ist damit problemlos, obwohl das kritisch ist
bezüglich Timing und nicht an jedem PC/Adapter funktioniert.
Offensichtlich synchronisiert der UART der Karte nicht sauber, weil er
mit dem Timing außerhalb des RS232-Standards liegt!
Das Timing ist hier so kritisch, dass es noch funktiniert, wenn als
zweites Byte 0x00 übertragen wird, aber es funktioniert mit 0xff als
zweitem Byte nie!

Bei anderen PCs (z. B. mit Tyan Tiger MPX) funktionieren die
Onboard-Ports unabhängig vom zweiten Byte und es geht mit dem
USB2.0-Adapter weil die UARTs wohl toleranter sind. Es geht aber schon
nicht mehr mit dem USB1.1-Adapter; da geht ungefär die Hälfte der Bytes
verloren. Bei den Adaptern ist es unabhängig vom Rechner.

Bei Gelegenheit werde ich mal versuchen das durch den Austauch des
Quarzes der Karte zu korrigieren ...

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mir nach wie vor ziemlich sicher, daß es an der Kombination aus
Software und Treibern liegt, auch wenn diese Conrad-Relais-Karte wohl
auch ein Kandidat für Fehlerquellen sein mag. Aber bei so niedrigen
Baudraten ist das auch schon eher unwahrscheinlich. Wie ist denn diese
Conrad-Karte aufgebaut? Was ist da für ein Controller drauf, mit was
für einem Quarz arbeitet das Teil?

Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Ding hat einen 4 MHz-Quarz.
Ich habe mal probiert mit den Quarzen, die ich hier habe:
3686 kHz: 100 % packet loss
4433 kHz: 50 % packet loss

Es könnte also sein, daß die Karte etwas zu niedrig getaktet ist und
mit einem 4,2 MHz-Quarz optimal funktionieren würde, aber wo gibt's
4,2 MHz Quarze?
Ein anderes Problem wäre zu großer Jitter, beispielsweise weil das
Modulations-Register vom MC (MC68HC705KJ1) der Karte falsch
konfiguriert ist. Ohne den Sourcecode ist das aber schwer feststellbar.

Autor: Johannes Raschke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man Quarze nicht mit Kondesatoren etwas beeinflussen? Oder geht das
nur nach unten?

Autor: nobody0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Prinzip geht das auch nach oben z. B. mit einem parallelen
Widerstand, aber nur im Bereich von Promille, nicht Prozent.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
9600 Baud aus 4 MHz erzeugen - da wird ein Teiler von 416 oder 417
verwendet, was zu
9615 bzw. 9592 Baud führt, also etwa 0.16% zuviel bzw. 0.0008 %
zuwenig.

Das ist eine definitiv tolerierbare Abweichung. Das ist vollkommen in
Ordnung.
Hast Du mal probeweise den Quarz durch einen
4MHz-Festfrequenzoszillator ersetzt? Vielleicht hat Conrad ja beim
Aufbau der Oszillatorschaltung geschlampt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.