[Firmware] RS232-Problem

[saft6luck]

Es gab schon mehrfach Reports zu Problemen mit der RS232. Da ich aktuell wieder etwas mehr damit mache, ist mir ein Problem damit aufgefallen: Nach unregelmäßig vielen Ausgaben auf der RS232 Schnittstelle fällt diese spontan aus.

Also mal nachgemessen und siehe da, bei mir scheint es nach dem HW Handshake zu passieren. Der Handshake funktioniert meist gut, manchmal etwas weniger gut, d.h. er sendet noch ein oder mehrere Bytes und macht dann eine Pause. Manchmal dauert diese Pause aber zu lang, d.h. unendlich lang, die RS232 des eibPCs läuft also nicht mehr an.

Ich betreibe ein LCD an der RS232 und nur um die Übertragung völlig sicher zu machen, habe ich den HW-Handshake im eibPC aktiviert. Prompt nach der Aktivierung treten Probleme auf .

Anbei ein paar Traces an den TTL Pins des RS232 Treibers des LCDs, die Pegel sind also invertiert.

1: Normal: CTS wird vom LCD auf High gesetzt (RSR232 Low) und somit hält der eibPC an (es kommt leider noch ein Byte).
2: Es kommen leider noch 2 Bytes und dann macht der eibPC eine Pause.
3: Lange Pause und dann doch noch ein Byte.
4: Und plötzlich kommt nichts mehr ...
5: 2 x der Effekt: Kabel abziehen und wieder anstecken und es geht wieder

Im letzten Bild sieht man, dass RTS auf High geht (RS232 auf Low). Da habe ich das Kabel abgesteckt -> folglich ist der Pegel des CTS auch abgefallen (nicht sichtbar am Pin des Treibers).

Auf diesen Wechsel hin hat der eibPC wohl wieder angefangen zu senden (und zwar alles, was noch im Puffer war und der scheint sehr groß zu sein!!!). Dann kam es wieder zum Problem (siehe Bild 4), welches ich dann wieder durch abziehen und anstecken des Kabels beheben konnte.

Aus meiner Sicht hat der eibPC ein Problem mit dem HW-Handshake. Evtl. ist das auch das Problem, weswegen das ResetRS232() Kommando eingebaut wurde?!

UPDATE:
Bild 6: Bei 2 Stop-Bits kommen die Pause sogar erst nach 3 Bytes
Bild 7: CTS wird ignoriert?

Nachdem ich testweise auf 2 Stop-Bits gestellt habe (sichtbar an der Lücke zwischen den blauen Balken), kommen sogar 3 Bytes, obwohl CTS dies verhindern soll. Der Fehler ist heute Nacht dafür aber nicht mehr aufgetreten ... mal sehen.

Bild 7 zeigt einen extremen Fall beim Systemstart: Hier scheint CTS nicht beachtet zu werden.

[enertegus]

Ich betreibe ein LCD an der RS232 und nur um die Übertragung völlig sicher zu machen, habe ich den HW-Handshake im eibPC aktiviert. Prompt nach der Aktivierung treten Probleme auf .

Hm, was genau sind denn deine Einstellungen: Baudrate etc. Bitte mal posten. Wie ist die Auslastung des EibPC insgesamt? Kommt es zu den Zeiten, wo z.B. aufwändigere TCP/UP-Abfragen laufen zu den Problemen? Warum benötigst Du den Handshake? Wieviele Daten schickst Du?
Wenn der Buszugriff mit der FT12 läuft, hat die RS232 Echtzeitpriorität, damit wäre auch bei hoher Auslastung die Kommunukation gesichert (wie es auch beim Betrieb dieser Schnittstelle der Fall ist). Wir haben aber hier bewusst berichtet

Aus meiner Sicht hat der eibPC ein Problem mit dem HW-Handshake. Evtl. ist das auch das Problem, weswegen das ResetRS232() Kommando eingebaut wurde?!

Nein, das war, weil der HA7E manchmal hängt.

