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?
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
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
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?
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
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.
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?
> 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
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!
>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?
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
> 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?
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 ...
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?
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.
Kann man Quarze nicht mit Kondesatoren etwas beeinflussen? Oder geht das nur nach unten?
Im Prinzip geht das auch nach oben z. B. mit einem parallelen Widerstand, aber nur im Bereich von Promille, nicht Prozent.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.