RS232 nicht Echtzeitfähig??

KnochenM4RK Gast #295733
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Bri Gast #295735
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Rufus Τ. F. Persönliche Seite #295736
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
HD_ Gast #295738
Lesenswert?
• ▲
▼ 
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ß
Antwort Zitieren Bearbeiten Löschen Beitrag melden
T. Stütz Gast #295740
Lesenswert?
• ▲
▼ 
@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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
HD_ Gast #295741
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
HD_ Gast #295743
Lesenswert?
• ▲
▼ 
;-)

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 !!!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Unbekannter Gast #295744
Lesenswert?
• ▲
▼ 
@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?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren