comEventRxOver bei MSComm in VB bei Kommunikation mit M32

[robotxy]

Hi!
Seit längerem kommuniziere ich jetzt schon über die RS232 Schnittstelle mit meinem M32 via dem MScomm Control in VB. Ich muss viele Daten vom M32 zum Computer "schaufeln". Leider fehlen immer Teile und als ich mir das CommEvent ausgeprinted habe, hatte ich dauernd ein "comEventRxOver". Das heist ja das der Empfangsbuffer voll ist. nur wie kann ich das umgehen, um eine sichere Datenkommunikation gewährleisten?
Achja ich lese den Buffer immer beim OnComm Ereignis aus.
Hoffe jemand kann mir helfen,
MfG
Rasmus

[PicNick]

Am einfachsten und doch Standard ist die XON/XOFF methode.
Jeder (AVR + PC ) der gerade den Hals voll hat, schickt XOFF (19), darauf sendet der andere nix, bis XON(17) kommt.
das ist das, was beim Terminal als "Flußsteuerung" verwendet werden kann

[robotxy]

So, frage jetzt den Buffer über einen Timer ab, dann habe ich keinen comEventRxOver mehr, aber trotzdem fehlen noch Teile(manchmal auch nur ein Buchstabe), sollte ich vllt die Baudrate ändern? (M32, 9600 Baud, 16MHZ)?
Oder gibt es noch eine andere Möglichkeit eine sichere Kommunikation zu gewährleisten?
MfG
Rasmus

bei der Baud rate kann das nur ein Programmier fehler sein.

Ich fahre den AVR mit 16 MHz bei 19200 Baud
und zwischen zwei PC's mit 115000 Baud und keinen Fehlenden Buchstaben.

Alles mit einer drei draht verbindung.

Leider kenne ich das MScomm.ocx nicht drum weiß ich nicht genau wo der fehler sein könnte.

Also habe jetzt ne Stunde mit dem ocx gespielt aber ich glaube das taugt einfach garnix.

Sorry

[robotxy]

Wieso wie wertest du denn die Serielle Schnittstelle aus?
Wäre nett wenn du den Code mir schicken könntest.
MfG
Rasmus

[SprinterSB]

Versuch mal mit nem Quarz mit dem du die genaue Baudrate bekommst, etwa mit 11.0592 MHz.
Die verwende ich mit AT90S2313 broblemlos bei 115200 Baud, allerdings mit Handshakeleitungen CTS und RTS um eben diesen Datenverlust zu vermeiden.
Bei XON/XOFF kannst du nicht alle Binärwerte schicken wie vorher, das ist eher was für ASCII, da muss also dein Protololl drauf passen.

Anstatt die Baudrate zu ändern würd ich auch mal versuchen, die Datenbytes in grösseren Zeitabständen zu schicken. Die PC-seitige FiFo ist mit 16 Bytes, dicht. Der PC ist zwar schneller als dein AVR, hat aber mächtig anderes Zeug am Hals...