FIFO Puffer der COM-Ports macht Probleme

[christian.noeding]

Hallo liebe Delphi-Gemeinde,

jetzt habe ich nach etlichen Monaten wieder mal ein Problem, bei dem ich leider keine eigene Lösung finde und das einen Eintrag hier im Forum rechtfertigt :) . Ich bin immer noch (unter anderem) dabei an meinem PC_DIMMER Projekt zu programmieren, was bislang auch sehr reife Früchte trägt. <Werbung> Ich bin mittlerweile so weit, dass das Programm viele Funktionen aus dem professionellen Lichttechnik-Bereich beherrscht (Bühnenansicht, Musikgetriggerte Showabläufe, Pluginstruktur, etc.). http://www.pcdimmer.de </Werbung>

Problembeschreibung: Nun habe ich ein Hardwareproblem mit der seriellen Schnittstelle. Ich gebe meine Daten binär über den Comport aus und nutze dafür die Comport-Komponente von Marco Cocco (wird hier im Forum öfters verwendet). Die Daten werden mit 115,2 kBaud gesendet und es häufen sich sehr viele Daten an, da die Kanalwerte der Scheinwerfer z.T. sehr häufig aktualisiert werden. Jetzt habe ich bei einem Stresstest (viele schnelle Lauflichter parallel, etliche Kanalwertänderungen nacheinander) festgestellt, dass bei aktiviertem FIFO-Puffer der COM-Ports (egal ob intern oder per USB-2-RS232-Adapter) mein Programm nach ca. 10-20 Minuten abstürzt. Nach ewigem Fehlersuchen habe ich dann mal den FIFO-Puffer verzweifelt ausgeschaltet und nun läuft alles problemlos etliche Stunden ohne Absturz.

Endlich meine Frage:
Wie kann ich den FIFO-Puffer automatisch ausschalten, oder wenigsten Überprüfen, ob er ausgeschaltet ist und ggf. eine Warnmeldung ausgeben? Ich habe mal gesucht, aber bin hier im Forum auf nichts gestoßen und Google gibt auch nur darüber Infos, dass der FIFO-Puffer bei manchen prof. Messgeräten der Elektronik Probleme machen kann (schätze also gleiches Problem wie bei mir). Es werden wie gesagt sehr schnell viele Datenpakete gesendet (6 Bytes pro Wertänderung. Es wurden beim Test ca. 40 Kanäle geändert. Pro Sekunde passiert das ca. 4 bis 10 Mal, was irgendwas um die 10 Änderungen/s *40 Kanäle *6 Bytes *8 Bit=19200 Bit/s bedeutet. Dazu dann die Start-/Stopbits des RS232-Protokolls und dann kommt der FIFO-Puffer vermutlich nicht mehr mit -> Folge ist wahrscheinlich eine Art Zugriffsverletzung)

Ich nutze Delphi 7 und etliche Komponenten (Indy, Bass, etc.). Die Comportfunktionen sind jedoch in einem externen Plugin ausgelagert.


Zweite Frage (eher nebensächlich):
Mein Programm sucht automatisch freie Comports und wählt diese aus. Gibt es eine Möglichkeit die internen Modems von dieser Suche/Aktivierung auszuschließen? Vor allem bei Laptops mit internem Soft-Modem stürzt mein Programm nämlich immer ab, wenn der Comport des Modems ausgewählt wird (Herstellerunabhängiges Problem). Der Fehler tritt nur beim Beenden des Programmes auf.


Das Projekt ist Open-Source, sonst würde ich solche Fragen hier wahrscheinlich nicht stellen - wäre nett, wenn mir jemand unter die Arme greift ;-)


Besten Dank,
Christian!


PS (auch nebensächlich und zudem Off-Topic): falls jemand ein paar Delphi-Funktionen für ein Darstellen von Wavedaten über die BASS-DLL (oder auch anders) hat, wird herzlich um Hilfe gebeten. Ich habe zwar eine Wave-Darstellung, jedoch wird die Auflösung beim hineinzoomen nicht angepasst, sodass ich nur die Darstellung auseinanderziehe und Lücken bekomme.
Also aus: .|...||..|... wird . | . . . | | . . | . . .

[christian.noeding]

Hallo...

da das ja ein sehr spezielles Thema ist, schiebe ich es nur einmal, in der Hoffnung, dass jemandem noch etwas einfällt.

Sodenn: *schieb*

[Gruber_Hans_12345]

also, ich mach teils auch recht viel mit der seriellen schnittstelle (allerdings greife ich direkt darauf z, ohne irgendwelchen umweg von komponenten)