Bild 7 zeigt einen extremen Fall beim Systemstart: Hier scheint CTS nicht beachtet zu werden.

Das werden sich auch die Spezialisten hier mal anschauen.

[saft6luck]

Hm, natürlich die Einstellungen vergessen

[RS232]
// RS232-Konfiguration: Baudrate, Datenbits, Stoppbits, Parität, Flusssteuerung
115200
8
2
0
1

Geschickt werden 30-50 Bytes, inzwischen sogar mehr. Ohne dass das LCD den eibPC einbremst läuft es nun schon ein paar Stunden (das 2. Stopbit hatte am Ende doch nichts gebracht).

Der Handshake war ja eigentlich nur zur Absicherung gedacht, d.h. wenn das Display komplexe Aufgaben abarbeitet, wird die Übertragung für ein paar ms angehalten. Notwendig ist es nicht, nur zeigt sich eben das beschriebene Problem am eibPC. Das sollte IMHO gerichtet werden, denn so kann man die Flusskontrolle nicht nutzen.

Schon ein einzelnes, zu viel übertragenes Byte, kann im Empfänger verloren gehen, mehrere sind aber ein wirkliches Problem und wenn die Übertragung anhält ...

Die Auslastung ist in den besagten Fällen niedrig, d.h. das Diagramm über 10sec zeigt ca. 10% (lässt sich direkt aus den übertragenen Werten bestimmen )

[enertegus]

Hm, in diesem Fall ist es natürlich schwierig, grundsätzlich ist die rs 232 Verbindung direkt ein Teil des Prozessors beziehungsweise des kernels. Ob wir das so viel machen können weiß ich gar nicht.

[saft6luck]

Die Hoffnung stirbt zuletzt ...

[saft6luck]

Gibt es denn schon Neuigkeiten?

[enertegus]

Ich habe mal hier intern nachgehakt: "Das RS232 Modul ist integraler Bestandteil des Prozessors, also kein externes Teil. Damit ist es vom Kerneltreiber abhängig und wenn es da tatsächlich bei 115kBaud mit Hardwarehanshake Probleme geben sollte, können wir nicht allzuviel machen."

[saft6luck]

Ich habe mal hier intern nachgehakt: "Das RS232 Modul ist integraler Bestandteil des Prozessors, also kein externes Teil.

Das ist doch aber eher normal, oder?

Damit ist es vom Kerneltreiber abhängig und wenn es da tatsächlich bei 115k Baud mit Hardwarehanshake Probleme geben sollte, können wir nicht allzuviel machen."

So wie es für mich aussieht, kann der Prozessor keinen wirklichen HW Handshake - er wird also "nur" über SW emuliert. Ist dem so?

Das wäre ja auch nicht wirklich ungewöhnlich, bis auf die Tatsache, dass man dann eher keine so hohen Geschwindigkeiten zulassen würde.
Wenn aber Events verloren gehen, dann sollte nicht die RS232 stehen bleiben. Das sieht wie ein Treiber-Bug aus.

Am Ende könnte man sich natürlich auch einen HW-Fehler vorstellen, der nicht gefixt werden kann. Dann ist der HW-Handshake aber generell unbrauchbar (oder wieder ein Geschwindigkeits-Thema).

Wer sagt denn aber, dass das Problem nur mit HW-Handshake auftritt?

Bevor man also entscheidet, dass nichts zu manchen ist, müsste doch erst einmal geklärt werden, welcher Fehler vorhanden ist, oder?

[saft6luck]

Gibt es denn hier schon mehr Informationen?

[enertegus]

Nur, was ich oben geschrieben habe. Wir binden das RS232 Modul über den Kernel ein. Kann sein, dass da nur die "Standard" Sachen funktionieren, immerhin auch so mit der FT12. Oder worauf genau bezieht sich die Frage?

[saft6luck]

Nur, was ich oben geschrieben habe. Wir binden das RS232 Modul über den Kernel ein. Kann sein, dass da nur die "Standard" Sachen funktionieren, immerhin auch so mit der FT12. Oder worauf genau bezieht sich die Frage?

