mikrocontroller.net

Forum: PC-Programmierung Direkt auf RS232 Buffer zugreifen


Autor: Leo F (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe eine Kommunikation zwischen einem Controller und einem PC über
die RS232 Schnittstelle. Der Controller sendet in zeitlichen Abständen
von etwa 10 - 20 ms eine 3 Byte lange Nachricht an den PC. Als
Empfangsbuffer für die RS232 Schnittstelle am PC habe ich deshalb 3
Bytes eingestellt sowie ein timeout von 5 sec.

Nun fällt mir auf, dass der PC nicht so schnell auf die Nachricht des
Controllers reagieren kann. D.h. wenn ich 4 Nachrichten vom uC gesendet
habe, kommt gerade mal eine an. Dadurch wird meine Kommunikation
ziemlich träge.

Wie umgeht man ein solches Problem? Kann ich vielleicht den Buffer
größer machen und ohne interrupt die Daten direkt auslesen? D.h. das
ich mir die Daten einfach aus dem Buffer hole und selbst wieder diesen
lösche, ohne auf das RS232 interrupt zu warten? Ich programmiere auf
dem PC mit Visual Basic .NET und greife hierbei auf die RS232
Schnittstelle über die kernel dll zu.

Ich muss leider in 4 Tagen fertig sein und möchte die Übertragung
optimieren. Ich bin für jede Hilfe und jeden Ratschlag sehr dankbar.

Viele Grüße an alle

Leo

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach den Puffer sehr gross (z.b ein paar kb) und lese immer nur 3 Byte
auf einmal aus. Diese werden durchs lesen ja automatisch aus dem Puffer
gelöscht. So geht ganz sicher nichts mehr verloren. Und setz den Timeout
tiefer.

Autor: Leo F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tobi,

ich probier das gleich mal aus. Vielen Dank für die schnelle Antwort!

Viele Grüße

Leo

Autor: Karl heinz Buchegger (heinzi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kommt mir oberfaul vor.
Ein GHz getakteter PC soll nicht in der Lage sein, alle 20 ms ein paar
bytes zu verarbeiten? 20 ms sind eine halbe Ewigkeit.

Frage: Hast Du Handshaking aktiviert? Welches, XON/XOFF oder
Hardware-handshaking? Handhaking soll genau das verhindern, dass der
Sender sendet, waehrend der Empfaenger noch nicht zur Datenaufnahme
bereit ist.

Autor: Leo F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein ein Handshaking hab ich leider noch nicht implementiert. Mein
problem ist, dass mein Rechner mit anderen Sachen zwischendurch
beschäftigt ist. Wie funktioniert das mit dem Handshaking? Ich vermute,
dass ich eine zusätzliche Leitung habe, die z.B. auf High ist, wenn der
PC für einen Datenempfang bereit ist. Leider ist das nur meine Theorie.
Kann das irgend jemand bestätigen oder verbessern?

Vielen Dank für eure Hilfe.

Gruß
Leo

Autor: pittbull (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist richtig. es gibt verschiedene methoden. die gängigste ist wohl
RTS/CTS. wenn man keine leitung frei hat kann man auch ein
software-handshaking machen (XON/XOFF). der windows-interne
rs232-treiber kann beides

Autor: Karl heinz Buchegger (heinzi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nein ein Handshaking hab ich leider noch nicht implementiert.

Dann hast Du genau hier Dein Problem, warum Dir zwischendurch
immer wieder mal Daten verloren gehen.

> Mein problem ist, dass mein Rechner mit anderen Sachen zwischendurch
> beschäftigt ist.

Deckt sich genau mit der Fehlerbeschreibung

> Wie funktioniert das mit dem Handshaking? Ich vermute,
> dass ich eine zusätzliche Leitung habe, die z.B. auf High ist,
> wenn der PC für einen Datenempfang bereit ist.

Das ist dann Harware-Handshaking.
Beide Teilnehmer an der Kommunikation haben eine eigene Leitung
zum jeweils anderen, mit der sie mitteilen, dass sie jetzt
bereit sind Daten anzunehmen oder auch nicht. Ist die Gegenstelle
nicht bereit, dann sendet der Sender auch nicht.

Die andere Moeglichkeit ist Soft-Handshaking. Dazu sind im
ASCII Code eigene Zeichen definiert: XON und XOFF

Dein PC empfaengt Daten. Nachdem du weisst, das er jetzt eine
Zeitlang beschaeftigt sein wird, sendest Du sofort ein XOFF
and den Sender. Dieser sendet darauf hin nichts mehr. Erst
dann wenn der PC wieder bereit zum Empfang ist, schickt er
erstmal ein XON los und wartet auf Daten. Die Gegenstelle empfaengt
das XON und hat damit die Freigabe zum senden. usw.

Das ganze ist so, wie wenn Deine Freundin Dir einen Roman erzaehlt,
du aber momentan nicht aufnahmefaehig bist. Dann sagst Du:
"Einen Moment bitte", machst das was Du grade tust fertig, und
forderst sie mit "So, jetzt" zum 'senden' auf.

Ist doch immer wieder erstaunlich wie sich kompliziert klingende
Computer-Konzepte im realen Leben wiederfinden :-)

Autor: AndreasH (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Meinung nach stimmt da was anderes nicht.
Bei 3 Byte kann da so schnell nichts zuviel sein. So langsam wird der
Rechner nicht sein, dass da der interrupt-Buffer des PC bei 4 x 3 Bytes
zuläuft. Da gehen einige Hundert Byte rein.

Um genaueres zu sagen müsste man mal was von dem Code sehen. Die Frage
ist z.B. ob Du nach jedem Lesen den Port wieder neu initialisierst.
Dann ist der Rest natürlich weg.
Macht Dein Programm noch andere Sachen oder laufen auf dem PC noch
andere Programme?
Ich mache schon seit Jahren mit dem PC und der seriellen. Das ging
bisher nie schief. Selbst wenn das Programm zum Zeitpunkt des Empfangs
was anderes macht bleiben die Daten erhalten und werden erst mit der
ReadFile-Funktion abgeholt.
Wie gesagt, ohne Code zu sehen ist das Rätsel raten.

Grüße
Andreas

Autor: T. Stütz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@AndreasH
>Bei 3 Byte kann da so schnell nichts zuviel sein. So langsam wird der
>Rechner nicht sein, dass da der interrupt-Buffer des PC bei 4 x 3
>Bytes zuläuft. Da gehen einige Hundert Byte rein.

Also soweit ich weiss hat die Hardware (meist 16550 Kompatibel)
insgesammt 16 Bytes FIFO also keine 100 !

Danach kommt der Softwarepuffer von Windows/BIOS aber erst muß er sich
die Bytes aus der Hardware lesen (es ist möglich den Interrupt erst bei
14 Bytes zu bekommen), dann hat mann 2 Bytes Zeit den Puffer zu leeren.
Da du noch nicht gesagt hast mit welcher Baudrate dies geschieht
gehe ich von ca.19200 aus => 2 Zeichen sind dann etwa 1ms.

Wenn du dir mal anschaust wie lange ein Zugriff auf einen Sektor der
Diskette (400ms) oder Festplatte (10-20ms) dauert ist vielleicht
verständlich das es da zu Problemen kommen kann.

Dies ist jetzt eine etwas überzogene Darstellung trotzdem trifft sie
den Kern der Sache. Versuch mal bei MSDN herauszufinden wie schnell
die serielle Kommunikation von MS Garantiert funktioniert.

Die einzige Info diesbezüglih ist für Win3.1 und lautet <=19200Baud.

falls ich da was übersehen habe bitte um info.

Gruss

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interrupts werden aber eigentlich recht flott ausgeführt und für einen
aktuellen PC sind 1-2ms eine Ewigkeit. Vondaher sollte dadurch
eigentlich nichts verloren gehen

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Treiber für die serielle Schnittstelle hat wiederum einen Puffer,
der beim Auftreten eines Interrupts mit Daten gefüllt wird. Da das auf
Devicetreiberebene geschieht, treffen hier die diversen verzögernden
Aspekte des Windows-Schedulers nicht zu. Selbst ein sehr altes System
(486er) unter einem ernstgemeinten* Windows ist in der Lage, serielle
Schnittstellen mit einer Datenrate von 57600 oder 115200 Baud zu
bedienen, ohne daß Daten verlorengingen. Natürlich muss sichergestellt
werden, daß der Puffer des Devicetreibers auch zeitig geleert wird; die
Usermode-Applikation sollte sich dabei also nicht zu "dumm" anstellen,
beispielsweise in ein und demselben Thread  GUI-Ausgaben und die
Kommunikation mit der seriellen Schnittstelle abwickeln.

Das alles ist unter den Hobby-Frickel-Windows-Versionen** sicherlich
anders, da hat MS (noch) weniger Wert auf vernünftige Funktion gelegt
als bei NT.

Natürlich sieht das ganze auch anders aus, wenn man unter den
ernstgemeinten Windows-Versionen noch mit DOS-Programmen hantiert; es
gibt wohl immer noch Exoten, die sowas machen. Die Performance der
simulierten seriellen Schnittstelle der VDM ist zwar von NT-Version zu
NT-Version immer besser geworden, aber praktisch immer noch oft
unbrauchbar.

*) NT ab Version 3.1; das schließt Windows 2000 und XP (NT 5.0 und 5.1)
mit ein
**) 16-Bit-Varianten sowie alle Aufgüsse von Windows 95

Autor: Leo F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich glaub ich hab meine Schwachstelle gefunden. Sobald ich die
Daten über RS232 einlese, sende ich über eine andere Schnittstelle
Daten an ein drittes Modul. Diese Abarbeitung dauert nun so lange, dass
wenn ich dann wieder über die RS232 Schnittstelle Daten abfrage, wieder
x Nachrichten angekommen sind. Die RS232 Kommunikation schließe erst
wenn die Kommunikation abgeschlossen ist! Die Baudrate beträgt bisher
nur 300 baud.Die Übertragung funktioniert im Prinzip nun ganz gut.

Vielen Dank

Gruß
Leo

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.