RS232 nicht Echtzeitfähig??

[KnochenM4RK (Gast)]

Moin Moin..

ich hab da mal ein problem, weiß aber nicht wie/ob man das lösen kann.
Und zwar:

Ich habe ein Programm das Daten über eine COM-Schnittstelle ausliest
und weiterverarbeitet. Die Daten von der COM-Schnittstelle MÜSSEN
innerhalb einer bestimmten Zeit (1ms) abgeholt werden, sonst gehen sie
verloren und alles ist für die Katz!! Bisher hatte ich ein ein DOS
Programm das für mich erfolgreich gearbeitet hat. Aber das wollte ich
jetzt in Windows portiern. Und das ist das Problem:

In Windows kann ich nicht schnell genug den COM-Port ansteuern (die
Daten "runterholen"), sodass die Daten verloren gehen.
Fuchelt Windows beim COM-Port so viel rum??
Ist es möglich windows (oder was auch immer) so umzukonfigurieren das
der Port so schnell ist wie unter DOS???

würe mich über Vorschläge zur lösung sehr freuen.

mfg KnochenM4RK

[Peter (Gast)]

Die serielle Schnittstelle hat doch einen Inputbuffer dessen Grösse du
festlegen kannst. Da werden die Zeichen reingeschrieben und du liest
ihn dann einfach aus und gut is.

Peter

[Bri (Gast)]

Da Windows ein Multitaskingsystem ist, ist nunmal ncht garantiert, dass
dein Programm immer zur richtigen Zeit drankommt. Du kannst aber für
das Abholen der Daten die Prozesspriorität raufsetzen. Schau dir mal
die Funktionen SetThreadPriority und SetPriorityClass in der Hilfe an.

[Rufus Τ. F. (rufus)]

Zusätzlich zum Empfangspuffer des Treibers der seriellen Schnittstelle
hat auch die serielle Schnittstelle des PCs selbst einen Empfangspuffer
- Zeichen gehen erst dann verloren, wenn dieser Puffer ("Fifo")
überläuft und der Treiber des Betriebssystems die Daten nicht schnell
genug abholt.

Das aber ist auf einem auch nur mäßig aktuellen Windows-Rechner
ziemlich ausgeschlossen; bereits ein 66 MHz-486er konnte unter Windows
NT (3.5 oder 3.51) zwei serielle Schnittstellen simultan mit 115200
Baud bedienen, ohne daß Daten verloren gingen.

Es ist zu befürchten, daß die Programmierung von "KnochenM4RK" noch
etwas Optimierungspotential aufweist.

[Blackbird (Gast)]

@KnochenM4RK, zeig' doch mal das Programm oder den Programmausschnitt.


Blackbird

[HD_ (Gast)]

also, bei den angaben zum 66MHZ Rechner wäre ich vorsichtig !!!

Habe schon Programme geschrieben, die auf einem 500 MHZ Rechner
(Pentium) liefen und Windows (NT) hat es nicht geschafft die Daten
rechtzeitig aus dem FIFO zu holen, nämlich dann wenn der Kernel z.B.
mit dem verschieben eines Fensters beschäftigt war. Besonders auf
Rechnern mit ner schlechten Grafik-Karte war es zu erkennen...

Gruß

[Tobi H. (tobi-)]

Ich dacht immer die serielle Schnittstelle würde Interrupts benutzen.
Damit sollte eine von dir beschriebenes Verhalten eigentlich nicht
passieren.

[T. Stütz (Gast)]

@Tobi H.

"Ich dacht immer die serielle Schnittstelle würde Interrupts
benutzen."

Stimmt, manche Grafikkarten haben aber auch einen Interrupt (meist 10)
dieser liegt von der Priorität her zwischen IRQ 2 und IRQ 3/4
damit kann ein Interrupt der Grafik-Karte den Interrupt der COM2/1
ausbremsen.

Auch deine Tastatur kann deinen COM-Port - Interrupt bremsen (IRQ1)
OT: was für ein Hirnakrobat war das den, der dem langsamsten "Gerät"
sprich Mensch einen hochpriorisierten Interrupt spendierten (noch vor
dem Diskettenlaufwerk).

Gruss

[HD_ (Gast)]

Einer der cleversten ;-)

Aber bei den heutigen Prozessoren sollte das Thema eigentlich
ausgestanden sein.

Das beschriebene Verhalten habe ich seit dem es Rechner 1GHZ gibt unter
Windows nicht mehr gesehen !

Und wenn man einen Rechner benutzt der weniger als 500 Mhz hat dann
sollte man besser unter DOS programmieren

[Karl H. (kbuchegg)]

Das Verhalten hab ich auch frueher nicht gesehen.
Und das auf einer VAX 780 die ca. 40 Terminals ueber
RS232 servisiert hat.
Das Geheimnis: Handshaking aktivieren.

[HD_ (Gast)]

;-)

Danke für den Tip !

hätte ich auch gerne gemacht ABER dazu müssen das beide Seiten
Unterstützen was in meinem Falle (PC-Seite) kein Problem gewesen wäre,
nur die Gegenstelle konnte man nicht einfach umstellen !

Gruß

Achja, ums klarer zu formulieren: hier hilft nur HW-Handshake
SW-Handshake löst das Problem leider nicht !!!

[Unbekannter (Gast)]

@KnochenM4RK:

> Bisher hatte ich ein ein DOS Programm das für mich erfolgreich
> gearbeitet hat. Aber das wollte ich jetzt in Windows portiern.
> Und das ist das Problem:

Du wirst doch hoffentlich nicht die serielle Schnittstelle mit den
gleichen Methoden wie unter DOS ansprechen, sondern die
Windows-Funktionen dafür verwenden?

[Rolf F. (Gast)]

Es gibt Echtzeitbetriebssysteme, die die serielle Schnittstelle mit
Echtzeitfunktionen ansprechen, beispielsweise Linux +RTAI.