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
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.
Hallo Tobi, ich probier das gleich mal aus. Vielen Dank für die schnelle Antwort! Viele Grüße Leo
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.
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
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
> 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 :-)
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
@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
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
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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.