Das der FIFO Puffer schuld ist, wage ich zu bezweifeln, eher wird das ein Seiteneffekt sein.

zuerst mal, verwendest du Hard/Softwareprotokoll?

Haste mal ein Fehlerlog erstellt? also mal geguckt, wo der Fehler auftritt? Mit JCL, eurekalog oder sonstigen Programmen
Kommt der Fehler auch in der IDE?

die Komponente verwendet ja vermutlich Thread, ist bei dir alles Threadsafe?

[christian.noeding]

Hallo und danke für die Antwort :)

Zitat:

Das der FIFO Puffer schuld ist, wage ich zu bezweifeln, eher wird das ein Seiteneffekt sein

Nun, nachdem ich den Puffer komplett deaktiviert hatte trat der Fehler nicht mehr auf. Ich sende die Daten wirklich sehr schnell hintereinander, sodass teilweise die Schnittstelle nicht hinterherkommen kann.

Zitat:

zuerst mal, verwendest du Hard/Softwareprotokoll?

Was meinst du genau damit? Ich verwende die Schnittstelle Unidirektional ohne Handshaking. Hardware-/ und Software-Flowcontrol sind beide aus, 8 Datenbits, 1 Stopbit, keine Parität bei 115,2kBaud.

Zitat:

Haste mal ein Fehlerlog erstellt?

Eigentlich sollten alle Fehler von MadExcept abgefangen werden, welches in mein Projekt eingebunden ist. Der Absturz ist hier wirklich als "Absturz" zu sehen, da die komplette Anwendung mit allen Fenstern schalgartig verschwindet (da ich das Fehlerprotokollieren von Microsoft ausgeschaltet habe, kommt keine "Problembericht senden" Mitteilung). Die Anwendung hat keine Möglichkeit auf irgendwas zu reagieren. Wie kann ich den Fehler in der IDE nachstellen? Ich kann ja leider nicht genau bestimmen, wo er auftritt, da die Senderoutinen 99% der Zeit gut funktionieren.

Zitat:

die Komponente verwendet ja vermutlich Thread, ist bei dir alles Threadsafe?

Die Komponenten verwendet denke ich keine Threads. Jedenfalls steht im Sourcecode des TComport-Treibers non multithreaded serial I/O. Habe auch sonst keinen Hinweis auf Threads festgestellt. Meine Anwendung nutzt auf jedenfall einige Threads, jedoch sollten diese nicht für den Absturz verantwortlich sein - habe versucht darauf zu achten, dass die Threads sich nicht beißen und Daten schön in globale Variablen kommen.


Das Problem ist aber nachweislich behoben, wenn der FIFO-Puffer deaktiviert ist, also würde mir als Workaround da eine Detektierung des FIFO-Status weiterhelfen. :)


Aber vielleicht fällt dir ja noch was ein :)
Danke schonmal - ciao!

[Gruber_Hans_12345]

normalerweise kannste ja nicht zu schnell senden, da ja die seriellen treiber das unterbinden, du kannst bei einer 115k Verbindung nicht schneller als 115k senden, das geht einfach nicht. Die Daten kommen IMMER mit maximal 115k raus.

Die kannst zwar schneller an die Komponente schiciken, aber dann kommt das ganze entweder in den FIFO, oder in den Softwarebuffer der seriellen schnittstelle oder in einen Buffer von der Komponente, aber fakt ist, aus dem PC kommt maximal 115k raus.


was horcht den da auf der anderen seite?

wie man den FIFO abdrehen kann, weiss ich auch nicht, den software buffer der schnittstelle kannst mit SetupComm einstellen.

aber ich bin nach wie vor sehr sicher, das es nichts mit dem FIFO zu tun hat, sondern würde auf ein Thread Problem tippen, sicherheitshalber könntest du das programm ja mal auf einem anderen rechner laufen lassen (falls wirklich dein FIFO was haben sollte)

und wenn du den FIFO deaktivierst, verhält sich dann natürlich auch das ganze Programm anders, da die daten dann zb nicht mehr so schnell geschickt werden können, und die schreib befehle viel öfters abbrechen, und dadurch auch das verhalten den Threads, der schreibt anders ist.
Guck dir mal die schreiberoutine an, und speziell alle synchronisations sachen, ob alles threadsafe ist

[christian.noeding]

Zitat:

Die kannst zwar schneller an die Komponente schiciken, aber dann kommt das ganze entweder in den FIFO, oder in den Softwarebuffer der seriellen schnittstelle oder in einen Buffer von der Komponente, aber fakt ist, aus dem PC kommt maximal 115k raus.

