suche Gui-software

[Testman3000]

Hallo,

gibt es eine einfache Software wo ich eine GUI zum steuern eines µc erstellen kann? Also bislang muss ich befehle (Ascii zeichen) über rs232 senden um funktionen zu starten oder stopen. Wollte das nun über eine kleine Gui vereinfachen. Wie am besten anfangen???

Mit freundlichen Grüßen

[Lemonsquash]

Kannst du irgend eine brauchbare Programmiersprache? -> Mit was programmierst du deinen MC?

Ansonsten kannst du jede AE-Software nehmen, die du willst, von PHP(-GTK) über VB.NET nach Delphi und C++. Was dir so einfällt ;)

Mfg.
Lemon

[Testman3000]

Hallo,

also eig "kann" ich nur eben etwas basic (basecom), gibt es ncihts einfaches wo man schon fertige regler usw hat und sie nur "zuordnen muss"? bzw Knöpfe?

Am besten für Linux, aber Windows wäre auch i.O


MFG

[pctoaster]

Hallo,
gtkterm ist Dein Freund.

Gruß
pctoaster

[johns]

gibt es eine einfache Software wo ich eine GUI zum steuern eines µc erstellen kann?

Ein recht allgemeines 'nein' zu dieser recht allgemeinen frage.
'Software' im sinn einer out-of-the-box lösung ist mir nicht bekannt.
Am nähesten, zumindest ohne (textuellen) programmieraufwand sollte man dem ziel mit produkten wie z.b. lego nxt kommen, welche die für die kommunikation erforderlichen software gegenstücke für den µC und den PC enthalten und mW. eine erstellung von benutzeroberflächen per maus zulassen.

sofern sich das µC board durch ein I/O board ersetzen lässt, gibt es die möglichkeit ein solches I/O board zu wählen für das Treiber für ein graphisches programmiersystem o.Ä (zb. Labview, robotics studio) erhältlich sind.

aber du willst vmtl einen schon vorhandenen µC nutzen, und dazu ist es notwendig die serielle schnittstelle programmatisch anzusteuern, dh du musst programmieren (im klassischen sinne). Zwar haben ca 3650571 leute soetwas bereits für verschiedenste chips entwickelt, trotzdem konnte ich für diesen zweck keine fertiglösung für µC typ XY im internet finden, eine eigene recherche für deinen µC sei dennoch empfohlen.
da aber in diesem fall sehr lehrreich, eine gute gelegenheit das rad selbst neu zu erfinden ;).




Also bislang muss ich befehle (Ascii zeichen) über rs232 senden um funktionen zu starten oder stopen. Wollte das nun über eine kleine Gui vereinfachen.


daran wird sich auch mit einer GUI nichts ändern, denn die zeichen müssen selbstredend trotzdem gesendet werden, nur halt implizit (zb. durch drücken eines buttons). Falls du schon als quelltext oder library verfügbare software einsetzt, mit der du diese 'zeichen' überträgst sollte es relativ einfach sein eine GUI mit dem GUI-Builder der IDE nach wahl zu erstellen.

wenn du aber bisher mit einem terminalprogramm (zb Hyperterminal) gesendet hast , musst du dessen funktionalität ersetzen, also braucht das programm auch einen teil für die serielle kommunikation. Die gebräuchlichsten programmiersprachen bieten den notwendigen zugriff auf die serielle schnittstelle. Bei .NET z.b. kann man das CSerial Objekt bequem per GUI-builder erstellen und per property inspector einfach konfigurieren. Ein wenig komplizerter, nicht viel, ist die verwendung von weniger abstrahierenden APIs welche die serielle schnittstelle meist als file betrachten. Zur programmatischen verwendung der seriellen schnittstelle am PC stehen eine vielzahl von tutorials und beispiel code im netz.




Wie am besten anfangen???


du musst für dich selbst die anforderungen an eine solche software definieren, als erstes am besten aus sicht des benutzers. zb stellen sich fragen wie ob man nur befehle senden will, oder zusätzlich auch antworten des µC empfangen will, ob man den befehlen auch nutzlast, also parameter mitgeben will, ob man die kommunikation mittels prüfsumme auf datenübertragungsfehler prüfen will, etc.

aus den dadurch gewonnenen anhaltspunkten und etwaigen rahmenbedingungen lässt sich im nächsten schritt ein protokoll für die datenübertragung erstellen. dabei gilt es verschiedenes zu spezifizieren, wie zB steuerzeichen für synchronisation, deren unterscheidbarkeit von datenzeichen, anzahl der zeichen einzelner 'befehle', bei übertragung von nutzdaten ob man variable oder fixe länge erlaubt, wie eine etwaige prüfsumme implementiert wird uvm.
Am ende dieses schrittes hat man eine fertige protokollspezifikation die es nachfolgend zu implementieren gilt, dh es sind die sender und empfänger programmteile für uC und PC zu programmieren.
Vieleicht genügt aber auch ein minimalprotokoll wie du es vermutlich bis jetzt benutzt: 1 zeichen für befehl, keine nutzlast, keine empfangsbestätigung, keine prüfsumme.

für avr uC zb kann man sich fertige implementierungen von solchen protokollen im quelltext der als open source erhältlichen bootloader ansehen. Vmtl gilt selbes für andere uC.


bei deinem schon vorhandenen uC wirst du sehr wahrscheinlich nicht daran vorbeikommen ein protokoll zumindest (teilweise) zu implementieren. die spezifikation kannst du dir uU. 'ausleihen' (zb. von o.g. bootloadern abschauen) und eventuell sogar teile derer implementierungen in eigenen quellcode übernehmen.

ansonsten wären produkte wie lego NXT oder I/O boards mit bereits spezifizierten protokollen und dazugehörigen implementierungen ein weg den nicht zu unterschätzenden aufwand für serielle kommunikation gegen null zu verringern.



lg
johns

[Willa]

Hallo!
Ich habe einen Artikel wie man GUI's erstellt im RN-Wissen erstellt:
https://www.roboternetz.de/wissen/index.php/Windows_Programm_zum_Steuern_des_AVR%27s
(falls das jemandem hilft...)
Viele Grüße,
William

[nomad]

hi,
hier ein kleines altes c-programm unter linux & gtk
mit rs-232 routinen (senden und empfangen)
steuert einen microcontroller. (fahrtrichtung)

attachment:Mover12-c.txt

gruss
nomad

[NumberFive]

@Willa

hat die RS232 Komponente kein Event ? zum einlesen der Daten.
Der Timer von Windows ist in meinen Augen suboptimal zum eine lesen
der Daten. Die WM_TIMER Nachricht wird auch mal entfernt wenn das System beschäftigt ist.

[Willa]

Hi!
@NumberFive:
Doch, ich glaube schon. Nennt sich wohl "serialport1.DataReceived". Aber da ich wenig Ahnung vom Programmieren habe, nehm ich immer gern einen Timer. Der ist so schön intuitiv... Und wenn mal der Timer nicht auslöst, dann macht er es halt erst wieder beim nächsten mal, ist ja egal (wenigstens für meine Zwecke...).
Viele Grüße,
William