1. Steht eigentlich alles im Thread, oder? Eine Menge Fragen sind da nicht beantwortet.
2. Ich will die RS232 standardkonform einsetzen. Was soll die Aussage "nur die 'Standard' Sachen" bitte bedeuten? Ist HW Handshake für dich nicht standardgemäß? Liegt es an mir, dass die RS232 hängen bleibt?
3. Habt ihr euch das Problem denn schon mal angeschaut und es nachvollzogen?

[enertegus]

2. Ich will die RS232 standardkonform einsetzen. Was soll die Aussage "nur die 'Standard' Sachen" bitte bedeuten? Ist HW Handshake für dich nicht standardgemäß? Liegt es an mir, dass die RS232 hängen bleibt?

Ok, Standard ist es schon (wenn man Normung meint). In der Hardware macht man aber meist ohne Handshake.

3. Habt ihr euch das Problem denn schon mal angeschaut und es nachvollzogen?

[/QUOTE]
An sich geht das, - du hast ja geschrieben, dass offenbar der Fehler auch erst nach einer gewissen Zeit auftritt - es kann dennoch sein, dass in irgendeiner bestimmten Konstellation hier was scheps läuft. Der Kernel ist aktuell, der Treiber auch. Es wird ein Hardware-Software-Linux Problem sein, ggf. auch mit der Auslastung des System, der Schedulerzeit, Auslastung der Schnittstelle, ggf. indirekt mit der Software, etc. zusammenhängen. Da lässt sich an dieser Stelle leider nichts machen, als eben die Treiber auf Aktualität zu prüfen, und selbst das ist kein Garant für eine absolut fehlerfreie Software.
Der Reset wurde eingebaut, weil hier mit dem HA7E immer wieder ein Hängen beobachtet wurde (auf der HA7E Seite). Ich glaube einen 1-Wire Busreset konnte man nur so (Reset des HA7E) erreichen.

[saft6luck]

Ok, Standard ist es schon (wenn man Normung meint). In der Hardware macht man aber meist ohne Handshake.

Verstehe dich da nicht. RS232 ist mit Handshake, das ist erst mal Standard. Wer keinen Handshake verwendet, ist entweder schnell genug (unter allen Umständen) oder ist nicht auf die Daten angewiesen.

Was aber sicher nicht passieren darf: Wenn einer sendet, der andere einbremst, dass dann der Sender einfach für immer stehen bleibt, obwohl wieder gesendet werden darf.

An sich geht das, - du hast ja geschrieben, dass offenbar der Fehler auch erst nach einer gewissen Zeit auftritt - es kann dennoch sein, dass in irgendeiner bestimmten Konstellation hier was scheps läuft. Der Kernel ist aktuell, der Treiber auch. Es wird ein Hardware-Software-Linux Problem sein, ggf. auch mit der Auslastung des System, der Schedulerzeit, Auslastung der Schnittstelle, ggf. indirekt mit der Software, etc. zusammenhängen. Da lässt sich an dieser Stelle leider nichts machen, als eben die Treiber auf Aktualität zu prüfen, und selbst das ist kein Garant für eine absolut fehlerfreie Software.

Ich habe gezeigt, dass generell etwas "scheps" läuft. Auf den Handshake wird zu spät reagiert -> am Ende sogar ein richtig gravierender Bug.

Zwischen "Kernel und Treiber sind aktuell" und "RS232 funktioniert" gibt es noch viele Möglichkeiten, Fehler zu machen, z.B. eine falsche Konfiguration etc.

Das Problem zu reproduzieren dauert maximal ein paar Minuten, das hat auch nichts mit bestimmten Konstellationen zu tun.

Unter Linux ist eine RS232 auch kein Hexenwerk und wenn da ein Problem im Treiber existieren sollte, kann man sich an die Entwickler wenden. Das ist weit weg von "da lässt sich ... leider nichts machen".