-
ich meine gelesen zu haben (kann mich aber irren), dass die readString-Funktion nur maximal bis zur Pufferlänge liest, ansonsten nur bis String-Ende erreicht ist, je nach dem, was kürzer ist.
Trotzdem könnte es auch beim Byte-weisen Lesen passieren, dass er versucht, bis zum fest definierten String-Ende zu lesen, aber ebenfalls dabei unterbrochen wird, wenn das USB-Kabel unterdessen gezogen wurde, und dann folglich ebenso hängt und später nicht mehr die Verbindung beim Wieder-Einstöpseln neu aufbaut...
In der Zwischenzeit hat aber der Arduino weitergesendet, und mittlerweile wurden tausend neue Strings mit neuen Werten rausgeschickt.
Wie müsste also der korrekte lese- und verbindungsstabile und wiedereintritts-sichere Code genau aussehen?
-
Irgendwie bin ich grade zu blöd im Netz ne Doku zu diesem TComPort zu finden ... alles was ich bisher gesehen habe deutet darauf hin dass du Timeouts einrichten musst damit er auch nach einem unvollständigem lesen definiert zurück kommt und sich dabei nicht komplett aufhängt.
Generell würde es Sinn machen das reine lesen des Com Port in einen steuerbaren Thread auszulagern, der einfach kontinuierlich versucht "ein paar" bytes zu lesen und die dann in einen von dir kontrollierten Puffer zu speichern, von dem du dann aus dem GUI Thread lesen kannst. Das war auch damals mein Ansatz gewesen aber ich musste mich noch der Windows API für COM bedienen.
Wenn beim Lesen Bytes ankommen hängst du die in deinen Puffer und inkrementierst entsprechend den "noch zu Lesen" Counter und kannst im Hauptprogramm dann zyklisch darauf warten dass genug Daten ankommen.
Wenn beim Leseversuch keine Bytes rauskommen und ein Timeout entsteht gehst du einfach wieder auf Empfang und wartest das nächste Timeout ab oder dass neue Daten kommen, in der Schleife sollte dann auch eine Abbruchbedingungn enthaletn sein, damit du den Thread von außen auch abbrechen kannst und ein Thread.yield() damit der Prozess die CPU nicht permanent beansprucht. So hast du keine Hänger in der GUI während des wartens auf neue Daten.
Aber wie man ein Timeout bei TComPort einrichtet kann ich dir nicht sagen ich habe damals noch mit der WIN API gearbeitet und diese brutalen Riesenstructs zum COM initialisieren verwendet.
-
ja, genau so mit extra Threads mache ich es auch beim Pi (mit pthread) - aber pthread gibt es nicht bei BCB, nur TThread, das aber extremst viel komplizierter ist, und da bin ich mir noch nicht einmal sicher, ob die ComPort-Funktionen thread- / dataracing-safe sind (faktisch laufen sie ja bereits autonom und parallelisiert in einem eigenen Thread).
In jedem Falle führen USB-Unterbrechungen zu ComPort Errors und Exceptions, die ich nicht händeln kann, und die bislang einen Wiederaufbau verhindern.
Wie auch immer, theoretisch kann ich die Ideen von dir und Siro schon befürworten - nur: wie programmiert man sie genau?
-
Exceptions behandelt man in sog. Try{} Catch(...){} Blöcken, wo im Try der Code kommt der den Fehler verursacht und im Catch der Code der die übergebene Exception behandelt und entsprechenden Maßnahmen einleitet um das Problem zu behandeln
Wieder einmal kann ich leider nicht sagen wie exakt das in Borland C++ funktioniert, aber du kannst erstmal mit einer generellen Exception-Klasse beginnen und ausgeben um was für eine Subklasse es sich handelt und dann hinter einem Try mehrere Catch Blöcke zu der jeweils entsprechenden Exceptionklassen formulieren um auf verschiedene Ereignisse zu reagieren
Zum Hängen wegen zu wenig Daten brauche ich die Doku, wenn du eine Online verfügbare hast zu TComPort dann guck ich mir das mal an aber ich finde einfach nichts
-
theoretisch weiß ich schon, was try...catch ist und tut, die Frage ist, wie man damit welche BCB-Errors und Exceptions genau händelt ;)
-
Fang erstmal mit der Basisklasse für Exceptions an und lass sie dir so ausführlich wie möglich ausgeben (haben meist eine dump oder print funktion) und poste die unterschiedlichen Fehler mal, dann kann man da weiter gucken :)
-
Weitere Dokus zum ComPort kenne ich ja leider auch nicht, ich kenne noch nicht mal Namen/Syntax der Errors und Exceptions, keine dump oder print funktion, und wie man ihr Auftreten programmiert und abfängt.
Ich brauche hier also schon genauen Code.... 8)
-
https://docs.microsoft.com/de-de/win...texceptioncode
https://docs.microsoft.com/de-de/win...ioninformation
das als printout in einem Catch(...) (das "(...)" müsste glaube ich so funktionieren)
ob das so 1:1 in BCB funktioniert kann ich nicht versprechen, online doku ist echt mager was Borland angeht... ziemlich Blöd für die Vermarktung eigentlich
-
es geht nicht um Microsoft-Code, sondern um den genauen Borland ComPort Code, der nutzt keine Windows-Basisfunktionen, sondern eigene (gleiches gilt auch für die print Funktionen im Formular) ;)
Installiere doch mal den C++ Builder und teste mal selber 8)
-
du weist genau wie ich das ding hasse XD SOrry der kommt mir nicht aufn PC schon allein weil man keine Doku dafür hat, hatte gehofft ich könnte was helfen sorry :(