Das ist schon klar - ich meinte damit, dass ich schneller sende (an die Schnittstelle), als diese es physisch rausbringen kann.

Zitat:

was horcht den da auf der anderen seite?

Das ist ein kleiner Mikroprozessor von Atmel, der eine Lichtanlage steuert.

Zitat:

sicherheitshalber könntest du das programm ja mal auf einem anderen rechner laufen lassen (falls wirklich dein FIFO was haben sollte)

Habe ich ja. Resultat: nach ca. 10 Minuten Stresstest (also ununterbrochenem Datensenden) bricht die Software zusammen. Ich habe das ganze auf insgesamt drei Rechnern getestet (zwei Laptops und einem Desktop).
Nachtrag: jeweils bei deaktiviertem FIFO läuft alles ohne Probleme... egal, ob USB-2-RS232 oder direkt eingebauter COM-Port.

Zitat:

Guck dir mal die schreiberoutine an, und speziell alle synchronisations sachen, ob alles threadsafe ist

Das werde ich machen... da das Program aber mittlerweile so komplex ist, werde ich das heute nicht mehr schaffen. Mal schauen, ob ich nicht doch was finde.


Besten Dank und schöne Grüße,
Christian

[shmia]

Es gibt einen FIFO für Senden & Empfangen!!
Üblich sind 16 Bytes FIFO.
Der Sendepuffer (=Übertragungspuffer) dürfte auf deine Software eigentlich keine negativen Auswirkungen haben.
Beim Empfangspuffer sieht das etwas anderst aus.
Hier kann es passieren, dass du grössere Datenbröckelchen am Stück bekommst und sich deine SW daran "verschluckt".
Ich würde im Gerätemanager mal nur den Empfangspuffer auf Grösse 1 reduzieren, aber den FIFO sonst aktiv lassen.

[Gruber_Hans_12345]

Zitat:

Zitat von shmia

Beim Empfangspuffer sieht das etwas anderst aus.
Hier kann es passieren, dass du grössere Datenbröckelchen am Stück bekommst und sich deine SW daran "verschluckt".
Ich würde im Gerätemanager mal nur den Empfangspuffer auf Grösse 1 reduzieren, aber den FIFO sonst aktiv lassen.

ja das ist klar, aber auf grund

Zitat:

Was meinst du genau damit? Ich verwende die Schnittstelle Unidirektional ohne Handshaking. Hardware-/ und Software-Flowcontrol sind beide aus, 8 Datenbits, 1 Stopbit, keine Parität bei 115,2kBaud.

vermute ich mal, das er nur schreibend auf den COM Port zugreift, und daher der Empfanspuffer nicht wirklich relevant ist

aber ansonsten bin ich auch deiner meinung, das der FIFO eher positivere wirkungen erzielen soll (bis darauf, das die schreibvorgänge schneller abgeschlossen werden als ohne)

[christian.noeding]

Richtig, ich schreibe nur mit dem Comport. Ich habe außerdem nur den GND-Pin und den TXD-Pin der Schnittstelle belegt. Alle anderen Pins sind offen.

Kann es eine Art Buffer-Overflow geben, wenn ich mehr Daten schreibe, als der FIFO-Puffer groß ist? Die 16 Bytes sind aus bekannten Gründen der Geschwindigkeit und geforderten Aktualität der Daten auf diese Größe reduziert, sodass nicht trotz Beenden der Schnittstelle weiter Daten rauspurzeln. Jedoch ist jedes meiner Datenframes genau 6 Bytes groß. Dieses 6-Byte-Datenframe wird jetzt ein vielfaches pro Sekunde geschrieben. Ich kann leider nicht messen, wie häufig pro Sekunde. Wenn ich jetzt die Schnittstelle mit aktiviertem FIFO-Buffer mit Daten flute - wie verhält sich der FIFO-Puffer, wenn der voll ist?

[Gruber_Hans_12345]

warum verwendest du eigentlich kein hardware protokoll? rs232 ohne hardwareprotokoll birgt immer risiken.

im prinzip (hoffe das ichs noch richtig weiss ...)
du schickst die daten ja mit WriteFile an die serielle schnittstelle, diese daten werden zuerst in de software buffer von windows geschrieben (ist meist so 1k groß, und kann mit SetupComm eingestellt werden) windows schreibt diese dann in den FIFO Buffer rein, und von dort gehts dann raus ...
ist der FIFO und der Softwarebuffer voll, dann blockiert der WriteFile Befehl, und wartet solange, bis genug Platz im Buffer ist das die daten geschickt werden können.

Aber es kommt natürlich drauf an, wie auf die COM zugegriffen wird (gibt da ja auch noch den Overlapped Mode und so)