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

[HaWe]

jap!
mann, klar, auf "Kind" bin ich nicht gekommen, hatte was in der Art von "orientation" gesucht...




PS,

Für den Joystick gabs hier mal was:
https://www.roboternetz.de/community...ilder-abfragen

Siro

das geht da aber um einen "realen" Joystick, keinen virtuellen auf der BCC Form, oder?

[Siro]

Okay, das hab ich falsch verstanden, ich dachte es geht um eine "echte" Joystickabfrage.

Da gibt es aber sicher auch fertige Komponenten für.

Auf dieser Seite gibt es diverse Komponenten , die teils für Delphi und oder auch C++Builder geschrieben wurden.
https://torry.net


Siro

[HaWe]

Okay, das hab ich falsch verstanden, ich dachte es geht um eine "echte" Joystickabfrage.

Da gibt es aber sicher auch fertige Komponenten für.

Auf dieser Seite gibt es diverse Komponenten , die teils für Delphi und oder auch C++Builder geschrieben wurden.
https://torry.net


Siro

dankeschön, super Link! Mal gucken, was sich dort finden lässt!

- - - Aktualisiert - - -

das hier sieht ja schon ganz vielversprechend aus:
https://torry.net/quicksearchd.php?S...tick&Title=Yes,
ganz unten: TFlightJoyStick v.1.0

A-Bär... nur für Pascal, oder?

[HaWe]

aktuell: https://github.com/dsyleixa/Borland-...rduinoCOM_RxTx


to do (ganz wichtig):

bei Datenunterbrechung (Kabel gezogen) den Kontakt wieder aufnehmen.
Momentan blockiert dann leider das BCB Programm komplett...

(bei Arduino-Arduino oder Arduino-Raspi war das nie ein Problem...)

[Siro]

Ich vermute das Problem liegt bei ComPort1RxChar

Du versuchst 1024 Bytes aus dem RX Puffer zu lesen,
wieviele da aber momentan drin sind wird Dir ja in der Variablen Count mitgeteilt,
das ist auch immer unterschiedlich,
demnach kannst Du auch nicht mehr Bytes lesen.
Du musst die Empfangsbytes erstmal solange in einen Puffer ablegen, bis dein Endezeichen erkannt wurde,
also z.B. das Carriage Return /n
Erst dann rufst Du deine Auswertefunktion auf, die den Buffer zerlegt.
Also kommt in die ComPort1RxChar eigentlich nur folgende Pseudocode:

while (Count--)
{
read 1 byte
if byte is Endezeichen dann Auswerten
ansonsten in Puffer packen
}

Siro

[HaWe]

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?

[Ceos]

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.