Arduino am Windows-PC: GUI zur Fernsteuerung und zum Messwerte anzeigen (per USB)

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 :(

danke, aber ohne eigene Installation zum vorher selber-testen wird das mit den Hilfevorschlägen wohl leider nicht so schrecklich viel fruchten...


PS,
habe jetzt probiert:

Code:

---

void __fastcall TForm1::ComPort1Exception(TObject *Sender,
      TComExceptions TComException, AnsiString ComportMessage,
      __int64 WinError, AnsiString WinMessage)
{

    try {  ComPort1->Close();  }
    catch (...) {  }

    try { Application->Initialize(); }
    catch (...) {  Application->Terminate();  }

}

---

damit ist das Beenden bei USB-Unterbrechung leichter möglich ohne dass es sich aufhängt (aber auch nicht 100% korrekt), und springt auch sonst leichter raus, wenn Fehler schon beim 1. Verbinden passieren... :-/

Ich habe mir mal den Code von ComPort genauer angesehen.

Der originale Code "Cport.Pas" ist in Delphi programmiert, (wenn es das Original ist) 3652 Zeilen Code
Den Code kann ich "teilweise" gut nachvollziehen, da ich lange Zeit mich mit Delphi beschäftigt habe
und selbst erst eine Serielle Komponente in Lazarus auf Basis der Windows API programmiert habe.

Wie diese UNIT jetzt nach C++ convertiert wird, habe ich aber ehrlich gesagt nicht verstanden.
Habe ja auch bisher nie mit Borland Builder C++ gearbeitet.

Im Code selbst sind SEHR viele Funktionen implementiert, auch Timeouts usw,

Wenn die C-Componente alle Funktionen bietet wie das Delphi Original, dann fehlt es da eigentlich an Nichts.
Wobei ich sie nicht für Optimal halte beim Empfangen, (Geschmackssache)

Ich glaube die Funktion WaitForSingleObject könnte da ein Problem werden,
sie wird unter anderem beim Lesen aufgerufen mit einer "unendlichen" Zeit

Das asynchrone Lesen ist in der Komponente erheblich anders programmiert als bei mir
und könnte, meiner Meinung nach festhängen. Da stecke ich aber auch nicht so tief in der Materie wie das laufen soll.
Daher meine Aussage "festhängen" bitte mit Vorsicht geniessen.

Ich habe bei mir einen 1ms Timer der immer wieder nachschaut ob was da ist und es in "meinem" Ringppuffer packt.
es gibt ja leider keine Interrupts mehr, wie früher mit den Uarts im DOS Modus. Achja das waren Zeiten....

Ich schaue mir das aber auch nochmal an mit dem Empfangen beim Borland C.
Zumindest mal ausprobieren ob da was hängen bleibt und gebe Bescheid.

Mit dem "catch" "exceptions" usw. muss ich gestehen kann ich garnichts anfangen. :(


Siro

Zitat:

---

Zitat von Siro

Wie diese UNIT jetzt nach C++ convertiert wird, habe ich aber ehrlich gesagt nicht verstanden.

---

Da wird nichts konvertiert, der C++ Compiler ist binärkompatibel zum ebenfalls im C++ Builder enthaltenen Delphi Compiler. Das ganze Gemisch aus Pascal und C++ wird beim Übersetzen zusammengerührt.

@Mxt:
Achso, das wuste ich nicht, danke Dir für die Info. Ich dachte bisher C und Pascal unterscheiden sich unter anderem in der Reihenfolge bei den Paramterübergaben.
Pascal Parameterreihenfolge links nach rechts, bei C rechts nach links. :confused: Is ein anderes Thema, könnte man einen separaten Thread aufmachen...;)
oder hier gucken:
https://de.wikipedia.org/wiki/Aufrufkonvention

Siro

Ja, Pascal und C unterscheiden sich. Aber das war bei Frankensteins Monster auch so. Hat trotzdem funktioniert. (Irgendwie)

Guten Morgen HaWe und Ceos:

jetzt verstehe ich grad erst die Problematik:

Wenn Du deinen Arduino abziehst, dann ist bei Dir ja die ganze RS232 (also der virtuelle Comport) weg ?
und dann bekommst Du bei jeglichem Versuch auf die Schnittstelle zuzugreifen einen Exeption.

Diese Problematik habe ich garnicht, weil auf meinem Motherboard gibt es einen "echte" RS232 und wenn ich mein
Kabel abziehe, dann kommen lediglich keine Daten mehr, aber meine Schnittstelle existiert weiter.
Aufgefallen ist es mir nämlich grad also ich über einen CP2102 (also einen externen USB zu RS232 Converter) am USB Port arbeite.
Wenn ich dann das Kabel rausziehe, bekomme ich von Windows einen Exeption Error. Logisch Schnittstelle is ja weg.

Die Problematik war bei mir und meinen Geräten noch nie aufgetaucht,
das stellt also ein ganz neus Problem dar und da seid ihr Ceos und Du vermutlich wohl auf dem richtigen Weg.

Wie man diese Fehler abfängt weis ich auch noch garnicht, das bräuchte ich nämlich irgendwann auch für meine Basteleien.
Da wurde doch heute morgen tatsächlich nicht nur ich, sondern auch mein Forschungsdrang geweckt :)

Siro

Zitat:

---

Zitat von Siro

Guten Morgen HaWe und Ceos:

jetzt verstehe ich grad erst die Problematik:

Wenn Du deinen Arduino abziehst, dann ist bei Dir ja die ganze RS232 (also der virtuelle Comport) weg ?
und dann bekommst Du bei jeglichem Versuch auf die Schnittstelle zuzugreifen einen Exeption.
(...)
Wie man diese Fehler abfängt weis ich auch noch garnicht, das bräuchte ich nämlich irgendwann auch für meine Basteleien.
Da wurde doch heute morgen tatsächlich nicht nur ich, sondern auch mein Forschungsdrang geweckt :)

Siro

---

genau so ist es!
Aber selbst wenn ich ein paar Sekunden später wieder den Arduino einstöpsele, und dann die COM (hier immer COM15, eine neue wird dann nicht generiert) wieder da ist, und somit dann auch über das ComPort-Verbinden-Widget angezeigt und angewählt werden kann, führt der Verbindungsversuch dennoch zu dem beschriebenen Fehler (error, exception)... :-/

Man müsste bei ComPort->nicht_verfügbar alle Programm- und System-Einstellungen und -Threads dazu/darüber schließen und resetten, bis wieder der alte ComPort auftaucht, dann wieder überall alles dazu neu starten, und die Verbindung automatisch wiederherstellen - und falls automatisch nicht möglich, dann wieder über das Verbinden-Widget manuell per Menü ermöglichen...



PS,
letztes Layout:
Anhang 33960

updat:

ich habe jetzt die obige Funktion
void __fastcall TForm1::ComPort1Exception()
wieder komplett rausgenommen, sie hat letztendlich die Stabilität nicht deutlich verbessert.

Aber ich habe die Routinen fürs manuelle Verbinden leicht abgeändert, jetzt lässt sich nach USB-Unterbrechung die Verbindung ohne Störung wiederherstellen, wenn sie existiert, und es blockiert nichts mehr, wenn sie nach wie vor weg ist:

Code:

---

void __fastcall TForm1::Button1Click(TObject *Sender)  // Button press: "Connect"
{
  ComPort1->ShowSetupDialog();
  try {ComPort1->Open();}
  catch(...) { };

  if(ComPort1->Connected )  {
    // init program variables and widget states
  }
}

void __fastcall TForm1::Button2Click(TObject *Sender)  // Button press: "Disconnect"
{
  if(ComPort1->Connected ) {

      // try to send pin-stop msg to Arduino
      strcat(msgcstr,  "&_ALLPINS_=0;\n" );
      ComPort1->WriteStr(msgcstr); 

      Sleep(100);  // safety sleep

      try {  ComPort1->Close();  }
      catch (...) { }
  }
}

---

aktuelle, recht stabile und einigermaßen brauchbare Version:
https://github.com/dsyleixa/Borland-...rduinoCOM_RxTx

Hallo HaWe,

lebt das Projekt noch ?

Ich habe eben eine "uralte" Componente für die RS232 gefunden.
Hier können sogar Ereignisse abgefangen werden, wenn ein Comport hinzu oder auch entfernt wird.

Sie soll wohl auch unter Borland C++ Builder 1.0, 3.0, 4.0, 5.0, 6.0 laufen,
ich weis nur nicht wie man sie installiert.
Ich werde sie heute zunächts mal versuchen in mein Lazarus zu installieren.
Die Komponente ist aber Urheberrechtlich geschützt und darf nicht weiter gegeben werden:(
Ich habe sie damals mit dem Kauf des Buches erworben.

http://toolbox.reworld.eu/projekte/serial/index.html

Zitat:

---

Zitat von Siro

Hallo HaWe,

lebt das Projekt noch ?

Ich habe eben eine "uralte" Componente für die RS232 gefunden.
Hier können sogar Ereignisse abgefangen werden, wenn ein Comport hinzu oder auch entfernt wird.

Sie soll wohl auch unter Borland C++ Builder 1.0, 3.0, 4.0, 5.0, 6.0 laufen,
ich weis nur nicht wie man sie installiert.
Ich werde sie heute zunächts mal versuchen in mein Lazarus zu installieren.
Die Komponente ist aber Urheberrechtlich geschützt und darf nicht weiter gegeben werden:(
Ich habe sie damals mit dem Kauf des Buches erworben.

http://toolbox.reworld.eu/projekte/serial/index.html

---

danke für die Info!
Klar lebt das Projekt noch, und es ist ja jetzt auch ziemlich stabil. Bleibt jetzt allerdings erst mal so wie es ist, auch mit dem ComPort (Freeware). https://github.com/dsyleixa/Borland-...rduinoCOM_RxTx
Nach Möglichkeit würde ich doch auch gern auf dem Raspi so etwas mit qtcreator machen, siehe anderer Thread! https://www.roboternetz.de/community...l=1#post649910

Update zur seriellen Komponente:
Ich habe das Package "Serial44" in Lazarus installiert und ausprobiert, läuft auch.

Es gibt ein Ereignis OnCOMRemoved.

Wenn bei geöffneter Schnittstelle nun der USB Stecker gezogen wird,
verzweigt die Software in dieses Ereignis.

Ich hab mir das mal im Source Code angesehen.
Hier wird die Windows Message WM_DEVICECHANGE ausgewertet.
Eine Beschreibung gibt es hier:
https://docs.microsoft.com/en-us/win...m-devicechange

Man muss aber die WindowsProg irgendwie umgeleitet werden, damit diese Message auch abgefangen werden kann.

Ich denke aber, Du solltest vorerst bei deiner Variante bleiben.

Siro

Hallo HaWe !
Ich habe mir mal den Download zu Gemühte gezogen....läuft der auch auf 64Bit, ich meine BCB ? Sonst brauche ich das erst gar nicht brennen...
Ich hatte ja von Delphi 2 bis 7 so alles von Borland/Inprise/ usw.. aber unter 64Bit nix zu machen ..schade um das Geld. Aber nun nur fürs Hobby 3stellige Summen investieren, da bleib ich bei Atmels und PICs... ;)

Gruss
Gerhard

Bei mir läuft es auf einem Windows 10 Rechner 64Bit.
Das Programm muss aber immer mit rechter Maustaste und "Als Administrator" ausführen gestartet werden.
Sonst bekommst Du merkwürdie Fehlermeldungen beim Ausführen.
Weil mein Delphi6 auch nur noch Probleme machte, bin ich umgestiegen auf das FREIE Lazarus und bereue es nicht,
gibt es solch freie, hervorragende Versionen nicht auch für C ?

Zitat:

---

Zitat von oderlachs

Hallo HaWe !
Ich habe mir mal den Download zu Gemühte gezogen....läuft der auch auf 64Bit, ich meine BCB ? Sonst brauche ich das erst gar nicht brennen...
Ich hatte ja von Delphi 2 bis 7 so alles von Borland/Inprise/ usw.. aber unter 64Bit nix zu machen ..schade um das Geld. Aber nun nur fürs Hobby 3stellige Summen investieren, da bleib ich bei Atmels und PICs... ;)

Gruss
Gerhard

---

@oderlachs: ich habe Win7/64, läuft automatisch mit meinem Standard-Benutzer (allerdings hat der auch admin-Rechte). Auch der Vorgänger BCB 5 ließ sich ohne Probleme hier installieren.
@Siro: interessant, was es da alles gibt so mit COM, OnCOMRemoved, und dem ganzen Rest... 8)

@Siro :
Hatte mit Lazarus probiert, aber nur Probleme immer fehlten welche Packagen o.ä. . Habe es dann sein gelassen, weil ich unter Win kaum noch programmiere. Habe das ganze Delphi2....3..5 und alles was dazu sich angesammelt hatte gegen Porto verschenkt.
Darf gar nicht denken was das alles mal gekostet hatte, aber das war es mir wert.
Aber nun ärgern mich die PIC, ATMEL und STM Käfer genug, was soll ich mir damit nun auch noch den Kopf zerbrechen.
Wenn ich aber hier sowas lese, dann kribbelts doch noch nach alten Pascal, Delphi oder sonst was von Borland und Co.

@HaWe:
Habe CDs gebrannt und intalliert...menno wie in alten Zeiten die IDE Umgebung : :) :p

Gruss

Gerhard

Zitat:

---

Zitat von oderlachs

@Siro :
@HaWe:
Habe CDs gebrannt und intalliert...menno wie in alten Zeiten die IDE Umgebung : :) :p

Gruss

Gerhard

---

fand ich auch :)
aber jetzt kommt die Herausforderung: ComPort Widget installieren...! :p

Falls es Interssant ist auch rein mit der Windows Api die RS232 zu lesen kann ich euch gerne meine Code geben. Für Threads gibt es jetzt auch C++ Standarts weiß aber leider nicht ob das Eurer Compiler das schon kann.

Zitat:

---

Zitat von NumberFive

Falls es Interssant ist auch rein mit der Windows Api die RS232 zu lesen kann ich euch gerne meine Code geben. Für Threads gibt es jetzt auch C++ Standarts weiß aber leider nicht ob das Eurer Compiler das schon kann.

---

BCB 6 ist bestimmt schon über 10 Jahre alt, da gabs noch kein C++14 oder 11, AFAIK noch nicht mal C++04. Für Threads nutzt BCB kein pthread und auch nicht std::thread (zumindest nicht direkt), sondern ausschließlich das eigene TThread, was schon sehr kompliziert ist (noch brauche ich es nicht dringend, kommt aber evt noch).