Forum: PC-Programmierung Suche Programmgerüst: USB-Kommunikation und Daten Ein/Ausgabe Windows


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Ich muss wahrscheinlich eine Programmieraufgabe abgeben, bei der ich 
nicht die Zeit habe, mich lange in die Grundlagen hineinzuarbeiten. Da 
macht es evtl. Sinn, ein Programmgerüst zu nehmen und entsprechend zu 
erweitern. Ich weiß nicht wie komplex das Thema ist, aber ich denke, daß 
andere das bereits erfolgreich gelöst haben und es besser können als ich 
es schaffe, wenn ich alles neu von Null an beginne.

Ich brauche:
- Kommunikation mit einem Mikrocontroller über USB
- einigermaßen strukturierte Datenausgabe/Text in einem Windows-Fenster
- Eingabemöglichkeit für ein paar Daten (Text)
- als Bonus evtl. die Möglichkeit, grafische Kurven/Linien zu zeichnen
- Programmiersprache frei (wenn möglich evtl. C++)
- wünschenswert frei verfügbare Toolchain

Der Controller wird relativ leistungsschwach, wahrscheinlich reicht ein 
AVR wie ein ATMega 644/1284 locker, Anbindung vielleicht über den guten 
alten FT232.

Das Programm sollte diesen Controller finden können wenn er via USB an 
einen Computer angeschlossen und mit ihm kommunizieren können. 
Geschwindigkeit ist Nebensache, es geht nicht um große Datenmengen, 
sondern nur Anfordern/Auslesen von Messwerten, als Bonus Zeichnen von 
Messkurven aus diesen Messwerten. Wenns noch RS232 gäbe, würde ich 
darauf zurückgreifen und USB vergessen, aber leider lebt nur noch USB.

Zweites und evtl. (für mich) größeres Problem ist, daß ich keine 
nennenswerte Erfahrung mit Windows-Programmierung habe. Ich bin sehr gut 
in PHP, aber nicht in C oder C++. Heißt, von der reinen Programmierung 
her wäre ein kleiner Webserver auf dem Controller, die Anbindung an ein 
LAN/WLAN und die Kommunikation mit einem Browser ein einfacheres Problem 
als ein Windows-Programm mit USB-Kommunikation. Klingt unverständlich, 
ist aber so - weil Netzwerk und HTML weiß ich wie's geht, bei 
Windows-Programmierung weiß ich fast nichts, bzw. nicht was über 
Konsolenfenster-Programme hinausgeht.
  Ich überlege regelmäßig, wie man ein Programmgerüst für ein solches 
Windows-Fenster mit einfacher Text- oder Grafikausgabe zustande bringt, 
wo man auch ein paar Eingabefelder hat... aber ich habe es leider 
bislang nicht hingekriegt, mich da richtig hineinzuarbeiten, bzw. mir 
fehlen Vorlagen zusammen mit ihren Toolchains, von USB-Kommunikation mal 
ganz zu schweigen.

Zuletzt: Ich weiß, daß sowas unbezahlbar teuer wird wenn man einen 
professionellen Entwickler/Programmierer damit beauftragt. Hätte ich 
Millionen, würde ich es machen und niemand bräuchte ein Forum dafür. 
Aber vielleicht finde ich ja jemanden, der das mit wenig Aufwand bereits 
hat oder kann, oder vielleicht kann ich irgendwo anders zurück-helfen 
oder irgendwas tauschen...

von Harald K. (kirnbichler)


Lesenswert?

Ben B. schrieb:
> Anbindung vielleicht über den guten alten FT232.

Dann ist es einfach nur Kommunikation über eine serielle Schnittstelle, 
und nicht über USB, was die Angelegenheit sehr stark vereinfacht.

> Das Programm sollte diesen Controller finden können wenn er via USB an
> einen Computer angeschlossen und mit ihm kommunizieren können.

Das kann man herausfinden, indem man in der Registry nachsieht, welche 
seriellen Schnittstellen an einem FT232 enden.

Wenn man sich noch den Aufwand macht, dem Gerät, in dem der FT232 
verbaut ist, ein EEPROM zu spendieren und mit FTprog (Download von 
ftdichip.com) dem Ding eine eindeutige Seriennummer verpasst, kann man 
diese Seriennummer auch in der Registry finden, und damit Verwechslungen 
beim gleichzeitigen Betrieb mehrerer FT232 ausschließen.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Dann ist es einfach nur Kommunikation über eine
> serielle Schnittstelle, und nicht über USB, was
> die Angelegenheit sehr stark vereinfacht.
Aber leider nur seitens des Controllers, nicht des Programms.

> Das kann man herausfinden, indem man in der Registry nachsieht,
> welche seriellen Schnittstellen an einem FT232 enden.
Wäre schön, wenn jemand dafür Beispiele in einem solchen Programm-
Grundgerüst hat. Wie sowas geht habe ich leider noch nicht erforscht.

Was den FT232 angeht, da studiere ich das Datenblatt sobald ich einen 
konkreten Lösungsansatz habe und mir sicher bin, daß es dieser 
Schaltkreis werden soll. Vielleicht kann man diese EEPROM-Programmierung 
auch vom µC erledigen lassen wenn die Schaltung gestartet wird.

Edit:
Datenblatt des FT232 kurz überflogen, Dinge wie Vendor-ID und Product-ID 
kann der von Hause aus und hat einen internen EEPROM dafür.

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

Ben B. schrieb:
> Aber leider nur seitens des Controllers, nicht des Programms.

Aber ja doch. Es ist ganz erheblich einfacher, unter Windows mit einer 
seriellen Schnittstelle zu kommunzieren als mit einem USB-Gerät. Dafür 
müsstest Du nämlich entweder einen Devicetreiber für Windows schreiben 
oder aber mit libusb bzw. WinUSB herumdoktern.

https://github.com/libusb/libusb/wiki/Windows

https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/developing-windows-applications-that-communicate-with-a-usb-device

Die Lernkurve für beides ist unendlich viel brutaler als die für das 
Ansteuern einer seriellen Schnittstelle.


Ben B. schrieb:
> Vielleicht kann man diese EEPROM-Programmierung
> auch vom µC erledigen lassen wenn die Schaltung gestartet wird.

Nein, das EEPROM des FT232 (im FT232R ist es ab Werk eingebaut) ist nur 
von der USB-Seite aus "sichtbar".

Ben B. schrieb:
> Dinge wie Vendor-ID und Product-ID kann der von Hause aus

Um die geht es nicht, sondern um die Seriennummer.

von Hans-Georg L. (h-g-l)


Lesenswert?

Nimm einen STM Blue oder Blackpill da kannst du ein Gerüst mit CUBE-MX 
zusammenklicken. Für Windows nimmst du VisualStudio da kannst du auch 
das Gerüst einer Anwendung zusammen klicken. Kommunikation über 
Virtuelle COM Schnittstelle. Beispiele für beides gibt es genügend im 
Netz.

von J. S. (jojos)


Lesenswert?

oder einen RPi Pico mit Arduino Framework. USB ist eingebaut, etwas 
seriell auszugeben ist z.B. ein Serial.print("hello");
Über PlatformIO läuft das in wenigen Minuten. Ok, der Download und die 
Installation des Pico SDK dauert etwas, aber das geht automagisch mit 
PlattformIO.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

>> Aber leider nur seitens des Controllers, nicht des Programms.
> Aber ja doch. Es ist ganz erheblich einfacher, unter
> Windows mit einer seriellen Schnittstelle zu kommunzieren
> als mit einem USB-Gerät.
Sorry, wie gesagt, solche Details weiß ich nicht.

Arduino oder "irgendwas mit zuvielen Libs" wollte ich eigentlich meiden.
Ich hatte gehofft, etwas für C++ oder von mir aus auch C# zu bekommen, 
was evtl. mit dem MS Visual Studio compiliert werden kann und eine .EXE 
erzeugt, die hinterher auf jeder Win10-kompatiblen Kiste lauffähig ist.

> Nimm einen STM Blue oder Blackpill
Der STM wäre ohne Frage der bessere Prozessor, allerdings bin ich mit 
dem AVR vertrauter und die Aufgabe des µC ist im Grunde nur Daten 
sammeln und etwas Kommunikation mit wenig Geschwindigkeit. Ich tendiere 
im Moment stark zum AVR, einfach weil ich die Dinger kenne und in C für 
die STMs noch nicht so besonders gut bin.

von Harald K. (kirnbichler)


Lesenswert?

Ben B. schrieb:
> Arduino oder "irgendwas mit zuvielen Libs" wollte ich eigentlich meiden.

Ist ja für das Windows-Programm auch nicht der Punkt.


Und wie Du den µC programmierst, der über seine serielle Schnittstelle 
mit dem FT232 kommuniziert, das bleibt Dir überlassen -- da nimmst Du am 
besten das, was Du schon kennst.

Oder brauchst Du auch da ein "Gerüst"?

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Und wie Du den µC programmierst, der über seine serielle
> Schnittstelle mit dem FT232 kommuniziert, das bleibt Dir
> überlassen -- da nimmst Du am besten das, was Du schon kennst.
Korrekt, der bekommt sein Programm über ISP.

> Oder brauchst Du auch da ein "Gerüst"?
Negativ.

von Harald K. (kirnbichler)


Lesenswert?

Ben B. schrieb:
> Korrekt, der bekommt sein Programm über ISP.

Mit "Programm bekommt" meinte ich jetzt nicht das Flashen des µC, 
sondern das schreiben des Programmes in einer von Dir beherrschten 
Programmiersprache mit der von Dir verwendeten Programmierumgebung.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Mit "Programm bekommt" meinte ich jetzt nicht das Flashen des µC,
> sondern das schreiben des Programmes in einer von Dir beherrschten
> Programmiersprache mit der von Dir verwendeten Programmierumgebung.
Achso. Ja das krieg ich hin. Werde ich zwar mit Assembler machen was 
viele hier im Forum etwas rückständig ansehen, aber darin bin ich sehr 
fit und bei µCs ist der Unterschied zwischen C und Assembler nicht so 
groß, bzw. lohnt sich erst bei sehr komplexen Programmen.

Edit:
Außer es wird doch noch ein STM32, dann habe ich einen guten Grund, C zu 
lernen. Für die ARM Cortex nochmal Assembler lernen lohnt sich glaube 
ich nicht.

: Bearbeitet durch User
von Thomas W. (Gast)


Lesenswert?

Ben B. schrieb:

>   Ich überlege regelmäßig, wie man ein Programmgerüst für ein solches
> Windows-Fenster mit einfacher Text- oder Grafikausgabe zustande bringt,
> wo man auch ein paar Eingabefelder hat... aber ich habe es leider
> bislang nicht hingekriegt, mich da richtig hineinzuarbeiten, bzw. mir
> fehlen Vorlagen zusammen mit ihren Toolchains, von USB-Kommunikation mal
> ganz zu schweigen.

Natuerlich ist das relativ schnell mit VisualC#/Basic 
zusammengeklickert. MS C++ waere nicht meine erste Wahl.

Zwei Sachen solltest Du beruecksichtigen: Windows 10 ist 2025 EOL, bah! 
MS will ja unbedingt die alten Maschinen aus dem Verkehr ziehen, ob sich 
die EU das gefallen laesst: Wer weiss?

Wenn Du Deine SW in die Flaeche ausrollen willst musst Du Dir ein paar 
Gedanken ueber die CodeSigning-Certificates machen (genauer gesagt: 
Bezahlen) denn der Windows10 interner Signaturcheck ist ein wenig 
nervig.

Gruesse

Th.

P.S.: QT ist auch noch eine gute Wahl.

von Εrnst B. (ernst)


Lesenswert?

Ben B. schrieb:
> Ich brauche:
> - Kommunikation mit einem Mikrocontroller über USB
> - einigermaßen strukturierte Datenausgabe/Text in einem Windows-Fenster
> - Eingabemöglichkeit für ein paar Daten (Text)
> - als Bonus evtl. die Möglichkeit, grafische Kurven/Linien zu zeichnen
> - Programmiersprache frei (wenn möglich evtl. C++)
> - wünschenswert frei verfügbare Toolchain

Wirf mal einen Blick auf https://processing.org/

Ist vom Aufbau relativ ähnlich zu Arduino, aber eben auf dem PC mit 
Grafik usw.

Serielle Verbindung zu deinem µC geht, (allerdings kriegt man die 
USB-Seriennummern nicht, glaube ich)
https://processing.org/reference/libraries/serial/Serial.html

Und Beispiele wie man damit Arduino-Messwerte auf den Bildschirm pinselt 
gibt's auch:
https://itp.nyu.edu/physcomp/labs/labs-serial-communication/serial-output-from-an-arduino/

Aber:
ist m.M.n eher was für's Prototyping

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Ich bin nicht der Meinung, daß man nach 2025 keine (unsignierte) 
Win10-Software mehr ausführen können soll. Außer Microsoft will sich 
endgültig selbst abschaffen weil sie noch nicht genug Marktanteil an 
Linux verloren haben. Ich glaube auch nicht, daß jeder kleine 
Software-Anbieter sein Programm signieren lassen möchte. Vielleicht 
fängt man sich eine Warnung, daß das Programm aus einer unverifizierten 
Quelle stammt - aber die bekommt man ja im Moment auch schon wenn man 
ein aus dem Internet heruntergeladenes Programm unter Win10 ausführt.

Sicherlich wäre es ganz gut, von Anfang an ein Design zu machen, welches 
potentiell Produktiv-Ansprüchen gerecht wird, aber ich möchte das nicht 
an erste Stelle stellen. Ein Programm, was toll aussieht, aber nicht 
funktioniert, bringt niemandem was.

Programmiersprache... ich möchte da keine strikte Vorgabe machen, ich 
würde jedes Programmgerüst nehmen was gut funktioniert und was ich so 
gut verstehe, daß ich es selbst weiterentwickeln kann.
  Am liebsten wäre mir halt irgendwas in die Richtung C++ oder C# wegen 
Windows und weil ich sowieso irgendwann in diesem Leben nicht mehr um C 
lernen drumrum komme. Also wenn jemand so ein Programmgerüst gerne in VB 
machen würde, es funktioniert gut etc. dann würde ich es evtl. verwenden 
- aber die dabei gewonnenen Kenntnisse wären später möglicherweise 
umsonst wenn ich C lernen muss.

von Harald K. (kirnbichler)


Lesenswert?

Ben B. schrieb:
> Ich bin nicht der Meinung, daß man nach 2025 keine (unsignierte)
> Win10-Software mehr ausführen können soll.

Ein Signierungszwang wäre in der Tat ein Problem. MS könnte sich an 
Apples "Gatekeeper" orientieren, der in der Defaulteinstellung das 
Ausführen unsignierter Software unterbindet, aber das ist eher 
unwahrscheinlich, weil die schiere Menge an existierender, unsignierter 
Software sehr, sehr groß ist. Ein auch abschaltbares Gemecker à la 
"Gatekeeper" wäre aufgrund der Menge an dadurch hervorgerufenen 
Supportanfragen ein ernstes Problem.

Andererseits will Microsoft mit Windows 11 das sinnlose Verschrotten 
funktionierender PC-Hardware forcieren, indem völlig unnötige 
"Hardwareanforderungen" gestellt werden, ohne die angeblich 
möglicherweise die heiligen Updates nicht mehr sichergestellt werden 
könnten.

Wer so eine Scheißaktion durchzieht, kann natürlich auch versuchen, sich 
den anderen Ast abzusägen, auf dem man sitzt, und zig Milliarden an 
Softwareinvestitionen ohne Sinn und Verstand zu entwerten.

von Thomas W. (Gast)


Lesenswert?

Ben B. schrieb:
> Ich bin nicht der Meinung, daß man nach 2025 keine (unsignierte)
> Win10-Software mehr ausführen können soll. Außer Microsoft will sich
> endgültig selbst abschaffen weil sie noch nicht genug Marktanteil an
> Linux verloren haben. Ich glaube auch nicht, daß jeder kleine
> Software-Anbieter sein Programm signieren lassen möchte. Vielleicht
> fängt man sich eine Warnung, daß das Programm aus einer unverifizierten
> Quelle stammt - aber die bekommt man ja im Moment auch schon wenn man
> ein aus dem Internet heruntergeladenes Programm unter Win10 ausführt.

Da sehe ich leider etwas anderes: Der Benutzer erwartet schon, dass die 
SW ohne "Sicherheitswarnungen" installiert werden kann. Beim 
Endverbraucher ist das ein Mangel (Gewaehrleistung), bei B2B bist Du 
draussen (das aber schon seit vielen Jahren). Das ist der Unterschied 
zwischen einer Bastelei und einem Produkt.

Defacto brauchst Du fuer neue SW ein CodeSigning-Zertifikat.

Und gehe bitte davon aus, dass Deine Benutzer sehr wenig EDV-Kompetenzen 
mitbringen (selbst bei Studies im technischen Bereich gesehen).

> Programmiersprache... ich möchte da keine strikte Vorgabe machen, ich
> würde jedes Programmgerüst nehmen was gut funktioniert und was ich so
> gut verstehe, daß ich es selbst weiterentwickeln kann.
>   Am liebsten wäre mir halt irgendwas in die Richtung C++ oder C# wegen
> Windows und weil ich sowieso irgendwann in diesem Leben nicht mehr um C
> lernen drumrum komme. Also wenn jemand so ein Programmgerüst gerne in VB
> machen würde, es funktioniert gut etc. dann würde ich es evtl. verwenden

Ich wuerde mir an Deiner Stelle Qt angucken (wenn Du einen FatClient 
haben willst): Windows, Linux und macOS Quell-kompatibel, sehr stark 
Grafikorientiert. Es ist C++. Lizenz ist zum einen (L)GPL oder eine 
komplette kommerzielle Lizenz. Der Price-Tag ist mit ca. US$ 300 OK (pro 
Monat) oder OpenSource.

Oder etwas web-Based (Electron oder Java). Oder gucke mal, wie die 
Arduino-IDE den Serial Plotter implementiert hat (vielleicht reicht das 
schon).

Oder BetterSerialPlotter (ist c++, MS-Style):
https://github.com/nathandunk/BetterSerialPlotter

Gruesse

Th.

von G. K. (zumsel)


Lesenswert?


von Harald K. (kirnbichler)


Lesenswert?

Thomas W. schrieb:
> Ich wuerde mir an Deiner Stelle Qt angucken (wenn Du einen FatClient
> haben willst): Windows, Linux und macOS Quell-kompatibel, sehr stark
> Grafikorientiert.

Alternative: wxWidgets. Ebenfalls für Windows, Linux und macOS.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Ich werde mich mal durch die Links arbeiten.

> Der Price-Tag ist mit ca. US$ 300 OK (pro Monat) oder OpenSource.
Solche Abo-Lösung sind für mich ein ganz klares no-go und Zwang zu
Open Source egal was letztlich draus wird oder auch nicht geht auch gar 
nicht. Als Option okay, ich hab ja auch bereits Teile meiner Quellcodes 
veröffentlicht oder kurzen Code speziell zum Veröffentlichen 
geschrieben, aber als Zwang ist es ein zweites klares no-go.

Damit wäre Qt raus.

Edit:
Erfordert GCC, was Diamex für den Temperatursensor verwendet,
auch einen Open Source Zwang?

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

Ben B. schrieb:
> Erfordert GCC, was Diamex für den Temperatursensor verwendet,
> auch einen Open Source Zwang?

Gcc erfordert nicht, daß damit übersetzte Programme open source sein 
müssen.

Aber der Sourcecode selbst kann so etwas fordern.

Lad' den Sourcecode runter, guck rein. Da sollte drinstehen, unter 
welcher Lizenz der steht.

Steht's nicht drin, musst Du beim Anbieter nachfragen.

Das Diamex-Beispiel mit GUI nutzt keinen gcc, das ist in Delphi 
geschrieben.

Wieder 'ne andere Baustelle.

: Bearbeitet durch User
von C-hater (c-hater)


Lesenswert?

Ben B. schrieb:

>   Am liebsten wäre mir halt irgendwas in die Richtung C++ oder C# wegen
> Windows und weil ich sowieso irgendwann in diesem Leben nicht mehr um C
> lernen drumrum komme. Also wenn jemand so ein Programmgerüst gerne in VB
> machen würde, es funktioniert gut etc. dann würde ich es evtl. verwenden
> - aber die dabei gewonnenen Kenntnisse wären später möglicherweise
> umsonst wenn ich C lernen muss.

Es macht praktisch keinen Unterschied, ob man die Sache in VB.net oder 
C# schreibt. Ja, die Schlüsselwörter heißen je nach konkreter Sprache 
teilweise anders, aber die Struktur des Programmes wird praktisch gleich 
aussehen. Die wird nämlich im Wesentlichen durch das darunter liegende 
Framework vorgegeben, bzw. dessen Komponenten, die man sinnvollerweise 
verwenden wird, speziell hier natürlich SerialPort.

Ach so: ob C# oder VB.net: bezüglich einer späteren "Hilfe" beim 
Erlernen von C kannst du beide in den Skat drücken. Das sind prinzipiell 
sichere OOP-Sprachen, also so ziemlich das "Gegenteil" von C. Bezüglich 
der Syntax ist C# natürlich etwas C-ähnlicher als VB.net , aber das ist 
auch schon so ziemlich alles.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Yep, genau das ist mein Problem. Sprichwörtlich führen alle Wege nach 
Rom, aber ich weiß nicht welcher gerade gesperrt ist, wo 'ne Brücke 
eingestürzt ist oder wo es kürzlich einen Unfall gab.

Ich bräuchte da wirklich jemanden, der mir sagen kann das ist eine 
gute Lösung mit frei verfügbarer Toolchain und eben den Programmanfang, 
den ich übernehmen könnte.

Es sagt sich ja so leicht, daß es nicht so schwer sein kann, ein paar 
Informationen über USB einzulesen und diese anzuzeigen. Unter DOS hätte 
ich damals als Kind kein Problem mit gehabt, hätte ich locker 
hinbekommen (mit RS232). Aber unter Windows wird alles leider ein wenig 
komplizierter.

von Εrnst B. (ernst)


Lesenswert?

Ben B. schrieb:
> Aber unter Windows wird alles leider ein wenig
> komplizierter.

Wie wär's mit HTML und Javascript?
mit der "Serial"-API kann eine Webseite auf den COM-Port zugreifen.
Und von dort aus im HTML eine Schöne Oberfläche und Graphen hinzukriegen 
ist dank Bergen an unterschiedlichen UI&Plot-Bibliotheken auch kein 
Hexenwerk.

https://developer.chrome.com/articles/serial/

Da könntest du sogar nach USB-PID und VID filtern.

Später hast du immer noch die Option, deine Webseite+Javascript per PWA 
installierbar zu machen oder per Electron zu einem installierbaren Paket 
zu bündeln.

von C-hater (c-hater)


Lesenswert?

Ben B. schrieb:

> Es sagt sich ja so leicht, daß es nicht so schwer sein kann, ein paar
> Informationen über USB einzulesen und diese anzuzeigen.

Ist es auch nicht. Ganz sicher jedenfalls nicht, wenn man "über USB" mal 
runterbricht auf "über einen (virtuellen) COM-Port". Dann hat man 
nämlich mit dem ganzen USB-Geraffel schonmal rein garnix mehr zu tun. 
Irgendeinen USB-Seriell-Adapter mit passender Spannung auf der µC-Seite 
anschließen (ggf. den dazu gehörigen Treiber vom Hersteller 
installieren, falls Windows das nicht automatisch bereits tut) und die 
USB-Sache kann vergessen werden.

Danach hast du es nur noch mit einem COM-Port zu tun, nix mehr mit 
USB...

> Unter DOS hätte
> ich damals als Kind kein Problem mit gehabt, hätte ich locker
> hinbekommen (mit RS232).

...der sich dann (mal abgesehen vom Timing) genau so verhält, wie dein 
oller RS232-COM-Port. Genau weil das so ist, wird er halt so gern und 
oft benutzt. Es gibt bestimmt Millionen Codefragmente im Netz, die die 
Benutzung eines COM-Ports unter Windows aufzeigen. Für praktisch jede 
Programmiersprache und jedes Framework, die jemals unter Windows zum 
Einsatz kam...

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Wie wär's mit HTML und Javascript?
> [..]

Klingt interessant, das schaue ich mir einmal an. Ist das ausreichend 
standardisiert, daß es in allen Browsern funktioniert und nicht nur in 
Chrome?

@c-hater
Wie gesagt, für mich sind das viele offene Fragen und nicht wissen 
wonach man genau suchen soll, vor allem nicht wegen des Windows-Fenster 
mit der Ein/Ausgabe und der Auswahl des "richtigen" Compilers. Es gibt 
im Netz sicher eine Million Möglichkeiten und ich hab einfach keine 
Ahnung, welche ich davon nehmen soll, wo ich evtl. jemanden finde, der 
mir bei Problemen weiterhelfen kann. Und nicht dann sowas wie "äh naja, 
hätteste mal C-123 und nicht C+321 genommen, dann hätte ich dir helfen 
können" ... Ich will einfach nicht blind in eine Sackgasse hineinlaufen, 
ich hätte gerne irgendwas, was nachvollziehbar und für mich verständlich 
funktioniert.

von Thomas W. (Gast)


Lesenswert?

Ben B. schrieb:

> Ich bräuchte da wirklich jemanden, der mir sagen kann das ist eine
> gute Lösung mit frei verfügbarer Toolchain und eben den Programmanfang,
> den ich übernehmen könnte.

Das gibt es nicht. Was war denn z.B. am BetterSerialPlotter so schlecht: 
C++, der Compiler ist frei verfuegbar (frei im Sinne Free Beer). OK, 
laeuft nur unter Windows, aber sonst nicht so schlecht. Dir ein 
Protokoll ausdenken sollte ja kein Problem sein.

Qt ist wegen eines Passuses der Weitervergabe nach Ende der Subscription 
und die komplexe Anbindung an Datenbanken bei mir rausgeflogen. Die 
Library per se ist gut (mittlerweile meiner Meinung zu komplex, YMMV).

Der Pflicht zur Veroeffentlichung (GPL halt) ist fast ueberall dabei,the 
QT Company erzwingt es halt. Ist halt so. Man ist ja nicht verpflichtet, 
die SW zu benutzen.

> Es sagt sich ja so leicht, daß es nicht so schwer sein kann, ein paar
> Informationen über USB einzulesen und diese anzuzeigen. Unter DOS hätte
> ich damals als Kind kein Problem mit gehabt, hätte ich locker
> hinbekommen (mit RS232). Aber unter Windows wird alles leider ein wenig
> komplizierter.

Das stimmt auch nicht: Das layer "USB" programmierst nicht Du, praktisch 
hast du ein virtuellen seriellen Port. Das wars. Das Datenformat 
definierst Du mit der Ausgabe Deines uControllers.

Fenster bauen, Skalieren (das ist fasst das Hauptproblem) und fertig ist 
Dein Plotter (dieser BetterSerialPlotter ist nicht so schlecht).

Gruesse

Th.

von Εrnst B. (ernst)


Lesenswert?

Ben B. schrieb:
> Klingt interessant, das schaue ich mir einmal an. Ist das ausreichend
> standardisiert, daß es in allen Browsern funktioniert und nicht nur in
> Chrome?

Nur Chrome und dessen Abkömlinge, und da auch nicht auf Android:

https://caniuse.com/web-serial

Sobald es mit Electron verpackt ist, hast du aber eh immer deine eigene 
Chrome-Engine mit dabei.

https://www.electronjs.org/

von Stefan F. (Gast)


Lesenswert?

Thomas W. schrieb:
> Der Pflicht zur Veroeffentlichung (GPL halt) ist fast ueberall dabei,the
> QT Company erzwingt es halt

Ich denke, da hast du die Lizenz missverstanden, bzw. den falschen 
Lizenztext gelesen.

"The primary open-source license is the GNU Lesser General Public 
License v. 3 (“LGPL”). With the LGPL license option, you can use the 
essential libraries and some add-on libraries of Qt. This allows for 
keeping your application source code closed as long as all the 
requirements of LGPLv3 are met. More details are available below."

https://www.qt.io/licensing/open-source-lgpl-obligations

von Thomas W. (Gast)


Lesenswert?

Ben B. schrieb:
> @c-hater
> Wie gesagt, für mich sind das viele offene Fragen und nicht wissen
> wonach man genau suchen soll, vor allem nicht wegen des Windows-Fenster
> mit der Ein/Ausgabe und der Auswahl des "richtigen" Compilers. Es gibt

Du haettest in der Zwischenzeit schon einmal Microsoft Visual Studio 
2022 community herunterladen koennen, ein (C#/VB)-Projekt erstellen, ein 
Form, ein Panel, ein Serial Port dazu packen und versuchen, serielle 
Daten von Deinem USB-Serial-Adapter hin- und herzuschicken.

Beispiel findest Du:
https://learn.microsoft.com/de-de/dotnet/api/system.io.ports.serialport?view=dotnet-plat-ext-7.0

Benutze die Suchmaschien Deiner Wahl:
"c# grafik plotten"

Mehr ist da wirklich nichts. Ein paar Gedanken must Du Dir ueber die 
Skalierung machen, ein paar Ganglien massieren und gut ist.

Gruesse

Th.

von C-hater (c-hater)


Lesenswert?

Ben B. schrieb:

> im Netz sicher eine Million Möglichkeiten und ich hab einfach keine
> Ahnung, welche ich davon nehmen soll

Irgendeine. Scheißegal welche. Da du offensichtlich von nix irgendeine 
Ahnung hast, wirst du dich in jedem Fall einarbeiten müssen.

> wo ich evtl. jemanden finde, der
> mir bei Problemen weiterhelfen kann.

Für alle verbreiteten Frameworks und Programmiersprachen findet man 
Unmassen Informationen, Beispiele, potentielle Helfer und 
"de-facto-Listen" von Problemen, auf die die jeweiligen Anfänger auf 
Grund ihrer Inkompetenz früher oder später stoßen werden. Man muß halt 
nur wirklich erstmal anfangen...

Alle üblichen Suchmaschinen sind inzwischen clever genug, zielsicher zu 
den entsprechenden Artikeln zu verlinken. Es genügt meist, in seiner 
eigenen Sprache ein einigermaßen zutreffende Beschreibung des Problems 
oder der Fehlermeldung an sie zu verfüttern.

Dein Problem ist: du machst garnix selber, du fängst halt nicht an. So 
stößt man natürlich weder auf konkrete Probleme noch auf konkrete 
Fehlermeldungen und hat deswegen kein Futter für Google&Co...

von Thomas W. (Gast)


Lesenswert?

Stefan F. schrieb:
> Thomas W. schrieb:
>> Der Pflicht zur Veroeffentlichung (GPL halt) ist fast ueberall dabei,the
>> QT Company erzwingt es halt
>
> Ich denke, da hast du die Lizenz missverstanden, bzw. den falschen
> Lizenztext gelesen.

Ich darf natuerlich machen was ich will, in dem Moment wo ich meine SW 
unter GPL weitergebe(!) muss der Empfaenger (natuerlich) die 
Moeglichkeit haben, zu compilieren (z.B. Fehler korrigieren). Das ist 
die ganze Idee die da hintersteckt. Daher muss ich meine Quellen und 
alle Anpassungen an LGPL-Lizenzen (und das Build-System) mitgeben.

Oder habe ich die GPL komplett falschverstanden?

Gruesse

Th.

von Stefan F. (Gast)


Lesenswert?

Thomas W. schrieb:
> Oder habe ich die GPL komplett falschverstanden?

Nein hast du nicht.

Aber die Qt Bibliotheken laufen unter LGPL (nicht GPL). LGPL schreibt 
dir nicht vor, deinen eigenen Code überhaupt zu veröffentlichen. Das 
ist der wesentliche Unterschied zwischen GPL und LGPL.

Siehe auch die deutsche Übersetzung der LGPL: 
https://www.gnu.de/documents/lgpl-3.0.de.html

"Sie dürfen ein betroffenes Werk gemäß §§3 und 4 dieser Lizenz 
übertragen, ohne an §3 der GNU GPL gebunden zu sein. "

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Ich würde das auch an deiner Stelle mit einem USB-Serial Converter
(z.B. Digitus) machen und dann weiter mit einem virtuellen
COM-Port.
Die Programmiersprache ist eigentlich egal, sofern sie serielle
Kommunikation implementiert hat. Da du anscheinend noch keine
richtig kennst, würde ich auf eine BASIC-ähnliche Sprache setzen
und nicht auf Boliden wie C, C++, C# usw. womit man sich einige
Zeit damit auseinander setzen muß, bis man mal ein Fenster usw.
bauen kann. Da gibt es auch Nischen-Sprachen, wie PureBasic,
XProfan usw. die den Zweck erfüllen und man nach kurzer Einarbeitungs-
zeit ein kleines Programm entwickeln kann.

Gerade für solche kleine Programme oder Tools nutze ich auch
heute noch gerne mein (X)Profan. Da hat man mit wenigen Zeilen
Code (Fenster, GUI-Elemente ud Ereignisschleife) schon ein
Programmgerüst und man kann sich schnell der eigentlichen
Aufgabe widmen.

Ob die Sprache noch Zukunft hat, soll hier nicht das Thema
sein. Jedenfalls ist es mir noch für die nächste Zeit gut.

von Andreas R. (noobsen)


Lesenswert?

Ich bin zwar kein Freund von LabView, aber das scheint mir doch genau 
der richtige Anwendungsfall dafür zu sein.
Egal ob USB  FT232  RS232. Endet mit dem richtigen IC eh immer auf COM 
am PC.
Schnell etwas mit Symbolen zusammenklicken und für nicht kommerzielle 
Zwecke free.

von J. S. (jojos)


Lesenswert?

Dann schon lieber nodejs und Webbrowser als Labview. NI installiert dir 
ein Dutzend Dienste und Unmengen an Software die du nie mehr vom Rechner 
bekommst. Dazu die penetrante Werbung.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

So, das war erst einmal eine ganze Menge Input zum Lesen.

LabView... Weiß ich nicht, das könnte eine Sackgasse sein, von der ich 
später nichts weiterverwenden kann.

Daß es auf eine virtuelle COM-Schnittstelle hinausläuft bzw. daß man 
diese Form der Anbindung mit einem FT232 unter Windows so nennt, da bin 
ich mir inzwischen sehr sicher.

Basic-ähnliche Sprachen wollte ich meiden, da diese meiner Meinung nach 
am Aussterben sind. Aber ich würde sie nehmen wenn ich da ein gutes 
Programmgerüst für das was ich brauche bekommen könnte.

An den C-Varianten wäre halt der Vorteil, daß ich davon evtl. später 
noch irgendwas brauchen kann, wenn ich nicht mehr um die ARM Cortex 
Prozessoren (oder irgendwas anderes, was deutlich komplexer ist als die 
AVRs) herumkomme. Dann muss ich definitiv irgendwas mit C lernen.

@Thomas W und C-hater
Ich habe im Moment leider nicht die Zeit, um direkt etwas selbst 
anzufangen und mich da lange hineinzuarbeiten. Das ist mein Problem, 
warum ich den Thread eigentlich angefangen habe. Deswegen habe ich ja 
gesagt, ich suche wen, der so ein Grundgerüst erstellen kann was auch 
wirklich gut funktioniert, mit dem ich später gut und schnell 
weiterarbeiten kann. Wenn jemand ohne größe Mühe sowas bauen kann, dann 
soll er sagen was er dafür haben möchte oder wie ich mich revanchieren 
könnte und dann schauen wir weiter.

Danke Dir aber trotzdem für Deinen Vorschlag Thomas. Wenn ich es 
irgendwann doch komplett selbst machen muss - wobei das aber leider noch 
ein wenig warten muss, ich muss vorher ein Universal-BMS fertig kriegen 
und dafür das µC-Programm mit der ganzen Überwachung und 
Balancing-Strategie schreiben. Wenn ich niemanden finde, der mir hilft, 
werde ich es später wahrscheinlich in C# oder in dieser 
Chrome-JS-Variante versuchen. Letztere kann man evtl. als Framework 
verwenden, so daß es vielleicht auch unter Linux oder MacOS laufen 
könnte falls M$ sich mit Win11 und ihrem übertriebenen Sicherheitswahn 
bei nicht durch M$ signierter Software großkalibrig ins eigene Knie 
schießen sollte.

von Εrnst B. (ernst)


Lesenswert?

Ben B. schrieb:
> Wenn jemand ohne größe Mühe sowas bauen kann

ChatGPT schmeißt dir mit ein paar hingeworfenen Keywords das Grundgerüst 
fix und fertig raus, in der Sprache und mit dem Framework deiner Wahl.

Gerade solche No-Brain 08/15 Programmieraufgaben kann man da sehr gut 
outsourcen.

von Martin H. (horo)


Lesenswert?

Ben B. schrieb:
> Basic-ähnliche Sprachen wollte ich meiden, da diese meiner Meinung nach
> am Aussterben sind. Aber ich würde sie nehmen wenn ich da ein gutes
> Programmgerüst für das was ich brauche bekommen könnte.

Ähnlich schnell schreibst Du ein kurzes Script mit Python ohne große 
Übersetzungsorgien. Python wird interpretiert und liefert eine Unmenge 
von Bibliotheken für alle möglichen Zwecke bereits mit, für die 
graphische Ausgabe kannst Du mehrere Varianten wählen, unter anderem 
sind auch komplette Qt-Bindings verfügbar.
Ein Beispiel für ein (großes) Projekt Qt-Python-USB-Seriell ist der 
NanoVNASaver, schau Dir mal den Screenshot an, ob Dir das zusagt.
https://github.com/NanoVNA-Saver/nanovna-saver

von Harald K. (kirnbichler)


Lesenswert?

Martin H. schrieb:
> Ähnlich schnell schreibst Du ein kurzes Script mit Python ohne große
> Übersetzungsorgien.

Es ist aber ein Krampf im Arsch, so ein Skript dann auszuliefern, denn 
auf normalen PCs ist kein Python installiert, und etwaige Zusätze erst 
recht nicht.

Der Vorzug in sich abgeschlossener Binaries, die kein weiteres Geraffel 
benötigen, macht sich in solchen Situationen schon  bemerkbar.

von Thomas W. (Gast)


Lesenswert?

Ben B. schrieb:
> @Thomas W und C-hater
> Ich habe im Moment leider nicht die Zeit, um direkt etwas selbst
> anzufangen und mich da lange hineinzuarbeiten. Das ist mein Problem,
> warum ich den Thread eigentlich angefangen habe. Deswegen habe ich ja
> gesagt, ich suche wen, der so ein Grundgerüst erstellen kann was auch
> wirklich gut funktioniert, mit dem ich später gut und schnell
> weiterarbeiten kann. Wenn jemand ohne größe Mühe sowas bauen kann, dann
> soll er sagen was er dafür haben möchte oder wie ich mich revanchieren
> könnte und dann schauen wir weiter.

Ich habe mal eben BetterSerialMonitor von Github 
(https://github.com/nathandunk/BetterSerialPlotter.git) runtergeladen, 
in mein VisualStudio 2019 eingelesen, CMake startet von sich selbst und 
dann ausfuehren... Wenn ich das mit den make-Orgien in den 90'er 
vergleiche ist das Genial.

Wenn Du so oder so "windows-zentrisch" bleiben willst/musst/kannst, sind 
die Kosten und der Aufwand ueberschaubar. Es gibt wieder ein paar 
Details die einem das Leben schwer machen, ist aber beherrschbar.

Gruesse

Th.

P.S.: Ich habe heute morgen mal eine halbe Stunde Restlebenszeit 
verschwendet den Legalize der (L)GPL zu verstehen. So als 
Naturwissenschaftler ist das nicht so ganz zu verstehen, vielleicht muss 
man als Jurist geboren sein (oder vielleicht 1x Lobotomie als Therapie). 
Oder ein Ticket fuer die B-Arche.

von Purzel H. (hacky)


Lesenswert?

Der Troll hat's nach 30 Posts noch nicht weit gebracht. Naja, die 
Anforderungen sind auch etwas ueberzogen. Null Ahnung von Windows, mit 
der seriellen Schnittstelle bei DOS stehengeblieben. Ich wuerd mal einen 
Monat an Windows Software werfen. zB C# oder Delphi.

von Joe J. (j_955)


Lesenswert?

Harald K. schrieb:
> Martin H. schrieb:
>> Ähnlich schnell schreibst Du ein kurzes Script mit Python ohne große
>> Übersetzungsorgien.
>
> Es ist aber ein Krampf im Arsch, so ein Skript dann auszuliefern, denn
> auf normalen PCs ist kein Python installiert, und etwaige Zusätze erst
> recht nicht.
>
> Der Vorzug in sich abgeschlossener Binaries, die kein weiteres Geraffel
> benötigen, macht sich in solchen Situationen schon  bemerkbar.

Nicht in jedem Arsch....Es gibt auch die Möglichkeit eine vollwärtige 
Exe aus python-libs und Custom Skript zu bauen. Die kannst dann überall 
ausführen. Tatsächlich auch mein Mittel der Wahl.

Kriegst du denn die Gegenseite hin auf dem Controller? Das kann gut 
gehen, ist aber auch mit größerem Arbeitsaufwand verbunden.
Wird vmtl. ohnehin nix komerzielles werden.

von Joe J. (j_955)


Lesenswert?

Serielles UART reicht doch um ein paar Messwerte rauszupumpen. Was hälst 
dich denn mit dem ganzen USb-Zeug überhaupt auf?

Edit:
Was heisst, leider lebt nur noch USB?

: Bearbeitet durch User
von Joe J. (j_955)


Lesenswert?

Ben B. schrieb:
> der das mit wenig Aufwand bereits
> hat oder kann, oder vielleicht kann ich irgendwo anders zurück-helfen
> oder irgendwas tauschen...

Ich hätte gerne ein Cabriolet.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

@Purzel
Zuerst einmal vielen Dank für das Kompliment, denn so wie das aussieht, 
hast Du es noch zu viel weniger gebracht wenn Du hier wahllos die Leute 
beschimpfen musst. Bist Du als Kind ein paar mal zu oft auf den Kopf 
gepurzelt (worden) oder woher kommen Deine sozialen Probleme?

> Serielles UART reicht doch um ein paar Messwerte rauszupumpen.
> Was hälst dich denn mit dem ganzen USb-Zeug überhaupt auf?
> Was heisst, leider lebt nur noch USB?
Theoretisch würde mir RS232 natürlich völlig reichen.
Praktisch hat keiner meiner Rechner einen Sub-D9 Anschluss mehr, alles 
nur noch USB.

> Ich hätte gerne ein Cabriolet.
Das geht schneller als Du denkst, 'ne Flex habe ich da.

Edit:
Sorry habe ich übersehen:
> Kriegst du denn die Gegenseite hin auf dem Controller?
Ja, das ist kein Problem.

> Wird vmtl. ohnehin nix komerzielles werden.
Vorerst nichts geplant, ausschließen kann man es nie.

So, danke für den aufgeheiterten Nachmittag, über ein ernsthaftes 
Angebot würde ich mich natürlich weiterhin freuen.

: Bearbeitet durch User
von Joe J. (j_955)


Angehängte Dateien:

Lesenswert?

Ben B. schrieb:
> Theoretisch würde mir RS232 natürlich völlig reichen.
> Praktisch hat keiner meiner Rechner einen Sub-D9 Anschluss mehr, alles
> nur noch USB.

OK, dann scheitert es nur daran. Guck mal->im Anhang -> das sind 
gängige USB/Seriell Konverter für SUB-D. Die verwenden wir in der 
Entwicklung auch hin und wieder. Serielles UART ist nach wie vor in der 
Entwicklung gängig um debug Informationen etc auszugeben.

Theoretisch reicht es auch aus, wenn du nur Tx/Rx+GND rausziehst auf 
eine Stiftleiste. Da gibt es dann noch schlankere Lösungen.

Viel Erfolg!

Edit:
Für eine serielle kannst du mit Python ganz schnell was zusammenklicken. 
Und eine UI mit PyQt+numpy für Grafen. Da ist die Lernkurve nicht 
sonderlich steil, du musst ja nicht alles im Detail verstehen auf 
Anhieb.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Hmm... sagen wir's mal so, ein solches Adapterkabel wollte ich mit dem 
FT232 mehr oder weniger auf der Platine integrieren, weil in dem Kabel 
ist auch nichts anderes drin.

Vielleicht hätte ich schreiben sollen, daß die Hardware ein eher kleines 
Problem ist, das größere Problem ist die Windows-Programmierung. Sorry 
wenn ich Dich da auf eine falsche Fährte geschickt habe.

Es gibt halt leider noch Dinge auf der Welt, die ich in diesem Leben 
noch nicht gemacht habe - eines davon ist die Programmierung eines 
Windows-Programms, welches im Fenster- und nicht im Konsolenmodus 
arbeitet. Man kann halt nicht immer schon alles schon kennen/können und 
mir fehlt im Moment die Zeit, mich konzentriert in die 
Windows-Programmierung reinzuarbeiten, da die freie Zeit für den 
Speicherbau und das BMS dafür draufgeht. Deswegen hoffe ich da auf Hilfe 
von jemandem, der sich mit der Windows-Programmierung - am besten in 
C/C++/C# auskennt. Qt weiß ich nicht, da haben Leute in diesem Thread 
geschrieben, daß man dann den Quellcode zwingend offenlegen muss und das 
möchte ich nicht. C-basierende Sprachen könnten auch ein Vorteil sein 
wenn ich mich irgendwann in die µC-Programmierung mit C reinarbeiten 
muss sobald ich irgendwo einen µC programmieren muss, bei dem das nicht 
mehr so einfach in Assembler geht wie bei den AVRs.

Gemessen an Purzels Maßstäben: Ich habe auch noch niemanden erschossen, 
macht mich das ebenfalls zu einem schlechteren Menschen?

Wie gesagt, ich muss es nicht geschenkt haben. Wenn es ein wenig Geld 
kostet oder ich evtl. gegen irgendwas tauschen kann, dann ist das in 
Ordnung. Mal sehen, vielleicht packe ich irgendwann nochmal einen Thread 
in den Marktplatz und hoffe, daß ich dann jemanden finde, der mir so ein 
Grundgerüst erstellen mag ohne mich dafür als Troll zu beschimpfen.

von Oliver S. (oliverso)


Lesenswert?

Ben B. schrieb:
> Qt weiß ich nicht, da haben Leute in diesem Thread
> geschrieben, daß man dann den Quellcode zwingend offenlegen muss und das
> möchte ich nicht.

Na ja, solange du da in deinem stillen Kämmerlein vor dich hin 
programmierst, und das Progrämmchen auch an niemanden weiter gibst, 
musst du natürlich auch nichts offenlegen.

Oliver

von Martin H. (horo)


Lesenswert?

Ben B. schrieb:
> Qt weiß ich nicht, da haben Leute in diesem Thread
> geschrieben, daß man dann den Quellcode zwingend offenlegen muss und das
> möchte ich nicht.

NEIN - Qt ist weitestgehend LGPL, nur wenn Du einige spezielle Module 
brauchst, musst Du Dich für GPL oder kommerziell entscheiden.

The primary open-source license is the GNU Lesser General Public License 
v. 3 (“LGPL”). With the LGPL license option, you can use the essential 
libraries and some add-on libraries of Qt. This allows for keeping your 
application source code closed as long as all the requirements of LGPLv3 
are met. More details are available below.

https://www.qt.io/licensing/open-source-lgpl-obligations#lgpl

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Na ja, solange du da in deinem stillen Kämmerlein vor dich hin
> programmierst, und das Progrämmchen auch an niemanden weiter
> gibst, musst du natürlich auch nichts offenlegen.

Man weiß ja immer nie, ob's tatsächlich dabei bleibt oder ob doch noch 
irgendwer anders das Programm haben möchte und man es ihm auch geben 
würde - aber ohne, daß man den kompletten Code offenlegen möchte.

Ich möchte mir nicht von Anfang an irgendwelche Möglichkeiten verbauen, 
zumal ich im Moment noch nicht mal viel über das Programm weiß oder was 
es einmal tatsächlich werden wird.

Die ganzen (L)GPLs in hunderten Versionen möchte ich einfach vermeiden. 
Ich habe zu wenige Doktor- und Professorentitel in Jura, um diese 
tausend Versuche einer eierlegenden Wollmilchsau gut genug zu verstehen 
und bei ihrer Anwendung keine Fehler zu machen.

Daher nochmal, Qt ist eigentlich gestorben, richtig freuen würde ich 
mich über C/C++, gleich danach C# und wenn mir jemand helfen mag, der 
nur VB kann oder so, dann würde ich sowas auch nicht ausschließen wenn 
es gut funktioniert. Wichtig wäre, daß ich die Toolchain dazu übernehmen 
kann. Irgend ein "the best compiler" kann wirklich toll sein - bringt 
mir aber nichts wenn ich den nirgendwo bekomme oder nicht nutzen darf.

von Εrnst B. (ernst)


Lesenswert?

Ben B. schrieb:
> Daher nochmal, Qt ist eigentlich gestorben, richtig freuen würde ich
> mich über C/C++

Wenn die QT wegen der komplizierten LGPL-Lizenz für dich gestorben ist, 
wird's schwierig... wxWidgets ist auch LGPL (+ein paar Ergänzungen, also 
noch komplizierter), GTK & FLTK ebenfalls...

Ben B. schrieb:
> gleich danach C#

Windows Forms für .NET ist unter einer MIT-Free-Software-License. Die 
ist wesentlich kürzer und hoffentlich einfacher zu verstehen als die 
LGPL.

Tk gäb's noch für C (oder TCL, Python, Perl, whatever), steinalt, 
Cross-Plattform und BSD-Lizenz.

von Thomas W. (Gast)


Lesenswert?

Ben B. schrieb:

> es gut funktioniert. Wichtig wäre, daß ich die Toolchain dazu übernehmen
> kann. Irgend ein "the best compiler" kann wirklich toll sein - bringt
> mir aber nichts wenn ich den nirgendwo bekomme oder nicht nutzen darf.

Ich hatte Dir ja in
Beitrag "Re: Suche Programmgerüst: USB-Kommunikation und Daten Ein/Ausgabe Windows"
einen Vorschlag fuer einen Plotter (darauf laeuft es ja hinaus). Hattest 
Du Dir Visual Studio installiert und z.B. 
https://github.com/nathandunk/BetterSerialPlotter.git geladen und 
kompiliert?

Einfacher geht es wirklich nicht. Oder mal Google mit "github serial 
plotter" gefuettert und die vier Ergebnis-Seiten angeguckt? Oder 
erwartest Du dass jemand fuer Dich eine individuelle SW konzipiert und 
implementiert? Fuer Gottes Lohn? Wenn Du erwartest dass jemand fuer Dich 
arbeitet musst Du mal in Vorleistung gehen und etwas zeigen.

Gruesse

Th.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Ich hatte es überflogen, aber noch nichts installiert oder ausprobiert. 
Ich habe dafür im Augenblick wirklich nicht die Zeit und deswegen hatte 
ich jemanden gesucht, der mir evtl. für kleines Geld die Anfänge 
abnehmen mag weil das für ihn kein großes Problem ist.

Na gut, sehe ein es bringt nichts. Vielleicht frage ich nochmal im 
Marktplatz oder mal sehen ob ich ein C/C++/C# Windows-Programmiererforum 
finde... wenn nicht muss ich es in die Zukunft schieben und wenn's so 
weit ist sehen, wie lange das Projekt beim Reinarbeiten dann wieder im 
Stillstand ist. Dann ist das eben so.

Danke trotzdem an die, die ernsthaft helfen wollten.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Εrnst B. schrieb:
> Ben B. schrieb:
>> Daher nochmal, Qt ist eigentlich gestorben, richtig freuen würde ich
>> mich über C/C++
>
> Wenn die QT wegen der komplizierten LGPL-Lizenz für dich gestorben ist,
> wird's schwierig... wxWidgets ist auch LGPL (+ein paar Ergänzungen, also
> noch komplizierter), GTK & FLTK ebenfalls...
>

Ähm... zumindest wenn du C++ unter dem GCC nutzt, hast du schon mit der 
LGPL zu tun.
LVMM ist zwar Apache 2.0, aber "public-domain" ist das auch nicht.

73

von Stefan F. (Gast)


Lesenswert?

Ben B. schrieb:
> Qt weiß ich nicht, da haben Leute in diesem Thread
> geschrieben, daß man dann den Quellcode zwingend offenlegen muss und das
> möchte ich nicht.

Wie gesagt und nachgewiesen wurden, ist das nicht richtig.

> C-basierende Sprachen könnten auch ein Vorteil sein
> wenn ich mich irgendwann in die µC-Programmierung mit
> C reinarbeiten muss

Genau deswegen ist C++ und Qt für mich auch attraktiv. In einem Anflug 
von Langeweile hatte ich mal ein Tutorial für Qt geschrieben: 
http://stefanfrings.de/qt_lernen/index.html

> Ich möchte mir nicht von Anfang an irgendwelche Möglichkeiten verbauen,

Du verbaust dir mit Qt gar nichts. Die wenigem Module die nicht unter 
LGPL stehen sind allesamt optional, ich habe sie noch nie gebraucht und 
außerdem gibt es alternativen von anderen Autoren.

> Daher nochmal, Qt ist eigentlich gestorben, richtig freuen würde ich
> mich über C/C++, gleich danach C# und wenn mir jemand helfen mag, der
> nur VB kann oder so

Qt ist eine C++ Bibliothek.

C# und VB klingt für mich so, als ob du nur an Windows denkst. Falls ich 
damit richtig liege: das kann viel schneller in eine Sackgasse führen, 
als du denkst.

von Thomas W. (Gast)


Lesenswert?

Ben B. schrieb:
> Ich hatte es überflogen, aber noch nichts installiert oder ausprobiert.
> Ich habe dafür im Augenblick wirklich nicht die Zeit und deswegen hatte
> ich jemanden gesucht, der mir evtl. für kleines Geld die Anfänge
> abnehmen mag weil das für ihn kein großes Problem ist.

Du erwartest einen Architekten und Programmierer fuer "eventuell fuer 
kleines Geld". Mit der Zeit, die Du in Deine Posterei versenkt hast, 
haettest Du schon laengst Du Visual Studio installieren koennen und 
jetzt so gar Ergebnisse haben. Logischer Schluss: Du suchst einen 
Deppen.

Wir wuenschen Ihnen alles Gute auf Ihrem weiteren Lebensweg. Wir melden 
uns bei Ihnen, bitte sehen Sie von Nachfragen ab.

Mit freundlichen Gruessen

Th.

von Thomas W. (Gast)


Lesenswert?

Stefan F. schrieb:
> Ben B. schrieb:

> C# und VB klingt für mich so, als ob du nur an Windows denkst. Falls ich
> damit richtig liege: das kann viel schneller in eine Sackgasse führen,
> als du denkst.

Hatte er von Anfang an gesagt/geschrieben: 
Beitrag "Suche Programmgerüst: USB-Kommunikation und Daten Ein/Ausgabe Windows"

Wenn ihm das so reicht, ist das auch OK (die MS-Produkte sind nicht so 
schlecht, der Nutzerkreis ist gross, die Problematik mit den 
Code-Signing kann man umgehen). Gleichzeitig moechte er die 
Einschraenkungen der (L)GPL nicht akzepieren, auch die Taler fuer die 
kommerzielle Lizenz nicht zahlen (insbesondere, weil er auch die 
kommerzielle Nutzung nicht ausschliessen will
[explizit hier: 
Beitrag "Re: Suche Programmgerüst: USB-Kommunikation und Daten Ein/Ausgabe Windows" ])

Genuegend Restleben verschwendet.

Gruesse

Th.

von C-hater (c-hater)


Lesenswert?

Stefan F. schrieb:

> C# und VB klingt für mich so, als ob du nur an Windows denkst. Falls ich
> damit richtig liege: das kann viel schneller in eine Sackgasse führen,
> als du denkst.

.Net-Anwendungen laufen mit Mono auch weitestgehend problemlos unter 
Linux. Naja, zumindest wenn man sich wirklich auf das .Net-Framework 
beschränkt und nicht zusätzlichen Win32-API-Kram "importiert".

Dann muss man genau diese drangestrickten Teile selber auf das API des 
anderen Zielsystems abbilden. Auch machbar, aber natürlich zumindest 
nicht ganz so einfach.

Aber in der konkreten Anwendung sehe ich sowieso keinerlei ernsthafte 
Notwendigkeit dafür. Klar: mit dem Setup-API von Windows kann man die 
Auswahl des "COM-Ports" für den Nutzer deutlich komfortabler oder sogar 
ganz überflüssig machen (also automatisieren). Das war's aber auch schon 
so ziemlich.
Dabei geht's vor allem darum, den Port dem USB-Gerät zuzuordnen und dann 
dessen Eigenschaften mit zur Auswahl heranzuziehen. Zum Glück wird unter 
Linux praktisch alles von diesem Zeug im Filesystem abgebildet. Und der 
Filesystemzugriff ist natürlich Teil des .Net-Framework. Ein Port des 
unter Windows mit Hilfe des Setup-API geschaffenen Luxus ist also recht 
problemlos möglich, aber es ist natürlich trotzdem neu zu schreiben.

Der ganze Rest der Anwendung, also die eigentliche Funktionalität, 
sollte sich aber sowieso komplett und problemlos mit den Möglichkeiten 
des Framework abhandeln lassen und ohne jegliche Anpassungen auch unter 
Mono funktionieren. Naja, wenn man gleich beim Programmieren auch die 
Portabilität im Auge hatte und nicht z.B. hart Pfade mit + "\\" + oder 
so zusammenbastelt. Sowas ist natürlich tödlich...

von Stefan F. (Gast)


Lesenswert?

Ich meinte jetzt auch nicht, dass die Programmiersprache .Net schnell in 
eine Sackgasse führt, sondern die Fokussierung auf Windows.

Mac OS, Linux, Android erfreuen sich wachsender Beliebtheit, ebenso 
Web/Browser Anwendungen.

von C-hater (c-hater)


Lesenswert?

Stefan F. schrieb:

> Ich meinte jetzt auch nicht, dass die Programmiersprache .Net schnell in
> eine Sackgasse führt, sondern die Fokussierung auf Windows.
>
> Mac OS, Linux, Android erfreuen sich wachsender Beliebtheit, ebenso
> Web/Browser Anwendungen.

Naja, Microsoft tut derzeit alles dafür, Windows unattraktiver zu 
machen. Das hat schon Folgen. Aber so lange sie sich z.B. in Deutschland 
noch auf >> 90% der Desktop-Installationen als Basis verlassen können, 
können sie halt ihr Ding durchziehen. Das sind BWLer, die das tun. Die 
können immer nur ein Quartal in die Zukunft schauen und sind krass 
unfähig dazu, langfristig zu denken.

MacOS/IOS ist jedenfalls definitiv kein Ausweg. Das war von Anfang an 
noch viel schlimmer kastriert und zugenagelt, als es Windows jemals war.
Android hingegen basiert auf Linux und alle wesentliche Teile des 
.Net-Framework laufen auch darauf. Siehe Xamarin. Ich habe schon 
etliches mit dem VS geschreiben, was letztlich auf Android laufen sollte 
(und das auch tut ;o)

Und mit diesem ganzen Web-Technologie-Gedöhns habe ich ein ernsthaftes 
Problem. Das ist:
-vergleichsweise langsam
-vergleichsweise unkomfortabel
-unsicher (zumindest potentiell)

Und zwar genau deshalb, weil hier der Brwoser des Benutzers (und all 
seine Sicherheitslücken) der single point of failure ist. Er ist halt 
durch die Benutzung für's Web hoch exponiert als Angriffsfläche. Da kann 
man nicht wollen, dass dasselbe Teil für ggf. sicherheitskritische 
lokale oder "LAN-lokale" Anwendungen genutzt wird. Wer das tut, spielt 
mit dem Feuer.

Und dass dieses Angriffsfläche existiert und genutzt wird, daran kann es 
ja wohl angesichts der reinen Zahl der Sicherheits-Fixes der Browser 
keinerlei Zweifel geben.

Natürlich sind eigene Anwendungen auch nicht fehlerfrei und mit einiger 
Wahrscheinlichkeit mit Sicherheitslücken gespickt. Aber sie sind halt 
nicht exponiert und damit kein attraktives und leicht anzugreifendes 
Ziel.

von Thomas W. (Gast)


Lesenswert?

C-hater schrieb:
> Und mit diesem ganzen Web-Technologie-Gedöhns habe ich ein ernsthaftes
> Problem. Das ist:
> -vergleichsweise langsam
> -vergleichsweise unkomfortabel
> -unsicher (zumindest potentiell)

Vor allen Dingen ist die Halbwertszeit fuer die Frameworks in der 
Groessenordnung einer Mus musculus, also 24 Monate. Und der 
Programmierer/Architekt der Applikation hat ja die Lebenszeit des 
Frameworks ueberhaupt nicht in der Hand (und Update/Upgrade-Path gibt es 
meistens nicht).

Gruesse

Th.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Oh oh oh ... man habe ich mich da schon oft zum Deppen gemacht wenn ich 
irgendwelche Codefetzen irgendwelcher Webseiten für andere geschrieben 
habe... und das nicht mal für kleines Geld, sondern komplett kostenlos.

Nochmal: ICH HABE IM MOMENT NICHT DIE ZEIT mich großartig in das Thema 
Windows-Programmierung einzuarbeiten und mir alles selbst herzuleiten, 
aber ich bräuchte den Anfang und einen Weg für das Programm. Wenn ich 
dafür schon Geld oder sonstewas anbiete anstatt es einfach nur stumpf 
kostenlos zu wollen, dann braucht man das auch nicht runterzuputzen nur 
weil ich nicht jedem gleich eine Luxusvilla mit Oldtimersammlung oder 
was immer euch da vorschwebt bezahlen werde.

Ich weiß auch nicht mal wieviele Zeilen Code für so ein Programmgerüst 
in C++/C# oder VB notwendig sind. Kann sein es sind hunderte, kann sein, 
es ist mit 50 Zeilen erledigt, ein Fenster mit etwas Text und 
Eingabefeld aufzumachen, das USB-Device zu finden und mit diesem Daten 
auszutauschen. Ihr habt sowas nicht mal dargelegt, nicht mal einen 
Preisvorschlag gemacht, stattdessen wird nur rumgemotzt. Gut, wenn's 
euch zu gut geht, daß 200..300 Euro oder was man dafür hätte geben und 
verlangen können, für euch nichts mehr wert sind, dann ist das eben so.

Dieses Forum hier scheint immer mehr den Bach runter zu gehen. Entweder 
wegen solcher dummen Bemerkungen oder weil man sowieso ständig an andere 
Stellen verwiesen wird.

Kaffeemaschine wird nicht mehr heiß? Dann frag doch im 
Kaffemaschinenforum.

Taschenrechner hat 'ne leere Batterie und 'ne Solarzelle? Dann frag im 
Batterie- oder Solarforum.

Kühlschrank hat ein Problem? Dann frag im Haustechnikforum, Kategorie 
Kühlschrank.

PC-Netzteil geht nicht mehr? Dann frag im PC-Forum, Kategorie Netzteile.

Welchen Vorwiderstand braucht eine LED? Wird ausnahmsweise in diesem 
Forum behandelt (solange man es bei Analogtechnik postet, in µC und 
Elektronik wird der TE standrechtliche erschossen), aber auch nicht mit 
konkreten kurzen Vorschlägen, sondern mit ganzen Romanen wie dumm denn 
der TE wäre, daß er das nicht selber weiß weil's seine erste 
LED-Ansteuerung ist und warum man sich selbst ja nicht zum Deppen machen 
will, wenn man ihm das schnell ausrechnet.

Na dann werde ich mal nach einem C/C++/C# Forum googeln. Das schaffe ich 
sogar ohne Googleforum, braucht ihr mich nicht hinzuschicken.

von Steve van de Grens (roehrmond)


Lesenswert?

C-hater schrieb:
> Aber so lange sie sich z.B. in Deutschland
> noch auf >> 90% der Desktop-Installationen als Basis verlassen können,
> können sie halt ihr Ding durchziehen.

Ich dachte Apple hätte bereits etwa 30% Marktanteil

> MacOS/IOS ist jedenfalls definitiv kein Ausweg. Das war von Anfang an
> noch viel schlimmer kastriert und zugenagelt, als es Windows jemals war.

Ja, aber es hat eine andere Art von Menschen als Fan-Gemeinde. Die 
finden das so gut, wie es ist.

Ben B. schrieb:
> ICH HABE IM MOMENT NICHT DIE ZEIT

Irgendwie komme ich da nicht mit, so rein logisch.

Du hast also nicht die zeit, dir mit den gängigen Assistenten der 
Entwicklungsumgebungen ein Grundgerüst zusammen zu klicken und (manuell) 
die serielle Kommunikation hinzuzufügen. Ok, kann sein.

Aber wenn du schon dafür nicht genug Zeit hast, dann wirst du auch nicht 
imstande sein, daraus ein sinnvolles Anwendungsprogramm zu machen. Was 
willst du mit dem Grundgerüst anfangen?

> Gut, wenn's euch zu gut geht, daß 200..300 Euro oder was man dafür hätte
> geben und verlangen können, für euch nichts mehr wert sind, dann ist das
> eben so.

Hänge da mindestens eine Null dran, um in einen realistischen bereich zu 
kommen. Und mache dich darauf gefasst, ein Anforderungsdokument 
schreiben zu müssen, sonst bekommst du "irgend etwas" aber nichts was 
dir hilft.

> Dieses Forum hier scheint immer mehr den Bach runter zu gehen.

Du hast eine falsche Erwartungshaltung. Wenn du einen Auftrag zu 
vergeben hast, dann beauftrage eine Fachfirma direkt (nicht hier), oder 
nutze wenigstens den Bereich 
https://www.mikrocontroller.net/forum/ausbildung-studium-beruf . Hier 
wird nur diskutiert, das hat so seine Richtigkeit.

Und: Ein konkretes Angebot erfordert konkrete Anforderungen.

: Bearbeitet durch User
Beitrag #7410522 wurde vom Autor gelöscht.
von Joerg W. (joergwolfram)


Lesenswert?

Falls es was hilft:

bei meinem PDP11-Emulator (in C geschrieben)

https://www.jcwolfram.de/projekte/mxe11/main.php

gib es in der letzten Version (1.74) auch die Möglichkeit, das für 
Windows zu compilieren (Mingw32). Die Oberfläche ist halt SDL und man 
muss den Port als Parameter angeben. Installation ist nicht vorgesehen, 
wenn man die Bibliotheken mit ins Verzeichnis packt, lässt sich das auch 
problemlos vom USB-Stick aus starten. Ggf. könnte ich daraus auch ein 
minimales Gerüst extrahieren, allerdings nur insoweit, dass man es unter 
Linux Cross-kompilieren kann.

Jörg

von Joe J. (j_955)


Lesenswert?

Ben B. schrieb:
> C-basierende Sprachen könnten auch ein Vorteil sein
> wenn ich mich irgendwann in die µC-Programmierung mit C reinarbeiten
> muss sobald ich irgendwo einen µC programmieren muss,bei dem das nicht
> mehr so einfach in Assembler geht wie bei den AVRs.
Ähhm...OMG. Ich glaube, der ganze Thread ist eine Verarsche;-)

: Bearbeitet durch User
von Rolf M. (rmagnus)


Lesenswert?

Steve van de Grens schrieb:
> C-hater schrieb:
>> Aber so lange sie sich z.B. in Deutschland
>> noch auf >> 90% der Desktop-Installationen als Basis verlassen können,
>> können sie halt ihr Ding durchziehen.
>
> Ich dachte Apple hätte bereits etwa 30% Marktanteil

Solche Behauptungen stellt er schon mal gerne auf, aber wo er die Zahlen 
her hat, will er nicht verraten. Vermutlich wie 83,7% aller Statistiken 
spontan erfunden 😀. Laut 
https://gs.statcounter.com/os-market-share/desktop/worldwide waren es 
Ende letzten Jahres so um die 75% weltweit. Jetzt liegt der Wert bei 
63%, allerdings hauptsächlich ersetzt durch "Unknown". Der Anteil von 
MacOS liegt demnach bei knapp 18%.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

>> Assembler [..] AVR
> Ähhm...OMG. Ich glaube, der ganze Thread ist eine Verarsche;-)
Nur weil Du zu dumm für AVR-Assembler bist, heißt das nicht,
daß andere das nicht gut können.

>> 200..300 Euro
> Hänge da mindestens eine Null dran, um
> in einen realistischen bereich zu kommen.
Aber Du hast Recht, jetzt wird der Thread eine Verarsche.

Wenn mich das nächste mal jemand nach einem Stück Code für einen AVR 
fragt, werde ich ihm eure Postings verlinken. Und anschließend die 
Saltos zählen, die der Arme dann rückwärts macht.

Nur falls das noch von Relevanz sein sollte:

> Du hast also nicht die zeit, dir mit den gängigen Assistenten
> der Entwicklungsumgebungen ein Grundgerüst zusammen zu klicken
> und (manuell) die serielle Kommunikation hinzuzufügen.
Nein, weil es tausend verschiedene Möglichkeiten dafür gibt und ich 
schlicht nicht weiß, welche davon die am besten geeignete ist. Ich 
möchte mich nur sehr ungerne stundenlang mit einer dieser Möglichkeiten 
befassen und sowas wie ein Hallo Welt schreiben, nur um einen Tag später 
herauszufinden, daß der Ansatz falsch war und die gewählte 
Sprache/Framework gar nicht taugt.

> Aber wenn du schon dafür nicht genug Zeit hast, dann wirst du auch
> nicht imstande sein, daraus ein sinnvolles Anwendungsprogramm
> zu machen. Was willst du mit dem Grundgerüst anfangen?
Das enthält zumindest alle Funktionsaufrufe die ich brauche, um ein 
Fenster zu öffnen, da irgendwelchen Text reinzuschreiben und die 
USB-Kommunikation. Selbst wenn das nur ein Fenster aufmacht, ein "Hallo 
Welt" reinschreibt und ein Eingabefeld bereitstellt, dessen Inhalt man 
hinterher in einer Variablen oder so wiederfindet. Oder nur das 
USB-Device (FT232) sucht, dem ein "Hallo" schickt und alles was von dem 
zurückkommt in eine Variable schreibt.

Wenn ich damit anfange - egal in welcher Sprache - muss ich mir erst 
einmal alle Funktionsnamen und deren Syntax für die Aufrufe 
zusammengoogeln oder wie man den ganzen Mist am Ende compiliert. Ich 
habe schlicht keine Erfahrung mit C/C++/C#, auch nicht mit VB, Qt oder 
sonstewas. Ich könnte es unter DOS - die Zeiten sind vorbei - oder mit 
PHP wenn das nicht eine serverbasierte Sprache wäre. Wahrscheinlich 
kriege ich es sogar in PHP hin falls das USB-Devices öffnen kann und der 
FT232 am Server hängt - aber das ist nicht das was ich will weil das 
Ding hängt nicht an meinem Server.

von Andi M. (andi6510) Benutzerseite


Lesenswert?

> ChatGPT schmeißt dir mit ein paar hingeworfenen Keywords das Grundgerüst
> fix und fertig raus, in der Sprache und mit dem Framework deiner Wahl.
>
> Gerade solche No-Brain 08/15 Programmieraufgaben kann man da sehr gut
> outsourcen.

kann ich bestaetigen. Ich habe das mal ausprobiert und mir ein Programm 
generieren lassen, dass mit Visual C++ ueber die serielle Schnittstelle 
mit vorgegebenen timing (Sekundentakt) Daten ausgegeben hat, die es aus 
einer Datei zeilenweise einlesen sollte. Erst wollte ich nur das 
Grundgeruest bauen lassen. Am Ende hat ChatGPT fast das komplette 
Programm fuer mich geschrieben. Ich musste nur noch das "COM1" in ein 
"COM3" aendern und schon funktionierte es. Ich war wirklich schwer 
beeindruckt.

von Stefan F. (Gast)


Angehängte Dateien:

Lesenswert?

Fertig:
http://stefanfrings.de/net_io/ioModule-src.zip

(Für Linux, Windows und Android, in C++ mit QT Framework, aber das 
wolltest du ja nicht. So ein Käse aber auch.)

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Der will so einiges nicht.
Hat keine Ahnung von VB/C/C++/C# und will sowas mal gerade
schnell nebenbei lernen. Da nützt ihm auch kein Grundgerüst,
wenn er das nicht für seine Zwecke entsprechend abändern kann,
weil das Wissen fehlt.

Egal, welche Sprache, sowas lernt man nicht in einem Tag so
nebenbei.

Wie haben wir früher gesagt ?
Keine Zähne im Maul aber La paloma pfeifen wollen.

von Thomas W. (Gast)


Lesenswert?

Ben B. schrieb:

> PHP wenn das nicht eine serverbasierte Sprache wäre. Wahrscheinlich
> kriege ich es sogar in PHP hin falls das USB-Devices öffnen kann und der
> FT232 am Server hängt - aber das ist nicht das was ich will weil das
> Ding hängt nicht an meinem Server.

Kein Problem, das Zauberwort ist WAMP (Windows, Apache, MariaDB und, 
drumroll Please: PHP). Auf Deiner Arbeitsstation. Zugriff auf SerialPort 
geht z.B. so (aus https://www.wut.de/e-50513-00-apus-000.php):
1
<?php
2
$fd = dio_open( COM1:, O_RDWR );
3
dio_tcsetattr( $fd, array(
4
  baud         => 9600,
5
  bits         => 8,
6
  stop         => 1,
7
  parity       => 0,
8
  flow_control => 0,
9
  is_canonical => 0  ));
10
dio_write( $fd, temperatur? );
11
$input = ’’;
12
while( strlen( $input ) <= 10 )
13
  {
14
  $input .= dio_read( $fd, 1 );
15
  }
16
echo $input;
17
dio_close( $fd );
18
?>

Du Siehst: Problem geloest. Die PHP-DIO-Bibliothek macht alles fuer 
Dich. Du kannst morgen Deine Ergebnisse vorstellen, keine Lernkurve weil 
Du ja PHP kennst.

Dokumentation:
https://www.php.net/manual/en/book.dio.php

I'm happy to help.

Th.

von Udo K. (udok)


Lesenswert?

Ben B. schrieb:
> Nein, weil es tausend verschiedene Möglichkeiten dafür gibt und ich
> schlicht nicht weiß, welche davon die am besten geeignete ist. Ich
> möchte mich nur sehr ungerne stundenlang mit einer dieser Möglichkeiten
> befassen und sowas wie ein Hallo Welt schreiben, nur um einen Tag später
> herauszufinden, daß der Ansatz falsch war und die gewählte
> Sprache/Framework gar nicht taugt.

Mach es nicht komplizierter als nötig.
Du brauchst erst mal gar nichts programmieren.
Ein simples Terminal wie TeraTerm reicht erst mal.
Damit kannst du einen COM Port aufmachen, und mit deinem AVR reden.

Wenn das läuft, dann machst du ein simples Konsolenprogramm in C.
Dafür nimmst du unter Windows am besten den Visual Studio Compiler.
Die Hilfe behandelt die 5 benötigten Funktionen im Detail.

Hier dein gewünschtes Programm Gerüst:
1
    /* UART Port aufmachen */
2
    UartHandle = CreateFile("COM3", GENERIC_READ | GENERIC_WRITE,
3
                            0, NULL, OPEN_EXISTING, 0, NULL);
4
5
    /* UART Control Block (Baudrate etc.) setzen */
6
    DCB Dcb = { ... };
7
    SetCommState(UartHandle, &Dcb);
8
9
    /* UART Timeouts setzen */
10
    COMMTIMEOUTS Timeouts = { ... };
11
    SetCommTimeouts(UartHandle, &Timeouts);
12
 
13
    for (;;)
14
    {
15
         BYTE buffer[100];
16
         DWORd n, m, k;
17
18
         /* Schreibe Kommando zum AVR */
19
         WriteFile(UartHandle, buf, m, &k, NULL);
20
         
21
         /* Lese Antwort vom AVR */
22
         ReadFile(UartHandle, buf, n, &m, NULL);
23
    }

Als Framework für ein einfaches Windows Programm würde ich ein Win32 
Programm erstellen. Der Visual Studio Compiler macht dir dafür ein 
fertiges ausführbares Programmgerüst
(Neues Projekt anlegen -> Auswahl Win32 Program ->... -> Compile -> Run)

: Bearbeitet durch User
von Purzel H. (hacky)


Lesenswert?

Nochmals 40 posts spaeter .. Zeit den Poster herunterzuputzen. Sehr 
duenne, renitente Leistung.
Jetz steck endlich mal das USB Uart in den PC ein und sende/empfange in 
paar bytes. Erst mal vom controller her senden, auf dem PC empfangen, 
dann vom PC her senden, auf dem Controller empfangen.
Allenfalls kann putty oder xterm (gratis herunterladbar)  beides auf dem 
PC Auf dem Controller kann du's ja.
Uebrigens. Weshalb man erst vom Controller her sendet .. um die Baudrate 
mit dem Oszilloskop zu testen

: Bearbeitet durch User
von J. S. (jojos)


Lesenswert?

Hier im Forum ist ja gerade wieder der 'ComVisu' Thread aufgepoppt. Das 
wäre vielleicht auch eine einfache Möglichkeit, grafische Darstellung 
von seriell übertragenen Werten.
Was ist aus der Vorlage für dieses Programm geworden, den 
SerialComInstruments? Die Google Links dazu laufen ins Leere?

Dann als weiteren Tipp noch Node Red. Ist zwar erstmal ein größerer 
Brocken, aber mit sehr vielen Möglichkeiten. Wenn der µC die Daten 
gleich als JSON String sendet dann braucht man nur einen Switch Node der 
an die gewünschten Darstellungselemente weiterleitet. Oder in eine 
Datenbank. Die Darstellung über Webbrowser ist nur wenig Konfiguration.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Mit reiner RS232 habe ich bereits mit einem µC "geredet", also UART 
seitens des Controllers, HyperTerminal krieg ich alles hin. Leider ist 
eben durch das Ende der RS232-Schnittstellen bei PCs ein Anschluss via 
USB nötig geworden und HyperTerminal taugt zum Anzeigen der Rohdaten, 
aber ich wollte perspektivisch etwas "besseres" wie ein eigenes Fenster 
und daß die korrekte virtuelle serielle Schnittstelle selbst gefunden 
wird. Ich habe keinen Computer mehr, der noch RS232 hat.

@Thomas
Daß PHP das kann war mir ziemlich klar, aber das wäre nur eine Lösung 
für mich alleine, ohne daß ich das (fertig compilierte) Programm 
irgendwann auch weitergeben könnte. Es hat ja nicht jeder 'nen Webserver 
zuhause.

Wenn ich das so machen möchte, dann muss ich mir entweder wirklich 
irgendwann diese ElectronJS-Geschichte anschauen oder ich müsste mein 
Gerät mit einem XPORT oder so LAN-fähig machen. Das wäre etwas über's 
Ziel hinaus geschossen, einen eigenen Webserver wollte ich eigentlich 
nicht dafür schreiben.

Genauso wäre die Variante WLAN/WIFI/Bluetooth/NFC-irgendwas und eine 
Android-App. Auch damit (Android-Programmierung) habe ich mich noch nie 
auseinandergesetzt und ich müsste irgend ein Schnittstellenmodul auf 
meiner Platine verbauen, die WLAN oder Bluetooth kann. Aber ich würde es 
auch nicht ausschließen wenn jemand dafür ein Grundgerüst hat... ich 
nehme sozusagen fast alles was besser ist als ein Terminalprogramm und 
reines RS232.

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Bluetooth fände ich da noch besser, weil das am PC auch über
RS232 (virt. SChnittstelle) kommuniziert.
Und man hätte dann auch eine Schnittstelle fürs Smartphone.

Die BT-Module sind ja wirklich nicht mehr teuer.

von Stefan F. (Gast)


Lesenswert?

Ben, ich finde ziemlich schade, dass du dich für mein Programmgerüst 
nicht einmal kurz bedankt hast. Dabei passt es wie der Deckel auf den 
Topf, denn es ist unter LGPL Lizenz, kann seriell, Bluetooth und WLAN. 
Auf meiner Homepage findest du sogar konkrete Schaltungsvorschläge mit 
USB-UART, Bluetooth und WLAN Modulen. Dazu Bücher und Tutorials die in 
deren Programmierung einführen. Mehr Silberteller geht nun wirklich 
nicht.

Zum Austeilen von Kritik hattest du jedoch viel Zeit gefunden. Echt 
Schade.

von Harald K. (kirnbichler)


Lesenswert?

Ben B. schrieb:
> HyperTerminal taugt zum Anzeigen der Rohdaten,

Man könnte sich auch mit dem VT100-Befehlssatz auseinandersetzen und 
eine TUI damit bauen. Reicht für vieles völlig aus, und auf PC-Seite 
genügt ein Terminalprogramm, notfalls sogar das alte Hyperterminal. 
Teraterm ist eine (imho bessere) Alternative.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

@Stefan

Sorry, ich hatte noch nicht die Zeit, mich damit so weit zu 
beschäftigen, um irgend eine fundierte Meinung darüber abgeben zu 
können. Ich habe es wirklich nur zur Kenntnis genommen, kurz überflogen 
und dann als "zu groß für zwischen Tür und Angel abhandeln" eingeordnet, 
ich wollte es später noch einmal genauer durchlesen. Tut mir leid, wenn 
ich damit so weit hinter Deinen Erwartungen zurückgeblieben bin.

von T.U.Darmstadt (Gast)


Lesenswert?

Harald K. schrieb:
> Man könnte sich auch mit dem VT100-Befehlssatz auseinandersetzen

Terraterm!

von C-hater (c-hater)


Lesenswert?

Ben B. schrieb:

> Sorry, ich hatte noch nicht die Zeit, mich damit so weit zu
> beschäftigen, um irgend eine fundierte Meinung darüber abgeben zu
> können.

Du hast aber die Zeit, diesen Troll-Thread am Leben zu erhalten...

Denkst du, wir sind alle blöd?

von Harald K. (kirnbichler)


Lesenswert?

Thomas U. schrieb:
> Terraterm

Nur ein r. Teraterm. Erwähnte ich übrigens auch.

von Stefan F. (Gast)


Lesenswert?

Ben B. schrieb:
> Sorry, ich hatte noch nicht die Zeit, mich damit so weit zu
> beschäftigen

Das dir ein Programmgerüst ohne Zeit nichts nützt, war schon zu Beginn 
des Threads zu erkennen. Nimm dir die Zeit die du brauchst, wenn du es 
ernst meinst, oder lasse es bleiben. Man muss nicht alles können, aber 
seine Grenzen akzeptieren.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Man muss nicht alles können, aber seine Grenzen akzeptieren.
Das hatte ich eigentlich getan, als ich nach einem Programmgerüst 
gefragt habe... War aber für manche auch nicht richtig wie man sieht.

Ich werde sicher noch Zeit dafür finden. Irgendwann muss ich so ein 
Programm dafür bauen - oder drauf verzichten und schauen wie ich ohne 
auskomme. Aber dadurch wird es nicht wesentlich einfacher, weil ich dann 
einen Plan B mit Display usw. bauen muss. Das würde ich zwar mit 
bestehendem Wissen hinbekommen, aber ich könnte an die Grenzen des 
Displays kommen (begrenzter Platz) und Einstellungen vornehmen wird ohne 
echtes Tastenfeld auch nicht schön.

Ließe sich Dein Programm eigentlich auch ohne Qt realisieren, mit dem 
Visual Studio alleine oder so oder ist es vielfältig auf Qt angewiesen?

von Stefan F. (Gast)


Lesenswert?

Ben B. schrieb:
> Ließe sich Dein Programm eigentlich auch ohne Qt realisieren, mit dem
> Visual Studio alleine oder so oder ist es vielfältig auf Qt angewiesen?

Visual Studio ist eine IDE, in der kann man mit jedem beliebigen 
Framework programmierten. Auch Qt.

Das Programm beruht auf dem Qt Framework. Dieses zu entfernen kommt 
praktisch einer Neuentwicklung gleich. Das haben Frameworks so an sich.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Okay, also darf man Qt nicht wie eine C-Erweiterung verstehen.

Dann müsste ich irgendwann Deine Toolchain übernehmen.

von Stefan F. (Gast)


Lesenswert?

Ben B. schrieb:
> Okay, also darf man Qt nicht wie eine C-Erweiterung verstehen.

Es ist ein C++ Framework. Große Teile davon kann man als Bibliothek 
verwenden, aber mein Programm benutzt das ganze Framework - weil es 
sonst schlicht und ergreifend um ein vielfaches komplexer geworden 
wären.

Man (also du, nicht ich) könnte das auch alles in C# und .Net neu 
schreiben, aber dann läuft es nur unter Windows. Theoretisch kann man 
grafische Windows sogar in C ohne Framework schreiben, allerdings wäre 
das sehr retro, ich denke nicht, dass sich das heute noch irgendein 
Programmierer freiwillig antut.

> Dann müsste ich irgendwann Deine Toolchain übernehmen.

Die Toolchain die ich verwendet habe heißt GCC. Die ist aber weder von 
mir, noch habe ich dabei mitgewirkt. Bei Fragen zur GCC wende dich an 
https://gcc.gnu.org/

von Steve van de Grens (roehrmond)


Lesenswert?

Qt kann auch mit anderen Toolchains verwendet werden, z.B. der von 
Microsoft.

Ich halte es nicht für sinnvoll, als Anfänger nach der optimalen Lösung 
zu suchen, vor allem nicht ohne konkrete harte Anforderungen. Als 
Anfänger neigt man dazu, die selbst gesetzten Entscheidungskriterien 
sinnlos zu gewichten und andere wichtige Aspekte weg zu lassen (weil man 
sie nicht kennt).

Mit der Zeit wirst du mehr Erfahrung sammeln und besser entscheiden. 
Deswegen reicht es für den Anfang, irgend etwas halbwegs 
funktionierendes zu haben. Verbessern kann man dann immer noch, auch 
Neu-Schreiben ist kein Weltuntergang.

: Bearbeitet durch User
von Klaus S. (kseege)


Lesenswert?

Ben B. schrieb:
> Sorry, ich hatte noch nicht die Zeit, mich damit so weit zu
> beschäftigen, um irgend eine fundierte Meinung darüber abgeben zu
> können.

Ist auch kein Wunder, da die bisherigen Empfehlungen alle Lösungen 
anboten, die (aus meiner Sicht) jede eine Woche Beschäftigung damit 
erfordern, um sie vernünftig beurteilen zu können.

Ich war vor ca. 10 Jahren in derselben Situation wie Du und brauchte 
eine einfache Lösung für ein GUI-Programm unter Windows. Außer den 
großen Frameworks für Programmierer, die den ganzen Tag nichts Anderes 
als GUI-Programmierung machen, gibts eben auch noch die "kleinen" 
Lösungen für den Gelegenheitsprogrammierer. Ich baue Sondermaschinen und 
habe nicht die Zeit, ein "großes" Framework zu handhaben. Es kostet mich 
vermutlich mehr Zeit, als es mir einspart.

Ich hab mich damals für den Tcl-Coach entschieden (ca. 1MByte Größe!). 
Könnte aber sein, daß er unter Win10 teilweise nicht mehr richtig 
funktioniert. Die Nachfolgelösung, die ich im Moment benutze, ist 
12MByte groß.
Das Pendant dazu in Python wäre wohl Thonny, aber damit habe ich nur 
eine Stunde herumgespielt und kann es nicht kompetent beurteilen.

Zur Kommunikation mit Mikrocontrollern kenne ich jedenfalls nichts 
Einfacheres als Tcl, mit 2 Zeilen Code ist die Verbindung aufgebaut und 
parametriert. Ich habe im Moment 5 Frontend-Controller über USB an einer 
Maschine und das läuft inclusive Eventsteuerung perfekt. Python soll 
ähnlich gut sein. Ich bin nur etwas voreingenommen, da mein 
Lieblingseditor fleißig Spaces und Tabs mixt, was Python angeblich mit 
schwer zu finden Fehlern quittiert (Hörensagen), weshalb ich bisher um 
Python einen Bogen mache.

Nachteile von Tcl sind aus meiner Sicht die umständliche Anbindung von 
UDP (TCP ist m.E. perfekt) und von externen DLLs. Auch mathematische 
Berechnungen sind schnarchlangsam, das muß man je nach Anwendungssfall 
im Auge behalten und eventuell auslagern.

Ich bin aber als bekennender Minimalist voreingenommen, ich habe ein 
Faible für schlanke Lösungen.

Just m 2 cents

Gruß Klaus (der soundsovielte)

von Herbert B. (Gast)


Lesenswert?

Harald K. schrieb:
> Es ist aber ein Krampf im Arsch, so ein Skript dann auszuliefern, denn
> auf normalen PCs ist kein Python installiert, und etwaige Zusätze erst
> recht nicht.
Das liefert man alles mit und baut einen Installer dazu.

> Der Vorzug in sich abgeschlossener Binaries, die kein weiteres Geraffel
> benötigen, macht sich in solchen Situationen schon  bemerkbar.
Du bist ein Amateuerstümper wenn dich das oben schon überfordert.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Klaus S. schrieb:
> Zur Kommunikation mit Mikrocontrollern kenne ich jedenfalls nichts
> Einfacheres als Tcl, mit 2 Zeilen Code ist die Verbindung aufgebaut und
> parametriert.

Das halte ich für eine ziemlich dreiste Fehlinformation!

Selbst wenn du nur eine simple Serielle hättest, hast du in 2 Zeilen 
sicher keine funktionsfähige SCPI, Modbus, CAN,... Verbindung!

Damit hast du im besten Fall die Schnittstelle "geöffnet".

Qt bringt dir haufenweise Helferlein für z.B. die Serielle,CAN, 
Modbus,... mit.
Das ist jetzt alles sicher nicht in jeder erdenkbaren Situation perfekt, 
aber gerade für "Rapid Prototyping" bzw. One-Off's ziemlich gut.

Ja, das Lizenz-Zeug ist ein "Problem". Das hast du aber mit so ziemlich 
jedem Open-Source Tool.
Schonmal die Lizenzbedingungen vom GCC/LVMM/Python/... gelesen?

Übrigens gäbe es noch die Möglichkeit, das ältere Qt4 als Fork zu 
nutzen(Trinity Deskop Environment).
Und dann wäre da natürlich noch die GTK bzw GTK+ und wxWidgets.

Die Lernkuve ist aber in allen mir bekannten Umgebungen ziemlich steil.

TCL/TK ist einfach - schaut aber aus wie aus den 80ern.
TKinter kann die styles aus dem System übernehmen. Das sieht dann besser 
aus - bleibt aber nur für sehr einfache GUIs brauchbar. Sobald du z.B. 
MDI brauchst, würde ich davon Abstand halten!

73

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Da er ja bei Null anfängt, sagte ich ja schon bereits, daß er mit
einer Basic - ähnlichen Sprache anfangen soll. Und am besten eine,
die die ganze Funktionalität schon mit drin hat. Ich selber kenne
das, wenn man in Includedateien, Importlibraries, bzw. Internet u. ä.
nach Funktionalitäten suchen muß, um z.B. nur eine GUI zustande zu
bringen. Bestes Beispiel ist ja schon Python und z.B. TKinter. Da muß
man sich schon schlau machen, was TKinter eigentlich alles kann.

Deshalb mag ich für so kleine Sachen immer noch gerne mein (X)Profan.
(Gibt es auch als Feeware Version 11.2).
Das ist zwar mehr Interpretersprache (Compiler kopiert die Runtime
zur .exe dazu), aber da ist die ganze Funktionalität drin und eine
deutsche Hilfe gibt es auch. Da brauche ich keine Ausschau zu halten,
welche Funktionen ich für welche Funktionalitäten importieren muß.
Klar, kann ich mir auch Includedateien und vorcompilierte Units
erstellen oder Dlls importieren, wenn ich die Funktionaltäten
erweitern möchte.
Schneller und einfacher geht wohl kaum :
1
Declare btn1&, btn2&, ende&
2
WindowTitle "Mein Programm"
3
Window 600, 400
4
btn1& = Create("Button", %HWnd, "Ende", 10, 10, 60, 25)
5
btn2& = Create("Button", %HWnd, "Click mich", 100, 10, 80, 25)
6
7
ende& = 0
8
' jetzt kommt die Ereignis-Schleife
9
WhileNot ende&
10
  WaitInput
11
  If Clicked(btn1&)
12
     ende& = 1
13
  ElseIf Clicked(btn2&)
14
    MessageBox("Du hast mich geklickt !", "Info", 0)
15
  EndIf   
16
EndWhile
17
End

Und wenn er später mal mehr Zeit hat, kann er immer noch auf eine
andere Sprache umswitchen.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Dann muss man Qt wahrscheinlich als eigene Programmiersprache verstehen. 
Schade, ich dachte man könnte da evtl. etwas für µC-C brauchbares bei 
lernen.

> Und wenn er später mal mehr Zeit hat, kann er immer noch auf
> eine andere Sprache umswitchen.
Genau das wollte ich gerne vermeiden. Dann steh ich ja später nochmal 
genau so doof da wie jetzt. Nee sorry, das macht keinen Spaß, zumal 
absehbar ist, daß ich irgendwann C lernen muss wenn es an ARM Cortex 
Controller oder sowas geht, die man nicht mehr in Assembler 
programmieren möchte. Ich bin zu jung dafür, um das zu vermeiden.

> Ich halte es nicht für sinnvoll, als Anfänger nach der optimalen
> Lösung zu suchen, vor allem nicht ohne konkrete harte Anforderungen.
Ich wollte mir halt nicht das ganze Programm schreiben lassen, weil sich 
da noch Dinge ändern könnten (weniger in der Grundfunktion, aber im 
Ausmaß) und weil ich dann wirklich jemanden sehr teuer dafür bezahlen 
müsste. Ich kann ein bißchen Geld investieren, aber ich kann keine 
komplette Auftragsarbeit des gesamten Programms bezahlen.

> Als Anfänger neigt man dazu, die selbst gesetzten
> Entscheidungskriterien sinnlos zu gewichten und andere
> wichtige Aspekte weg zu lassen (weil man sie nicht kennt).
Hmm... das ist eine der Fragen, die die Suche nach einem Programmgerüst 
bereits beinhaltet... oder was genau meinst Du damit?

> Mit der Zeit wirst du mehr Erfahrung sammeln und besser
> entscheiden. Deswegen reicht es für den Anfang, irgend
> etwas halbwegs funktionierendes zu haben.
Das ist eigentlich nicht mein Anspruch. Also halbwegs funktionierendes. 
Ich möchte definitiv auf einem Niveau ankommen, wo das Projekt als 
"vorzeigbar" beschrieben werden kann. Es muss nicht das beste sein, aber 
es muss gut und zuverlässig funktionieren, ohne viele Fehler und ohne 
großes Herumwürgen. Alles was nur halbwegs funktioniert empfinde ich 
irgendwie nur als Test oder Proof-of-Concept.

> Verbessern kann man dann immer noch,
Kann man immer, gibt wenige Programme wo das nicht geht.

> auch Neu-Schreiben ist kein Weltuntergang.
Aber doppelte Arbeit. Besser ist,
es gleich beim ersten Mal richtig zu machen.

von Steve van de Grens (roehrmond)


Lesenswert?

Ben B. schrieb:
> Dann muss man Qt wahrscheinlich als eigene Programmiersprache verstehen.

Nein, Qt ist immer noch eine C++ Bibliothek. Versuche besser nicht, Qt 
mit eigenen Begriffen zu beschrieben. Mangels Ahnung verwirrst du dich 
damit nur selbst unnötig.

> Schade, ich dachte man könnte da evtl. etwas für µC-C brauchbares
> bei lernen.

Eher nicht. Qt ist für Desktop Betriebssysteme gedacht. Auf einem 
Mikrocontroller mit Schaltern und LED's macht es kaum Sinn.

Ben B. schrieb:
> ... oder was genau meinst Du damit?

Dass du noch nicht entscheiden kannst, welche Gerüst oder Framework für 
deine Zwecke optimal ist. Deswegen: Fang einfach mit irgendeinem an, was 
dir zumindest teilweise vertraut vorkommt oder eine verständliche Doku 
hat. Auf etwas andere wechseln kannst du dann immer noch. Mit mehr 
Erfahrung weißt du dann auch, worauf du beim nächsten Anlauf achten 
wirst (falls es überhaupt dazu kommt).

Qt ist jedenfalls kein schlechter Ansatz, schließlich ist es weit 
verbreitet. In Linux gibt es einen Desktop (grafische Oberfläche mit 
Startmenü, Dateimanager, und zahlreichen Apps, sogar einem kleinen 
Office-Paket), der komplett mit Qt gemacht wurde. Es gibt Autos von 
deutschen Markenherstellern, deren Bedienfeld damit gemacht wurde. Das 
ehemalige Handy-Betriebssystem Symbian nutzt Qt viele Jahre lang, bis es 
vom markt verschwand.

Wenn dich nur Windows interessiert, ist C# mit .Net sicher auch kein 
schlechter Ansatz. Microsoft dokumentiert ja für gewöhnlich auch sehr 
gut.

: Bearbeitet durch User
von J. S. (jojos)


Lesenswert?

Steve van de Grens schrieb:
> Qt ist für Desktop Betriebssysteme gedacht. Auf einem
> Mikrocontroller mit Schaltern und LED's macht es kaum Sinn.

geht schon:
Beitrag "Qt for MCUs: Grafiktoolkit für Mikrocontroller"

Aber nicht auf 8 Bit AVR.
Allerdings sollte die Grafik ja auf einem Desktop/Laptop laufen? Dann 
braucht man die µC Version nicht.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Dass du noch nicht entscheiden kannst, welche Gerüst oder Framework
> für deine Zwecke optimal ist.
Stimmt, daher dieser Thread. Ich würde es nicht mal als zwingend
optimal fordern, aber brauchbar sollte es halt sein.

> Deswegen: Fang einfach mit irgendeinem an, was dir zumindest
> teilweise vertraut vorkommt oder eine verständliche Doku hat.
Genau da ist das Problem, warum ich am Anfang so viel offen gelassen 
habe bzw. nur C-ähnliches als wünschenswert beschrieben habe. x86 
Assembler ist wegen Windows-GUI raus, PHP ist als Webserver-basierte 
Interpretersprache raus (ich hätte noch nicht mal die Chance, 
PHP-Quellcode auf irgend einem beliebigen Desktop auszuführen, bzw. mit 
biegen und brechen ja, aber nur als Konsolenfenster) und C64-Basic ist 
"etwas oldschool" wenn man es denn so nennen möchte. Pascal aus der 
Schule - wo ich lieber C/C++ Grundlagen gelernt hätte als diese 
Pascal-Scheiße aufgezwungen zu bekommen - ist auch raus. Ich muss 
zugeben, ich kenne nichts, was sich für Windows-GUI eignet und an dem 
Punkt ist alles mehr oder weniger gleich schwer zu lernen. Da ich aber 
wie gesagt C irgendwann für größere µCs als die AVRs sowieso brauche, 
wäre C eine gute Wahl. Daß ich davon keine Ahnung habe, ist im Moment 
kein Nachteil, es wäre in der Zukunft einer wenn ich jetzt weiß nicht Qt 
oder VB nehmen würde, was in keinster Weise zu µCs passt, nicht mal in 
der Syntax oder in der Toolchain/Handhabung.

Klar, ein betriebssystemübergreifendes Framework hat seine Vorteile, 
aber in absehbarer Zukunft kann ich von jedem, der das Programm zur 
Konfiguration einer µC-Schaltung und Ausgabe ihrer Messwerte nutzen 
möchte, noch einen Windows-PC erwarten. Irgend jemand wird immer ein 
Windows-Laptop haben.

> Auf etwas andere wechseln kannst du dann immer noch. Mit mehr
> Erfahrung weißt du dann auch, worauf du beim nächsten Anlauf
> achten wirst (falls es überhaupt dazu kommt).
Ich denke ich weiß was Du meinst, aber versuch mal, mich zu verstehen, 
daß ich nicht ständig irgendwas komplett neues lernen möchte... Ich 
suche jetzt einmal eine "Sache", mit der ich solche Probleme in 
absehbarer Zukunft lösen kann und keine Sackgasse, aus der ich in 
absehbarer Zukunft 'ne Rolle rückwärts machen muss und wieder vor dem 
gleichen Problem stehe wie jetzt. Das würde mich ehrlich ärgern.

Angenommen ich setze mir jetzt in den Kopf ich will das gerne mit C++ 
machen. Wenn ich mich dann hinsetze und ein Windows-Fenster haben will, 
Text dort hineinschreiben will, evtl. minimale Grafik (Punkte zeichnen 
würde völlig ausreichen, die Linien für Graphen berechne ich zur Not 
noch selbst), will das USB-Device als virtuellen COM-Port haben... Kann 
mir dann irgendjemand hier helfen, wenn ich dabei auf Probleme stoße? 
Ohne, daß ich immer wieder neu geschlachtet werde weil ich mich im 
Vergleich zu einem C++ Profi vielleicht dumm angestellt habe?

von Maik .. (basteling)


Lesenswert?

So zur zeitabschätzung und Entangstung:

Ich hatte mal vor ca. 10 Jahren ein ähnliches Problem. Als HF-Onkel und 
Hardwerker hab ich mit Software nur wenig zu tun - aber es waren in der 
Firma alle Softwareleute durch eine kurz bevorstehende Messe in einem 
ganz fürchterlichen Zeitproblem und unabkömmlich. Ich benötigte aber ein 
kleines Progrämmchen mit einigen Eingabefeldern, Buttons, 
Graphikfenster, ein bisschen Vektoren berechnen und Daten in eine Datei 
wegschreiben.
So musste ich, da die Zeit bei mir nur mäßig drängte, mir innerhalb 
einer Woche rudimentär das C# Programmieren beibringen und konnte aber 
zur Vereinfachung mit in Summe 1..2 Stunden Softwerker-Verhören meine 
offene Fragen klären. Ich war da gar nicht böse drum. Eine Woche 
Fortbildung - zeitlich entspannt ;)
Ging ganz gut. Hatte mir da einfach ein Lehrbuch mit ein paar Beispielen 
für komplett reingezogen und das .net Framework installiert. War glaube 
ich irgendetwas deutschsprachiges von Franzis o.ä. . Vorerfahrung aus 
gelegentlicher C Programmierung für uCs, Studienerinnenrungen und 
vergangenen Visualbasictools schreiben aus ganz grauer Vorzeit waren da.

Den Diskussionsstrang hier finde ich aber sehr interessant, da ich 
demnächst ähnliches wie der TO brauchen könnte und auch das Rad nicht 
neu erfinden möchte..

von Oliver S. (oliverso)


Lesenswert?

J. S. schrieb:
> geht schon:
> Beitrag "Qt for MCUs: Grafiktoolkit für Mikrocontroller"
>
> Aber nicht auf 8 Bit AVR.

Und vor allem nicht Open Source bzw. kostenlos.

Oliver

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Allerdings sollte die Grafik ja auf einem Desktop/Laptop laufen?
Korrekt. Der µC hat mit Grafik gar nichts zu tun, der soll nur einen 
Stapel Messwerte liefern, die er über die Zeit ansammelt. Um das besser 
auswerten zu können wäre eine grafische Darstellung nützlich, weil man 
Veränderungen/Abweichungen dann sofort sehen würde ohne sich durch lange 
Zahlenkolonnen wühlen zu müssen.

von Steve van de Grens (roehrmond)


Lesenswert?

C und Windows ist halt eine Welt, in der sich fast nichts mehr tut. 
Selbst die Doku der uralten Win32 API, welche aus Windows 3.1 Zeiten 
stammt, geht davon aus, dass du in mindestens C++ programmierst.
https://learn.microsoft.com/de-de/windows/win32/apiindex/windows-api-list

Auch die Doku von wxWidgets (anno 1992) geht von C++ aus:
https://docs.wxwidgets.org/3.2/

GTK ist in C verfügbar, aber ob das für Windows eine gute Wahl ist, weiß 
ich nicht.

Ich weis auch nicht, ob man in C überhaupt die angeschlossenen seriellen 
Geräte auflisten kann. Das war dir ja wichtig. Die aktuellen Doku 
beziehen sich alle auf C++ oder modernere Programmiersprachen.

Von C (auf dem Windows PC) rate ich daher ab.

> Ben B. schrieb:
> Kann mir dann irgendjemand hier helfen, wenn ich dabei auf Probleme stoße?

Vermutlich ja, allerdings stellst du solche Fragen besser im Support 
Forum von Microsoft.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Daß C (ohne ++) für Windows keine so gute Idee ist, habe ich schon 
"herausgefunden" bzw. man findet überall hinweise darauf, schon seit 
vielen Jahren verweisen alle auf C++ und/oder eines der Frameworks.

Ist C++ (oder evtl. das .NET Framework mit C#) da so viel besser? Ich 
habe mir das jetzt mal kurz angeschaut, C++ scheint von Hause aus auch 
keine Fenster usw. zu können und nutzt dafür die Win32 API. Da stellt 
sich mir die Frage, ob .NET mit C# nicht vielleicht doch die beste Wahl 
wäre anstatt eine Stufe tiefer anzusetzen und es möglichweise unnötig 
kompliziert zu machen - wie oben schon gesagt wurde, so ganz ohne Ahnung 
vielleicht nicht die beste Idee.

von Oliver S. (oliverso)


Lesenswert?

Ben B. schrieb:
> Da stellt
> sich mir die Frage, ob .NET mit C# nicht vielleicht doch die beste Wahl
> wäre anstatt eine Stufe tiefer anzusetzen und es möglichweise unnötig
> kompliziert zu machen - wie oben schon gesagt wurde, so ganz ohne Ahnung
> vielleicht nicht die beste Idee.

Die Frage stellt sich für jemanden, der beides nicht kennt, und sowieso 
erst lernen müsste, nicht. Da ist C# für ein auf die schnelle 
zusammengeklöppeltes Klicki-Bunti klar die ersten Wahl.

Oliver

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Lasst mich bitte einmal anders fragen: Wenn man C++ und C# in die engere 
Wahl nimmt, womit kann man später mehr anfangen, was ist vielseitiger 
verwendbar? Kann man von C++ etwas für die µC-Programmierung gebrauchen 
oder klebt man dann wieder beim "nackten C"?

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Ich programmiere zu 99% c++ auch am uC.
Wenn man das "richtig" macht, dann hast du eigentlich 0 Overhead. Das 
lernt sich aber nicht von heute auf morgen.

Qt ist übrigens tatsächlich ziemlich speziell. Das nützt einen eigenen 
Präprozessor der die moc-files generiert.

C++ erlaubt dir moderne Programme zu schreiben... im Sinne von 
Paradigmen und konstrukten.

Wenn du mal mehr mit USB zu tun hast, dann wirst du wohl aber übel auch 
z.B. mit libUSB zu tun bekommen.

Ich würde daher auch Mal schauen welche bindings solche libs haben.

73

von Stefan F. (Gast)


Lesenswert?

Ben B. schrieb:
> Ist C++ (oder evtl. das .NET Framework mit C#) da so viel besser?

Da sind die Leute unterschiedlicher Meinung. Diese spielt aber keine 
Rolle, weil man nehmen muss, was da ist.

> Ich habe mir das jetzt mal kurz angeschaut, C++ scheint von Hause
> aus auch keine Fenster usw. zu können und nutzt dafür die Win32 API.

Korrekt. Alle Programmiersprachen müssen unter Windows diesen Weg gehen, 
auch C#.

> Da stellt sich mir die Frage, ob .NET mit C# nicht vielleicht
> doch die beste Wahl wäre anstatt eine Stufe tiefer anzusetzen

C# ist wie C und C++ nur eine Programmiersprache unter vielen. .NET ist 
ebenso wie Qt ein Framework, dass über die Windows API gestülpt wurde.

Wenn du den direkten Weg mit minimaler Verschachtelungstiefe gehen, dann 
benutze die Windows API. Das ist der kleinste gemeinsame Nenner. Die 
Windows API besteht aus Header- und DLL-Dateilen für C++. Alle anderen 
Programmiersprachen greifen darauf mehr oder weniger indirekt zu.

Aber: Sie ist keineswegs einfacher zu benutzen, als Qt oder .NET.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Das lernt sich aber nicht von heute auf morgen.
Nichts davon lernt sich von heute auf morgen.

> Wenn du mal mehr mit USB zu tun hast, dann wirst du wohl
> aber übel auch z.B. mit libUSB zu tun bekommen.
So schlimm?

> Ich würde daher auch Mal schauen welche bindings solche libs haben.
Darauf kann ich im Moment nur wenig Rücksicht nehmen, ich bekomme auf 
die Schnelle sowieso keinen Überblick darüber. Wenn dann kann ich nur 
der Reihe nach vorgehen. Erstml Fenster, dann USB-Kommunikation, dann 
evtl. noch Grafikelemente im Fenster und immer das suchen/nehmen was ich 
eben gerade dafür brauche.

von Stefan F. (Gast)


Lesenswert?

Kennst du mein Qt Tutorial?
http://stefanfrings.de/qt_lernen/index.html

Dort erkläre ich, wie man Grafik ausgibt:
http://stefanfrings.de/qt_lernen/index.html#grafik

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Stefan, danke für die Klarstellung.

> Aber: Sie ist keineswegs einfacher zu benutzen, als Qt oder .NET.
Nichts davon ist einfach zu benutzen wenn man nichts davon kennt. Das 
ist gewissermaßen der einzige große Luxus, den ich mir gönnen kann - ich 
habe die freie Auswahl womit ich mir letztendlich ein paar Mal ins 
eigene Knie schießen werde.

Dein Tutorial schaue ich mir an.

Ich glaube ich werde mal ein paar Tests mit C++ machen. Wenn ich da 
nichts erreiche, überlege ich weiter wegen Qt oder .NET/C#.

von Stefan F. (Gast)


Lesenswert?

Wenn dir Qt nicht zusagt, schaue dir .Net an welches primär zusammen mit 
C# auftritt. C++ geht aber auch, was ich an deiner Stelle C++ bevorzugen 
würde, wegen der Synergie zur C/C++ Programmierung von Mikrocontrollern. 
Mehrmals pro Woche zischen unterschiedlichen Programmiersprachen zu 
wechseln wird nämlich schnell anstrengend.

C# ist übrigens ähnlich wie Java. Es hat eine automatische 
Speicherverwaltung (Garbage Colloctor) und viele andere Sachen, die das 
Programmieren vereinfachen. Man kann sich nicht ganz so leicht in eigene 
Knie schießen, wie in C/C++. Dafür laufen die Programme allerdings 
merklich langsamer. Für eine normale Desktop Anwendung finde ich das 
aber nicht schlimm, denn selbst 10 Jahre alte Desktop PC sind dafür 
schnell genug.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Hm, wenn ich sage, der Geschwindigkeitsaspekt wäre mir egal, dann wäre 
das gelogen. Es gab für mich zwei Gründe, zu Zeiten des 486er noch x86 
Assembler zu lernen. Virenprogrammierung (wenn man wissen will, wie die 
Dinger funktionieren geht das am besten, indem man selbst welche 
schreibt) und die Geschwindigkeit/Kompaktheit der Programme, die sich 
mit Basic (Überbleibsel vom C64, es gab mit PowerBasic einen sehr 
schönen Interpreter/Compiler für den PC) bei weitem nicht erreichen 
ließ. Für 6502 Assembler auf dem C64 war ich zu jung und hatte auch 
niemanden, von dem ich es hätte lernen können, Basic musste ich mir auch 
komplett selbst beibringen, für x86 Assembler gab's dann immerhin schon 
sehr gute Bücher und die Hardware zu verstehen war einfach. Aber das ist 
alles mit DOS gestorben. Ich habe später noch einmal eine 
Konsolenanwendung in x86 Assembler geschrieben weil ich pure 
Integer-Rechenleistung gebraucht habe, aber das war's dann.

Dann kam das Internet, alles nur HTML mit paar GIFs? Langweilig. PHP war 
cool, dynamische Webseiten... das isses. Textbasierte Spiele damit 
geschrieben, die plötzlich weltweit funktionierten und später als MMOGs 
bekannt wurden, das hat richtig Spaß gemacht. Etwa zur gleichen Zeit der 
erste Kontakt mit Mikrocontrollern (ominösen PIC16irgendwas in einer 
Notbeleuchtung gefunden, der entschieden zuviel konnte als mit einem 
CMOS oder TTL-Baustein erklärbar gewesen wäre).

Dabei ists bis heute geblieben, zwischen AVR Assembler (die PICs haben 
einen miesen Befehlssatz und sind nach meiner Einschätzung deutlich 
langsamer als die AVRs, daher der schnelle Wechsel) und PHP kann ich 
problemlos wechseln (PHP Backendprogrammierung und zuhause AVR 
Assembler), dazu noch etwas JavaScript.

Aber ich hatte niemals Kontakt oder die Notwendigkeit für C/C++. In der 
Schule konnte die dumme Kuh, für die ein Herd schon Mikroelektronik 
darstellte, nur TurboPascal - also haben wir das aufgedrückt bekommen, 
ganz toll. Umso mehr hat sie sich darüber gefreut, daß meine Programme 
z.B. via Inline-Assembler BIOS-Funktionen nutzten, um den hässlichen 
Cursor vom Bildschirm zu kicken, den Pascal da immer herumblinken ließ. 
Unterstellung "ich würde den PC kaputtmachen". Und von sowas kriegt man 
dann seine Noten, Glückwunsch.

Das rennt mir jetzt 20 Jahre bis heute hinterher, damals die ersten 
Anfänge in C/C++ und ich glaube ich hätte die Sprache heute ganz gut 
drauf.

von Stefan F. (Gast)


Lesenswert?

Ben B. schrieb:
> dynamische Webseiten... das isses

Dann knüpfe doch daran an, und nutze ein ESP8266 Modul als Web Interface 
zu deinem Mikrocontroller, sowie Javascript zur Visualisierung von 
Daten.

Ben B. schrieb:
> Das rennt mir jetzt 20 Jahre bis heute hinterher, damals die ersten
> Anfänge in C/C++ und ich glaube ich hätte die Sprache heute ganz gut
> drauf.

Naja, ich habe mit Basic angefangen, dann Assembler auf der selben 
Maschine, dann Basic auf Schneider CPC464, dann Pascal auf PC, und erst 
viele Jahre später C/C++ (wegen Windows). So schwer ist das nicht.

von Klaus S. (kseege)


Angehängte Dateien:

Lesenswert?

Habe spaßeshalber mal ein kleines, von mir zum Vorabtest geschriebenes 
Tcl-Programm mit hochgeladen, das 3 Schrittmotoren an einem 
emis-Controller über USB bedient und parametriert.

Jetzt würde ich das gern mit dem Qt-Framework und dem von Stefan 
veröffentlichten Codebeispiel in C++ nachprogrammieren, da ich ein 
ziemlich neugieriges Kerlchen bin. Allerdings bin ich schon beim 
Download gestolpert. Auf heise.de heißt es, der Qt-Creator wäre gar 
nicht dabei, auf qt.io wird von monatlich 300$ für ein Jahresabo 
geschrieben. Kann mich jemand aufklären, wie die Randbedingungen für das 
Qt-Framework sind? Ich arbeite gerade unter Debian11 und habe den gcc 
natürlich parat.

Gruß Klaus (der soundsovielte)

von Klaus S. (kseege)


Angehängte Dateien:

Lesenswert?

Das zugehörige Bild ist leider verlorengegangen, irgendwie bekomme ich 
nur eine einzige Datei an den Text geklebt.

von Stefan F. (Gast)


Lesenswert?

Klaus S. schrieb:
> Das zugehörige Bild ist leider verlorengegangen, irgendwie bekomme ich
> nur eine einzige Datei an den Text geklebt.

Benutze den Button "eine weitere Datei anhängen". Den kannst du beliebig 
oft benutzen. Die Voransicht sammelt alle Dateinamen, zeigt die Anhänge 
jedoch nicht an.

von Stefan F. (Gast)


Lesenswert?

Klaus S. schrieb:
> Allerdings bin ich schon beim
> Download gestolpert. Auf heise.de heißt es, der Qt-Creator wäre gar
> nicht dabei

Man downloaded solche Sachen besser auf der originalen Webseite, dann 
wird einem auch unerwünschtes "Zubehör" mit untergeschoben.

> auf qt.io wird von monatlich 300$ für ein Jahresabo  geschrieben.

Das ist wie mit der Lizenz wieder so ein Fall von "nicht richtig hin 
geschaut". Auf https://www.qt.io/download befindet sich zur Zeit rechts 
oben eine Box mit dem Label "Open source user?". Da musst du hin.

Und dann scrollst du nach unten. Unmittelbar über der FAQ Liste (wo 
übrigens deine Lizenz-Fragen beantwortet sind) ist ein fetter grüner 
Button "Download the Qt Online Installer". Den nimmst du.

Das steht so auch im Anfang meines Tutorials 
(http://stefanfrings.de/qt_lernen/index.html). Arbeite das mal von oben 
nach unten durch.

von Thomas W. (Gast)


Lesenswert?

Klaus S. schrieb:
> Jetzt würde ich das gern mit dem Qt-Framework und dem von Stefan
> veröffentlichten Codebeispiel in C++ nachprogrammieren, da ich ein
> ziemlich neugieriges Kerlchen bin. Allerdings bin ich schon beim
> Download gestolpert.

qt wird mit Dual-Licensing vertrieben: Commercial mit ca. US$300 pro 
Monat (mit support und ohne (L)GPL-Einschraenkungen) oder als 
OpenSource-Version (fuer US$ 0 aber mit Einschraenkungen). Fuer Deine 
Tests wuerde die OpenSource-Version reichen.

Ich weiss nicht, was dieses heise.de ist: Auf der Webseite des 
Herstellers qt kann man den installer runterladen (allerdings muss man 
sich registrieren, ih habe aber noch keine Spam von qt.io bekommen).

Beim Installer kannst Du dann auswaehlen welche Version der Library Du 
installieren moechtest. Bei dem Code-Schnippsel von Stefan ist wohl 5.15 
ganz gut).

Der qt-creator ist dabei (eine IDE mit Debugger und so), der Qt-Creator 
(eine Software um sehr fortgeschrittene Designs zu bauen) ist glaube ich 
nur in der Kauf-Version dabei.

Gruesse

Th.

von Stefan F. (Gast)


Lesenswert?

Thomas W. schrieb:
> Bei dem Code-Schnippsel von Stefan ist wohl 5.15 ganz gut).

Ja, ich habe das Projekt schon lange nicht mehr erneuert. Irgendeine 5.x 
Version der Bibliothek sollte gehen.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> So schwer ist das nicht.
Nichts ist unmöglich, aber die ersten Schritte sind bei sowas irgendwie 
immer die schwersten und man kann sich viel versauen wenn man nicht weiß 
in welche Richtung man sie machen soll.

Javascript zur Visualisierung der Daten könnte man evtl. machen, ESP8266 
verursacht aber höheren Aufwand auf dem steuernden µC, schließlich muss 
man das Ding irgendwie in ein verschlüsseltes WLAN bekommen. Das 
erfordert mindestens eine Kennworteingabe und die wird ohne Tastenfeld 
ätzend.

von Stefan F. (Gast)


Lesenswert?

Fange einfach mal an, anstatt weiter Zeit mit Diskutieren zu vergeuden.

von Stefan F. (Gast)


Lesenswert?

Ben B. schrieb:
> schließlich muss man das Ding irgendwie in ein verschlüsseltes WLAN
> bekommen. Das erfordert mindestens eine Kennworteingabe und die wird
> ohne Tastenfeld ätzend.

Dafür wurde WPS erfunden. Zufällig habe ich eine Alternative dazu parat, 
falls WPS (warum auch immer) nicht geht: 
http://stefanfrings.de/esp8266/index.html#wificonfigservice

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Ben B. schrieb:
> Hm, wenn ich sage, der Geschwindigkeitsaspekt wäre mir egal, dann wäre
> das gelogen. Es gab für mich zwei Gründe, zu Zeiten des 486er noch x86
> Assembler zu lernen.

Das ist doch gut und kann man auch heutzutage noch gut gebrauchen.
Nur die Register heißen etwas anders : statt AX -> EAX  usw.
Gerade da, wo es in selber geschriebenen Funktionen auf Geschwindigkeit 
ankommt, gibt es nichts besseres. Da gibt es auch Sprachen, die 
Inline-Assembler beherrschen. Ich habe mir auch schon von einer 
Funktion, die
ich gefunden hatte, Bytecode generieren lassen, die in einen 
Speicherbereich geschoben und mit CALL aufgerufen. Man muß aber genau 
wissen, was man macht.
Bei falschen Parametern knallt es dann.

Aber das nur so am Rande.

von C-hater (c-hater)


Lesenswert?

Steve van de Grens schrieb:

> Ich weis auch nicht, ob man in C überhaupt die angeschlossenen seriellen
> Geräte auflisten kann.

Natürlich kann man das. Das entsprechende API heißt SetupAPI. Und 
besteht aus unzähligen Datenstrukturen und Funktionen im C-Stil. Alles 
im Detail hervorragend dokumentiert.

Allerdings ist die Logik des Gesamtwerks nicht so ganz einfach zu 
durchschauen. Da fehlt leider eine verständliche übergreifende 
Dokumentation, die den Sinn der einzelnen Teilbereiche und ihr 
Zusammenwirken erklärt. Manches kann man eigentlich leider nur 
verstehen, wenn man auch Windows-Treiber programmiert.

Aber für das konkrete Problem des TO kommt man mit einigen (relativ 
wenigen) Funktionen aus. Hier mal die die entsprechenden 
Import-Deklarationen für VB.net (weil ich die schön passend aufbereitet 
vorliegen habe und nur C&Pen muss ;o). Daraus lassen sich zumindest die 
Namen der zu benutzenden Funktionen und die Namen der DLLs entnehmen, 
aus denen sie stammen (die Original-C-Doku kann man darüber dann ja 
problemlos bei MS finden). Zu diesen Funktionen gehören dann natürlich 
noch Datenstrukturen und Konstanten. Auch alles bei MS über die 
Funktionsdokus zu finden.
1
    <DllImport("SetupAPI.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
2
    Private Shared Function SetupDiBuildClassInfoList(ByVal Flags As UInteger, ByVal ClassGuidList As Byte(), ByVal ClassGuidListSize As UInteger, ByRef RequiredSize As UInteger) As Boolean
3
    End Function
4
    <DllImport("SetupAPI.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
5
    Private Shared Function SetupDiClassNameFromGuid(ByRef Guid As Guid, ByVal ClassName As Byte(), ByVal ClassNameSize As UInteger, ByRef RequiredSize As UInteger) As Boolean
6
    End Function
7
    <DllImport("SetupAPI.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
8
    Private Shared Function SetupDiGetClassDescription(ByRef Guid As Guid, ByVal ClassDescription As Byte(), ByVal ClassDescriptionSize As UInteger, ByRef RequiredSize As UInteger) As Boolean
9
    End Function
10
    <DllImport("SetupAPI.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
11
    Private Shared Function SetupDiGetClassDevs(ByRef ClassGuid As Guid, ByVal Enumerator As String, ByVal hwndParent As IntPtr, ByVal Flags As UInteger) As IntPtr
12
    End Function
13
    <DllImport("SetupAPI.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
14
    Private Shared Function SetupDiDestroyDeviceInfoList(ByVal DeviceInfoSet As IntPtr) As Boolean
15
    End Function
16
    <DllImport("SetupAPI.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
17
    Private Shared Function SetupDiEnumDeviceInfo(ByVal DeviceInfoSet As IntPtr, ByVal MemberIndex As UInteger, ByRef DeviceInfoData As SP_DEVINFO_DATA) As Boolean
18
    End Function
19
    <DllImport("SetupAPI.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
20
    Private Shared Function SetupDiGetDeviceRegistryProperty(ByVal DeviceInfoSet As IntPtr, ByRef DeviceInfoData As SP_DEVINFO_DATA, ByVal [Property] As UInteger, ByRef PropertyRegDataType As UInteger, ByVal PropertyBuffer As Byte(), ByVal PropertyBufferSize As UInteger, ByRef RequiredSize As UInteger) As Boolean
21
    End Function
22
    <DllImport("SetupAPI.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
23
    Private Shared Function SetupDiOpenDevRegKey(ByVal DeviceInfoSet As IntPtr, ByRef DeviceInfoData As SP_DEVINFO_DATA, ByVal Scope As UInteger, ByVal HwProfile As UInteger, ByVal KeyType As UInteger, ByVal samDesired As UInteger) As IntPtr
24
    End Function
25
    <DllImport("SetupAPI.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
26
    Private Shared Function SetupDiEnumDeviceInterfaces(ByVal DeviceInfoSet As IntPtr, ByRef DeviceInfoData As SP_DEVINFO_DATA, ByRef InterfaceClassGuid As Guid, ByVal MemberIndex As UInteger, ByRef DeviceInterfaceData As SP_DEVICE_INTERFACE_DATA) As Boolean
27
    End Function
28
    <DllImport("SetupAPI.dll", EntryPoint:="SetupDiGetDeviceInterfaceDetail", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
29
    Private Shared Function SetupDiGetDeviceInterfaceDetail_x86(ByVal DeviceInfoSet As IntPtr, ByRef DeviceInterfaceData As SP_DEVICE_INTERFACE_DATA, ByRef DeviceInterfaceDetailData As SP_DEVICE_INTERFACE_DETAIL_DATA_x86, ByVal DeviceInterfaceDetailDataSize As UInteger, ByRef RequiredSize As UInteger, ByRef DeviceInfoData As SP_DEVINFO_DATA) As Boolean
30
    End Function
31
    <DllImport("SetupAPI.dll", EntryPoint:="SetupDiGetDeviceInterfaceDetail", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
32
    Private Shared Function SetupDiGetDeviceInterfaceDetail_x64(ByVal DeviceInfoSet As IntPtr, ByRef DeviceInterfaceData As SP_DEVICE_INTERFACE_DATA, ByRef DeviceInterfaceDetailData As SP_DEVICE_INTERFACE_DETAIL_DATA_x64, ByVal DeviceInterfaceDetailDataSize As UInteger, ByRef RequiredSize As UInteger, ByRef DeviceInfoData As SP_DEVINFO_DATA) As Boolean
33
    End Function
34
    <DllImport("SetupAPI.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
35
    Private Shared Function SetupDiGetDeviceInstanceId(ByVal DeviceInfoSet As IntPtr, ByRef DeviceInfoData As SP_DEVINFO_DATA, ByVal DeviceInstanceId As Byte(), ByVal DeviceInstanceIdSize As UInteger, ByRef RequiredSize As UInteger) As Boolean
36
    End Function
37
    <DllImport("AdvApi32.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
38
    Private Shared Function RegQueryValueEx(ByVal hKey As IntPtr, ByVal ValueName As String, ByVal lpReserved As IntPtr, ByRef lpType As UInteger, ByVal lpData As Byte(), ByRef lpcbData As UInteger) As Long
39
    End Function
40
    <DllImport("AdvApi32.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
41
    Private Shared Function RegCloseKey(ByVal hKey As IntPtr) As Long
42
    End Function
43
    <DllImport("Kernel32.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
44
    Private Shared Function GetVolumeNameForVolumeMountPoint(ByVal lpszVolumeMountPoint As String, ByVal lpszVolumeName As Byte(), ByVal cchBufferLength As UInteger) As Boolean
45
    End Function
46
    <DllImport("Kernel32.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
47
    Private Shared Function GetVolumePathNamesForVolumeName(ByVal lpszVolumeName As String, ByVal lpszVolumePathNames As Byte(), ByVal cchBufferLength As UInteger, ByRef lpccReturnLength As UInteger) As Boolean
48
    End Function
49
    <DllImport("User32.dll", EntryPoint:="RegisterDeviceNotification", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
50
    Private Shared Function RegisterDeviceNotification_x86(ByVal Handle As IntPtr, ByRef NotificationFilter As DEV_BROADCAST_DEVICEINTERFACE_x86, ByVal Flags As UInteger) As IntPtr
51
    End Function
52
    <DllImport("User32.dll", EntryPoint:="RegisterDeviceNotification", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
53
    Private Shared Function RegisterDeviceNotification_x64(ByVal Handle As IntPtr, ByRef NotificationFilter As DEV_BROADCAST_DEVICEINTERFACE_x64, ByVal Flags As UInteger) As IntPtr
54
    End Function
55
    <DllImport("User32.dll", CallingConvention:=CallingConvention.Winapi, CharSet:=CharSet.Unicode, SetLastError:=True)> _
56
    Private Shared Function UnregisterDeviceNotification(ByVal Handle As IntPtr) As Boolean
57
    End Function

Darin sind allerdings auch schon Funktionen enthalten, die nur für eine 
sehr luxeriöse Variante so einer Device-Enumaration benötigt werden 
(eine, die auch mit dynamisch wechselnden Geräten klarkommt und eine die 
sowohl aus einer x86-Anwendung als auch aus einer x64-Anwendung heraus 
funktioniert. Für eine einfache Brot-und-Butter-Lösung mit fester 
Zielarchitektur kann man da noch deutlich ausdünnen.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Bei Assembler knallt es immer wenn irgendwas nicht passt und man das 
Programm nicht für den aufgetretenen Fehler vorbereitet hat. Bestes 
Beispiel was Deine Register angeht: MOV EAX,irgendwas auf einem 80286. 
Der weiß noch gar nichts von 32 Bit und reagiert mit einem illegal 
opcode Interrupt. Wenn man den nicht abgefangen hat und sich das 
Betriebssystem auch nicht drum kümmert, schmiert die Kiste ab. Oder 'ne 
Division durch Null, sowas wird immer gerne genommen. Bei 
Compilerprogrammen hat der Compiler einen Programmblock dafür 
integriert, daß man Debug-Informationen bekommt z.B. division by zero at 
CS:IP, alle Registerinhalte und daß das Programm halbwegs korrekt 
beendet wird. Wenn man sich das in Assembler gespart hat, dann schmiert 
die Kiste halt ab.

Edit: 32 Bit Windows interessiert mich nicht mehr, ich setze ein 64 Bit 
Windows voraus. Wir leben nicht mehr im Mittelalter und fast niemand 
unterstützt noch 32 Bit Windows.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Angehängte Dateien:

Lesenswert?

So, reicht für "heute". Ich wusste wie das endet.

Immerhin weiß ich jetzt wie diese hässlichen Installer und einfache 
Windows-Spielchen geschrieben wurden, die nach nichts aussehen. Ich 
hoffe ich krieg's irgendwann besser hin.

Gute Nacht!

: Bearbeitet durch User
von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Ben B. schrieb:

> Edit: 32 Bit Windows interessiert mich nicht mehr, ich setze ein 64 Bit
> Windows voraus. Wir leben nicht mehr im Mittelalter und fast niemand
> unterstützt noch 32 Bit Windows.

Ich denke, das wird schon noch einige Jahre überleben. Ich hatte auch
mal einen Arbeitskollegen, der partout eine 64-Bit Version meines
Programmes haben wollte. War dann mit FreeProfan64 kein Problem
und brauchte auch keine Umstellungen zu machen. Einfach neu
compilieren.

Aber für die längere Zukunft hast du wohl recht. Weiß ja auch keiner,
wann MS alles auf 64Bit umstellt. Bis dahin ist aber auch dein Projekt
mit AVR schon tiefstes Mittelalter. Ist eigentlich jetzt schon Mittel-
alter. Wer weiß schon, was es dann alles gibt.

von Steve van de Grens (roehrmond)


Angehängte Dateien:

Lesenswert?

Ben B. schrieb:
> 32 Bit Windows interessiert mich nicht mehr

Ja, aber viele Libraries und Verzeichnisse von Windows heißen immer noch 
so, obwohl der Code darin 64 Bit ist. Als beispiel habe einen Screenshot 
von der user32.dll von Windows angehängt.

: Bearbeitet durch User
von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Kommt ja auch drauf an, in welchem Ordner du schaust.
Die 3 Dateien, auf die man am häufigsten als Programmierer zugreift,
sind Kernel32.dll, user32.dll und gdi32.dll
Und die gibt es ja doppelt, Einmal als 32Bit im Ordner SYSWOW64
und einmal im Ordner SYSTEM32 als 64Bit. Klingt zwar kurios, ist
aber so.

Und die werden beim Systemstart von Windows automatisch geladen.

Oder was meinst du, warum die doppelt vorhanden sind ?

Und schau mal nach, da gibt es auch noch mehrere.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Ich meinte damit einfach nur, daß ich "mein" Programm nur auf 64 Bit 
ausrichte. Damit hat alles Pech, was kein 64 Bit Windows-Programm 
ausführen kann. Linux und Mac sind raus solange Windows brauchbar und so 
weit verbreitet ist. Der Anteil an 32 Bit only Windows-Versionen sollte 
inzwischen so gering sein, daß sich der Aufwand der Kompatibilität dazu 
einfach nicht mehr lohnt. Darum kümmere ich mich also nicht mehr.

Sollte das Projekt irgendwann mal interessant genug werden, daß sich 
eine Linux- oder Mac-Version "lohnt", dann kann man die immer noch 
nachschieben. Aber daran glaube ich erst wenn ich es sehe.

Edit:
Mittelalter bei µCs spielt ja keine Rolle. Solange die Controller 
verfügbar sind und klaglos ihren Dienst verrichten, ist der Einsatz 
alter Controller völlig valide. Deswegen hält sich der MCS-51/52 Kram ja 
so lange. Das Programm ist fertig, die Controller sind verfügbar und das 
Ganze macht das was es soll, nicht mehr und nicht weniger. Also wieso 
sollte ich jetzt einen neueren/besseren Controller einsetzen? Das wird 
erst bei Erweiterungen nötig, die mit dem alten Controller nicht mehr 
realisierbar sind bzw. man könnte die Hardware bei so einer Gelegenheit 
auf einen aktuelleren Prozessor migrieren.

: Bearbeitet durch User
von C-hater (c-hater)


Lesenswert?

Ben B. schrieb:

> Linux und Mac sind raus solange Windows brauchbar und so
> weit verbreitet ist.

Nunja, MS tut derzeit alles dafür, Windows weniger attraktiv zu machen. 
Die wollen mit der Zwangs-Cloudisierung Geld scheffeln. Das kann nur 
in's Aus führen. Wennschon Cloud, dann konsequent, also 
Web-Technologien. Da braucht man dann auf dem Client nur noch einen 
Browser. Und der braucht sicher nicht zwingend Windows, um laufen zu 
können.

Die Blinden Wichser in der MS-Führungsetage haben diese Endkonsequenz 
wohl nicht so richtig verstanden. Die begreifen einfach nicht, dass sie 
an den Beinen des Stuhls sägen, auf dem sie selber sitzen...

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Damit könntest Du Recht haben, die testen wohl gerade wie weit sie gehen 
können bis keiner mehr Lust auf die Scheiße hat und sich nach 
Alternativen umschaut. An dem Punkt könnten sie dann massiv Marktanteile 
verlieren und dann gibt's zwei Möglichkeiten - ab in die Versenkung oder 
zurückrudern. Die dritte Möglichkeit wäre, daß die Volksverdummung schon 
so weit fortgeschritten ist, daß dieser Punkt nie erreicht wird und sie 
mit der Masche durchkommen - und dann wäre die Überlegung wie weit man 
sich dann noch dagegen wehren kann wenn man auch weiterhin gerne Spiele 
auf dem PC hätte und keine Konsole dafür anschaffen möchte.

Egal, das ist vorerst OT und solange wie Windows eigene Programme 
zulässt und noch nicht zum Nischenprodukt verfallen ist, mache ich mal 
damit weiter. Schlimmstenfalls muss man es irgendwann nochmal für Linux 
neu schreiben falls man es nicht "einfach" dafür neu compilieren kann. 
Wäre ja auch möglich, Linux stellt ein Äquivalent zur Win32-API zur 
Verfügung, dann müsste das Programm bis auf das .EXE-Format eigentlich 
lauffähig sein. Vielleich gibt's auch irgendwelche Emulatoren dafür, 
wundern würde mich das nicht.

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Ben B. schrieb:
> Mittelalter bei µCs spielt ja keine Rolle. Solange die Controller
> verfügbar sind und klaglos ihren Dienst verrichten, ist der Einsatz
> alter Controller völlig valide.

Du wirst lachen, aber das spielt sogar bei Betriebssystemen keine
Rolle. Kleine und mittlere Firmen setzen da immer noch gerne
auf 'alt Eingefahrenes'. Bei der Firma, wo ich bis vor 2 Jahren
(bin jetzt Rentner) 20 Jahre arbeitete, hatte man immer noch als 
Betriebssystem das Window NT und ein altbackenes Warenwirtschaftssystem,
das es auch schon über 20 Jahre gibt. Die arbeiten heute noch damit.

Auf meine Anfrage hin, hatte mir damals der Systemadministrator
gesagt : Wozu solle man auf ein neues System wechseln, wenn das
alte bestens läuft ?

von Stefan F. (Gast)


Lesenswert?

Ben B. schrieb:
> Schlimmstenfalls muss man es irgendwann nochmal für Linux
> neu schreiben falls man es nicht "einfach" dafür neu compilieren kann.

Qt unterstützt Linux, Windows. Mac OS und einige andere. Normalerweise 
brauchst du an deinem Quelltext nicht zu ändern, einfach nur neu 
compilieren.

Mit .Net geht das ebenfalls, allerdings enthält die freie Version 
(Namens Mono) nicht alle Features, die unter Windows zur Verfügung 
stehen.

> Wäre ja auch möglich, Linux stellt ein Äquivalent zur Win32-API zur
> Verfügung, dann müsste das Programm bis auf das .EXE-Format eigentlich
> lauffähig sein. Vielleich gibt's auch irgendwelche Emulatoren dafür,
> wundern würde mich das nicht.

Gibt es, der mir bekannteste Emulator heißt Wine. Damit laufen manche 
Windows Programme sogar deutlich schneller, als unter Windows.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Gleich mal die nächste schnelle Frage:

Ich hab den Test ja jetzt so weit, daß er Text und Grafik an bestimmte 
Stellen im Fenster ausgeben kann. Wenn ich jetzt sagen wir 100 Zeilen 
Text haben will und nur 30 passen ins Fenster, gibt es dann eine 
intelligente Möglichkeit zum Hochscrollen oder muss ich mich darum 
selbst kümmern (z.B. Fenster leeren, Zeilen in einem Puffer kopieren und 
Fenster neu zeichnen)?

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Nimm bitte irgend ein Widget Set...

Selbst TK oder TKinter ist besser als direktes zeichnen!

An leichtgewichtigen GUI libraries gäbe es noch imGUI und FLTK.

73

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Nimm bitte irgend ein Widget Set...
Zu spät, dafür wäre vorher Zeit gewesen als ihr mich nur runtergeputzt 
habt. Jetzt habe ich mich für C++ entschieden, mir die Anfänge selbst 
gebastelt und nun ist's auch nicht in Ordnung, oder was?!

von Thomas W. (Gast)


Lesenswert?

Ben B. schrieb:
>> Nimm bitte irgend ein Widget Set...
> Zu spät, dafür wäre vorher Zeit gewesen als ihr mich nur runtergeputzt
> habt. Jetzt habe ich mich für C++ entschieden, mir die Anfänge selbst
> gebastelt und nun ist's auch nicht in Ordnung, oder was?!

Aber ich sehe sehr wenig (genauer gesagt: gar kein) Quellcode. Wie soll 
man dann etwas kommentieren wenn da nix da ist?

Th.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Der Quellcode ist unspektakulär, ein minimal erweitertes Beispiel zum 
Erzeugen einer Deskop-App mit Fenster, was mehr kann als ich erwartet 
hätte bzw. einfacher zu erweitern war als ich erwartet hätte.

Ich muss ein wenig damit herumspielen und schauen wie diese Message-Loop 
funktioniert bzw. wann und wie oft man so eine Message bekommt und ob 
man den Inhalt des Fensters immer selbst neu zeichnen muss, etwa wenn 
das Fenster verschoben wird oder so.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Ben B. schrieb:
>> Nimm bitte irgend ein Widget Set...
> Zu spät, dafür wäre vorher Zeit gewesen als ihr mich nur runtergeputzt
> habt. Jetzt habe ich mich für C++ entschieden, mir die Anfänge selbst
> gebastelt und nun ist's auch nicht in Ordnung, oder was?!

kA was du meinst.

C++ an sich "kann" kein GUI von sich aus.
Du nutzt irgendeine low-level API...

Oben kamen Vorschläge zu Qt, Gtk, Mono, TK, wxWidgets, FLTK, imGUI, ...

Wenn du unbedingt alles per Hand machen willst... BTDT... ultra steile 
Lernkurve!

Alleine ein funktionierendes clipping beim scrolling, Font- und 
Auflösungsmanagement. Ui,ui,ui...

Angegriffen habe ich dich oben jedenfalls nicht... aber nachdem eh alles 
gelaufen ist, bin ich Mal raus.

73

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Ja gut, dann ist das so.

Ich habe etliche Male nach einem Programmgerüst gefragt, von dem ich den 
Quellcode haben kann, ich hatte die Sprache oder welches Framework 
komplett offen gelassen. Dann kamen viele Wege, womit es denn gehen 
würde, aber außer von Stefan nichts Greifbares, bei dem man Quellcode 
und Ergebnis sehen konnte.

Ach vergessen, viele Hinweise kamen auch noch, daß es überall 'ne 
relativ steile Lernkurve wird, egal was ich letzlich nehme und noch von 
nichts 'ne Ahnung habe.

Ich habe Dich auch nicht direkt angesprochen, aber es hat auch niemand 
außer Stefan und Udo konkrete Lösungen angeboten. Also wenn sich Stefan 
aufregt weil ich sein Qt nicht so sehr mag und mit seinen vielen 
Beispielen deswegen jetzt nicht sonderlich viel anfangen kann, dann 
könnte ich das verstehen. Und der Quellcode-Schnipsel von Udo sieht sehr 
nach C++ aus.

Wo ist Dein Codeschnipsel, habe ich irgendwas übersehen oder vergessen 
zu berücksichtigen? Du hast doch nur darauf hingewiesen, was Du selbst 
mit C++ machst, aber nie was gezeigt.

> Du nutzt irgendeine low-level API...
Wissentlich Win32.

: Bearbeitet durch User
von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Wenn es übersichtlich sein soll, wirst du um die Erstellung von
Fensterelementen (Buttons, Listboxen, etc.) nicht herumkommen.
Alles andere sieht nicht schön aus und macht evtl. auch mehr
Arbeit.

Also, platziere doch eine Listbox oder wenn du editierbar haben
willst, ein MultiEdit in dein Fenster und schreibe dort deine
Zeilen rein. Sowohl Listbox als auch MultiEdit scrollen normalerweise
automatisch.

von Steve van de Grens (roehrmond)


Lesenswert?

Heinz B. schrieb:
> Auf meine Anfrage hin, hatte mir damals der Systemadministrator
> gesagt : Wozu solle man auf ein neues System wechseln, wenn das
> alte bestens läuft ?

Ich bin auch ein Freund von "Don't change a running system".

Wir IT Fachleute gehen immer davon aus, dass Software ständig auf und 
umgebaut werden muss

a) zur Sicherheit
b) um neue Anforderungen zu erfüllen

Punkt a wird bei Software ohne Anschluss ans Internet erheblich 
entspannter.

Punkt b hat wohl etwas mit der Blase zu tun in der wir sitzen. Als 
Softwareentwickler verändere ich Software jeden Tag, schließlich ist das 
mein Job. Software, die nicht verändert wird, bekomme ich jedoch kaum zu 
sehen.

Andererseits erfreue ich mich gerade in den Abendstunden an einem 
Adventure Game von 1990. Why not?

: Bearbeitet durch User
von Klaus S. (kseege)


Lesenswert?

Ben B. schrieb:
> Ich habe etliche Male nach einem Programmgerüst gefragt, von dem ich den
> Quellcode haben kann, ich hatte die Sprache oder welches Framework
> komplett offen gelassen. Dann kamen viele Wege, womit es denn gehen
> würde, aber außer von Stefan nichts Greifbares, bei dem man Quellcode
> und Ergebnis sehen konnte.

Dann hast Du einfach nach Stefans Beitrag aufgehört zu lesen. Ich hab 
Dir ein ganzes Programm spendiert mit Quelltext und Bild  dazu. Das war 
wohl nicht schnell genug, aber ich muß noch arbeiten und kann nicht den 
ganzen Tag am Rechner sitzen.

Das wäre aber die "kleine" Lösung gewesen, für Leute, die wenig Zeit 
aufwenden wollen. Wenn Du genügend Zeit für die "große" Lösung hast, ist 
die natürlich besser.

Gruß Klaus (der soundsovielte)

von Steve van de Grens (roehrmond)


Lesenswert?

Ben B. schrieb:
> gibt es dann eine intelligente Möglichkeit zum Hochscrollen
... (nimm Widgets)
> Zu spät, dafür wäre vorher Zeit gewesen als ihr mich nur runtergeputzt
> habt. Jetzt habe ich mich für C++ entschieden

Quatsch, dafür ist es nicht zu spät. Widgets sind vorgefertigte 
Dialogelemente, die man in Fenster einfügen kann. Einfachstes Beispiel 
ist der QButton (in Stefans Tutorial). Prinzipiell auf die gleiche Weise 
kann man auch einen QPlainTextEdit oder QTextEdit einfügen.

Wie du selbst siehst, kommt man mit ein paar Pixeln und Linien nicht 
weit. Schnell möchte man komplexere Sachen nutzen, die man von anderen 
Programmen gewohnt ist. Da muss man sich dann halt rein fuchsen. Die 
Webseite von Qt ist voll mit Tutorials wo all das erklärt wird. Es gibt 
auch schöne Bücher zum Thema.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Nochmal, Qt ist für mich tot. Das was ich da oben zusammengesucht habe 
ist auch kein Qt, sondern C++ und dabei werde ich nun auch bleiben.

Ich habe kein großes Problem damit, mir das Scrolling im Fenster und den 
Textbuffer dafür selbst zu schreiben wenn's nicht anders geht. C++ kann 
sicherlich Arrays und dann ist das einfach - ich muss nur wissen ob ich 
das MUSS oder ob es bessere Möglichkeiten gibt, die mir noch nicht 
bekannt sind. Dafür muss ich halt ein wenig forschen wie das mit dem 
Fenster zeichnen funktioniert bzw. dieses Message-System und erstmal 
nach Heinz' Schlagworten googlen ob da was passendes dabei ist.

> Dann hast Du einfach nach Stefans Beitrag aufgehört zu lesen.
Ich hab nicht aufgehört zu lesen. Sorry wenn ich da was übersehen oder 
"ausgeblendet" habe, aber irgendwann wird's auch einfach zuviel um sich 
alles zu merken und den Überblick zu behalten. Das war einer der 
Hauptgründe wieso ich ein Programmgerüst wollte und nicht 100 
Vorschläge womit es alles gehen würde - plus nochmal 50 Meckerpostings 
wieso ich die Scheiße nicht alleine mache und nur einen Deppen suche, 
der's für mich macht weil angebotenes Geld ja bei weitem nicht genug für 
die heilige Elite ist.

Aber ich schaue nochmal ob ich da wirklich was von Dir übersehen habe, 
wenn ja dann war das keine Absicht. Ich bin jedem dankbar, der mir 
ernsthaft helfen möchte und eben nicht nur herummeckert.

Gleich noch eine Frage hinten dran - wie schafft man es in C++ am 
besten, eine Funktion periodisch aufrufen zu lassen, etwa wenn man die 
Daten im Fenster einmal pro Sekunde aktualisieren will?

von Εrnst B. (ernst)


Lesenswert?

Ben B. schrieb:
> ist auch kein Qt, sondern C++

Nochmal: Qt ist eine Bibliothek für C++.

Ben B. schrieb:
> wie schafft man es in C++ am
> besten, eine Funktion periodisch aufrufen zu lassen, etwa wenn man die
> Daten im Fenster einmal pro Sekunde aktualisieren will?

Reines C++ hat keine Timer. Je nach Bibliothek die du verwendest, bietet 
die was entsprechendes an.
z.B:
1
QTimer *timer = new QTimer(this);
2
connect(timer, &QTimer::timeout, this, MeineFunktion);
3
timer->start(1000);

Oder mit deiner Win32-API, such nach "SetTimer", "KillTimer", und 
bearbeite "WM_TIMER"-Messages in deiner Event-Loop.

https://learn.microsoft.com/en-us/windows/win32/winmsg/timers

: Bearbeitet durch User
von Steve van de Grens (roehrmond)


Lesenswert?

Ben B. schrieb:
> Nochmal, Qt ist für mich tot. Das was ich da oben zusammengesucht habe
> ist auch kein Qt, sondern C++ und dabei werde ich nun auch bleiben.

Ich finde schon interessant, wie beharrlich du die Begriffe 
durcheinander bringst, obwohl wir uns alle drum bemühen, dir zu helfen.

C++ ist eine Programmiersprache. Alleine damit kannst du überhaupt nicht 
auf den Bildschirm zugreifen. Mit welchem Framework hast du es denn 
gemacht? Solange das dein Geheimnis bleibt, darfst du dich nicht 
wundern, keine passende Antworten zu bekommen.

Ich bin sicher, dass auch dein Framework mindestens ein pendant zu 
QPlainTextEdit enthält, wenn nicht auch eins zu QTextEdit. Solche 
Widgets gehörten schließlich schon in den 90er Jahren zu Windows, wie 
der Deckel zum Topf.

von Steve van de Grens (roehrmond)


Lesenswert?

Ben B. schrieb:
> Das war einer der Hauptgründe wieso ich ein Programmgerüst wollte
> und nicht 100 Vorschläge

Was hast du erwartet? Du hast schließlich deine Frage an tausende 
Menschen gerichtet. Es gibt nicht "den einen" Königsweg. Vielleicht 
solltest du dich besser an ein Entwicklerbüro wenden, die dir genau eine 
durchdachte Lösung anbieten. Aber frage dann nicht andere, was sie davon 
halten.

von Steve van de Grens (roehrmond)


Lesenswert?

Ben B. schrieb:
> Gleich noch eine Frage hinten dran - wie schafft man es in C++ am
> besten, eine Funktion periodisch aufrufen zu lassen, etwa wenn man die
> Daten im Fenster einmal pro Sekunde aktualisieren will?

Auf einem Betriebssystem wie Windows, Linux, Mac OS, Android, ... 
benutzt man dazu einen Timer, den das Betriebssystem bereit stellt. Der 
Timer sendet Ereignisse, auf die dein Programm reagiert.

https://learn.microsoft.com/de-de/dotnet/api/system.timers.timer?view=net-7.0

Wie gesagt, mit C++ alleine kommst du nicht weit. Du musst dich mit der 
Windows API beschäftigen, oder mit einem Framework, dass darauf aufbaut.

Vielleicht fällt dir langsam auf, dass du jeden Tag weitere 
Anforderungen zu deinem Programmgerüst hinzugefügt hast:

- Schöner Installer
- Serielle USB Geräte erkennen/auslisten
- Formulare mit Eingabefelder, und Buttons
- Text-Felder mit Scrollbalken
- Timer
(ich habe bestimmt noch einige vergessen)

Das läuft ganz klar auf ein Framework hinaus, genau dafür ist .NET 
gemacht worden. Du musst es nur benutzen.

: Bearbeitet durch User
von Klaus S. (kseege)


Lesenswert?

Ben B. schrieb:
> Aber ich schaue nochmal ob ich da wirklich was von Dir übersehen habe,
> wenn ja dann war das keine Absicht.

Das habe ich mir anhand der Menge der Beiträge auch schon so gedacht. 
Meine Empfehlung ist auch keineswegs so, daß sie das einzig Wahre wäre. 
Jeder Techniker weiß, daß es immer mehrere Möglichkeiten mit 
unterschiedlichen Vor- und Nachteilen gibt. Nur die Marketingschwafler 
haben stets die ultimative Lösung.

Mit einer Programmiersprache (wie C++) muß man eben alles selbst 
programmieren, was das Betriebssystem nicht von sich aus mitbringt.

Mit zusätzlichen Paketen wie Libraries und Frameworks bekommt man zwar 
viel Funktionalität angeboten, dafür hat man die Arbeit an der Backe, 
alles zu sichten und einzugliedern. Ich versuche es gerade mit Qt, 
vermutlich werde ich für eine ähnliche Lösung wie mit meinem 
Tcl-Programm aber zehnmal so lange brauchen.

Und die einfachsten Lösungen mit den Skriptsprachen inclusive der 
integrierten Erweiterungen sind typerweise auf einfache Funktionalität 
begrenzt, dafür ist man schnell fertig. Ich bin kein Tcl-Fan, benutze es 
aber, solange ich nichts Besseres finde. Mein Beispielprogramm ist mit 
ca.10KByte Sourcecode etwa so lang wie Stefans Vorschlag und hat 3 Tage 
Programmierung gekostet. Davon waren 2 Tage für den Kampf mit dem 
Schrittmotorcontroller und ein Tag für die Bedienoberfläche. Ob das 
schnell oder langsam ist, soll jeder selbst beurteilen.

Ich hab die Scriptsprache hauptsächlich deswegen vorgeschlagen, weil Du 
wenig Zeit verballern wolltest und weil ein Gerüst darin relativ klein 
ist, so daß ich Dir ohne Schwierigkeiten eines hätte schreiben können, 
wenn Du Interesse gezeigt hättest. Da Du aber auf die entgegengesetzte 
Schiene abzufahren schienst, war mir das dann die Arbeit auch nicht wert 
(meine Faulheit!).

Ich drücke Dir auf jeden Fall die Daumen, daß Du eine passende Lösung 
findest.

Gruß Klaus (der soundsovielte)

von Joe J. (j_955)


Lesenswert?

Lieber Klaus,

Danke für deine Meinung. Dafür darfst du dir jetzt aber auch gerne 
nochmal eine Abholen, denn schließlich passt diese einfach nicht zur 
Welt- und Wertevorstellung vom TO.

Ganz klar ist das hier ein Mecker-Thread. Der TO geht hier allen voran 
und ohne irgend einen ersichtlichen Grund permanent hoch wie ein 
HB-Männchen. Einfach nur blödes gemaule. An der Zahl der Postings sieht 
man eig. schon, das die Leute bemüht und gewillt sind zu helfen.

Es geht hierbei nicht nur um irgendein Pseudo-Programmgerüst, sondern 
darum, das der TO imho keine Ahnung hat was die Programmierung und der 
Datenaustausch über USB für Anforderungen mit sich bringen. Geschweige 
denn, was ein Framework für GUI-Programmierung ist und wie umfangreich 
seine Anforderungen sind. Das alles natürlcih mit Nachdruck einfordern 
für lau. Hut ab.

: Bearbeitet durch User
von Steve van de Grens (roehrmond)


Lesenswert?

Joe J. schrieb:
> ohne irgend einen ersichtlichen Grund permanent hoch wie ein HB-Männchen

Vermutlich steht er unter großem Zeitdruck. Vielleicht hat er einem 
Kunden zu viel versprochen und muss das nun ausbaden.

von Thomas W. (Gast)


Lesenswert?

Steve van de Grens schrieb:
> Joe J. schrieb:
>> ohne irgend einen ersichtlichen Grund permanent hoch wie ein HB-Männchen
>
> Vermutlich steht er unter großem Zeitdruck. Vielleicht hat er einem
> Kunden zu viel versprochen und muss das nun ausbaden.

Er hatte von Anfang an gesagt, dass er ca. 200 - 300EUR fuer ein 
individuelles Framework geben moechte (in toto). Dieses Framework soll 
Daten von der seriellen Schnittstellen erfassen und versenden, dann "den 
Inhalt in einer Variable speichern" (hatte ich nicht verstanden). Das 
Framework sollte dann mit einer Doku geliert werden, so dass der TO 
eigene Erweiterungen programmieren kann. Das alles fuer ein 
Windows-System (Linux/MacOS sind nicht notwendig).

Von der Nutzung der USB-Schnittstelle ist er jetzt weg, jetzt 
USB->Serielle Adapter reicht.

Da sich keiner fuer das Geld gestellt hat, wurde dem TO nachgelegt, es 
selber zu machen. Und da vorhandene Libraries zu komplex sind (Lernkurve 
zu steil), jetzt in C++ mit Win32-Api.

Habe ich was vergessen?

Gruesse

Th.

von Klaus S. (kseege)


Lesenswert?

Joe J. schrieb:
> Danke für deine Meinung. Dafür darfst du dir jetzt aber auch gerne
> nochmal eine Abholen, denn schließlich passt diese einfach nicht zur
> Welt- und Wertevorstellung vom TO.

Lieber Joe,

danke Dir ebenfalls für Deine Meinung. Ich bin einfach ein geduldiger 
Mensch, der auch noch Wadlbeißerfähigkeiten hat. Wenn ich es mir in den 
Kopf gesetzt habe, daß meine Erfahrungen für den TO sinnvoll sein 
könnten, dann werde ich nie, nie, nie aufgeben. Ich weiß, das das dem 
Intelligenzquotienten einer Stubenfliege entspricht, die immer wieder 
gegen dieselbe Fensterscheibe knallt. Andererseits weiß ich aus der 
Erwachsenenpädagogik:

Erwachsene sind lernfähig, aber unbelehrbar (Zitat von Horst Siebert, 
Professor f. ebendiese Erwachsenenpädagogik an der TU Hannover).

Und (leider zu viele) versuchen m.E. den TO zu belehren. Aus seinen 
bisherigen Ausführungen (das hier ist nicht der erste Thread, in dem ich 
Beiträge von ihm lese) weiß ich, daß er vermutlich eine Eigenschaft hat, 
die ich auch habe: Wenn ihm jemand sagt, was er zu tn hat, stellen sich 
ihm die Nackenhaare hoch. Dann neigt man zu Reaktionen, die 
kontraproduktiv sind. Das ist nur eine Vermutung, aber aus meiner Sicht 
eine, für die einiges spricht. Deswegen nehme ich mir die Feiheit, 
weiter mit ihm in Kontakt zu bleiben. Ich hoffe, Du verzeihst es mir.

Gruß Klaus (der soundsovielte)

von Steve van de Grens (roehrmond)


Lesenswert?

Thomas W. schrieb:
> Da sich keiner fuer das Geld gestellt hat, wurde dem TO nachgelegt, es
> selber zu machen. Und da vorhandene Libraries zu komplex sind (Lernkurve
> zu steil), jetzt in C++ mit Win32-Api.
>
> Habe ich was vergessen?

Eigentlich haben wir ehr zu Frameworks wie Qt und .NET geraten, da die 
darunter liegende Win32-Api schwieriger zu verwenden ist.

von Thomas W. (Gast)


Lesenswert?

Steve van de Grens schrieb:
> Thomas W. schrieb:
>> Da sich keiner fuer das Geld gestellt hat, wurde dem TO nachgelegt, es
>> selber zu machen. Und da vorhandene Libraries zu komplex sind (Lernkurve
>> zu steil), jetzt in C++ mit Win32-Api.
>>
>> Habe ich was vergessen?
>
> Eigentlich haben wir ehr zu Frameworks wie Qt und .NET geraten, da die
> darunter liegende Win32-Api schwieriger zu verwenden ist.

Gut, Du hast den Fehler in der Logik des TO gefunden. Ich hatte ihm am 
Anfang .NET mit C# (oder Qt) empfohlen (das waeren gefuehlte 
Dreizeiler). Aus irgendwelchen Gruenden gefiel ihm das nicht so sehr 
(warum auch immer).

Jetzt muss er hart lernen: Experience is a hard teacher, first the test, 
the lesson afterward.

Gruesse

Th.

von Stefan F. (Gast)


Lesenswert?

Ben B. schrieb:
> Das war einer der Hauptgründe wieso ich ein Programmgerüst
> wollte und nicht 100 Vorschläge womit es alles gehen würde

Lass uns mal zusammen zählen:

- Tcl
- Web-Anwendung (HTML, Javascript)
- Qt
- .NET
- Win32 API
- C++
- C#
- Visual Basic
- PHP

Das sind für mich 9 Vorschläge, nicht 100. Nach deinem Feedback hat sich 
das Ganze auf "C++ mit .NET" reduziert. Das ist genau ein konkreter 
Vorschlag.

Du hast dein Ziel erreicht. Warum die schlechte Laune?

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Ben B. schrieb:
> Ich habe kein großes Problem damit, mir das Scrolling im Fenster und den
> Textbuffer dafür selbst zu schreiben wenn's nicht anders geht.

Das bezweifele ich, zumal du wenig bzw. fast gar keine Kenntnisse
hast. Gerade beim Scrolling wirst du ganz schön staunen, wenn es
bei der API ans Eingemachte geht. Ganz abgesehen vom Message-Handling
und der Windows-Prozedur.

Warum glaubst du, warum ich mir damals als Anfänger erst mal eine
Basic-Sprache, die mir die ganze Messageverwaltung und Windowsprozedur
abnahm, zulegte ?

Da hat man zuerst mit seinem Fenster und seinen Controls (Button,
Listboxen usw.) genug zu tun. Dazu noch eine einfache Eventschleife,
die die Clicks abfragt und man entsprechend reagiert.

von C-hater (c-hater)


Lesenswert?

Ben B. schrieb:

> Ich muss ein wenig damit herumspielen und schauen wie diese Message-Loop
> funktioniert bzw. wann und wie oft man so eine Message bekommt und ob
> man den Inhalt des Fensters immer selbst neu zeichnen muss, etwa wenn
> das Fenster verschoben wird oder so.

Das Grundprinzip dieser Message-gesteuerten GUIs ist eigentlich immer 
gleich, ganz egal, wie sie heißen, wie die Messages heißen usw. usf.

Das ist: du hast die Input-Queue zu pollen und die Behandlung an die 
Handler zu verzweigen, die was tun müssen. Bei Frameworks kümmert sich 
i.d.R. das Framework um diese beiden Sachen und die vom Framework 
bereitgestellten "Widgets" oder "Controls" oder wie immer die Dinger 
gerade konkret genannt werden verzweigen dann wieder weiter auf ihre 
eigenen Ereignisse. Du musst nur noch die Handler implementieren, wo du 
eigenes Verhalten implementieren möchtest.

Das ist eigentlich schon alles. Event-driven programming. Für Leute, die 
nur Stino-Kontrollstrukturen á la C-Console-App gewohnt sind, ist das 
eigentlich die größte geistige Hürde...

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Was der TO noch nicht so eindeutig gesagt hat, ist, wie er
die serielle Schnittstelle genau bedienen will. Er schrieb
zwar was von Anfordern und Auslesen. Das wäre natürlich das
Einfachste. Einen Button drücken, Anfrage schicken, Messwerte
erhalten und bearbeiten bzw. in Liste schreiben.

Ein ständiges Pollen ist da schon schwieriger, da ja auch
die GUI bedienbar bleiben sollte. Vielleicht hat er ja deshalb
nach einem Timer gefragt. Meiner Meinung nach ist da ein eigen-
ständiger Prozess (Thread) zum ständigen Pollen besser geeignet.
Meiner Erfahrung nach geht auch ein Timer, wenn der über 300 ms
liegt. Dann bleibt auch die GUI bedienbar.

Sollte nur mal so als Hinweis sein, da ich sowas schon selber
gemacht hatte.

von Stefan F. (Gast)


Lesenswert?

C-hater schrieb:
> Das ist eigentlich schon alles. Event-driven programming. Für Leute, die
> nur Stino-Kontrollstrukturen á la C-Console-App gewohnt sind, ist das
> eigentlich die größte geistige Hürde...

Genau. Nicht die App steuert den PC, sondern umgekehrt.

Sollte die App nebenbei doch etwas aktiv steuern müssen (z.B. eine 
Maschine), läuft es in der meist auf die Verwendung von Timern hinaus. 
Dabei merkt man schnell, dass exakte Timings schwierig sind. Das ist der 
Punkt, von der fette Intel Prozessor von Mikrocontrollern unterstützt 
wird, denen diese Dinge keine Mühe Bereiten: Tastatur, Maus, Drucker, 
...

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Genau, darauf sollte man auch achten.
Ich hatte damals den AVR auf den WindowTimer abgestimmt, was die
Sendeintervalle des AVRs betraf. Das war so am einfachsten.

Auch sollte man darauf achten, daß der AVR in der ASCII-Welt und
der PC in der ANSI-Welt lebt, je nachdem ob man die Daten vom AVR
am PC als Bytes oder Strings bekommt. Um die Daten als String
vom AVR zu bekommen, hatte ich einfach ein Chr(0)an den String
im Mikrocontrollerprogramm -Programm dran gehängt. Den hatte
dann der AVR geschickt.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Angehängte Dateien:

Lesenswert?

So, denn mal versuchen, alle Fragen zu beantworten...

> Ich finde schon interessant, wie beharrlich du die Begriffe
> durcheinander bringst, obwohl wir uns alle drum bemühen,
> dir zu helfen.
Sorry, weiß ich halt nicht besser. Aber wenn es Dich beruhigt, wenn ich 
morgen jemanden operieren müsste weil's kein anderer macht, wüsste ich 
auch nicht wo man z.B. die Milz findet oder wie die Werkzeuge heißen, 
die man zum Ausbau benötigt. Ich glaube vorher gibt man der armen Sau 
lieber den Gnadenschuss, auch wenn eine gewisse Restchance besteht, daß 
ich's aus purem Zufall hinkriegen würde.

> C++ ist eine Programmiersprache. Alleine damit kannst du überhaupt
> nicht auf den Bildschirm zugreifen. Mit welchem Framework hast du
> es denn gemacht? Solange das dein Geheimnis bleibt, darfst du dich
> nicht wundern, keine passende Antworten zu bekommen.
Mit Visual Studio 2022 und der Win32-API, im Wesentlichen nach einem 
Microsoft-Beispiel und etwas googlen für die Grafik und Farben. Das ist 
wirklich noch keine Glanzleistung. Ich hänge den Code dafür mal dran... 
könnt ihr schauen.

> Mit einer Programmiersprache (wie C++) muß man eben alles selbst
> programmieren, was das Betriebssystem nicht von sich aus mitbringt.
Das hatte ich nicht anders erwartet und bin auch bereit, das zu machen. 
Was ich gerne vermeiden würde sind so "Fehler" wie daß ich mir das 
Scrolling z.B. selbst programmiere und dann jemand kommt "öh na du bist 
ja blöde, da hätte es doch dieses oder jenes Objekt gegeben wo du 
einfach alles reinschreiben kannst und Windows macht den Rest 
alleine..."

Mir fehlt da im Moment noch der Überblick, was Windows bzw. die 
Windows-API kann und was nicht - und diese Frage wird mich ganz sicher 
auch noch eine Weile begleiten.

> Vielleicht fällt dir langsam auf, dass du jeden Tag weitere
> Anforderungen zu deinem Programmgerüst hinzugefügt hast:
Naja erstmal ist es bei fortschreitendem Prozess zu erwarten, daß das 
Profil irgendwann von Grundgerüst zum echten Funktionsumfang schwenkt. 
Aber bring bitte nicht alles durcheinander.

> - Serielle USB Geräte erkennen/auslisten
> - Formulare mit Eingabefelder, und Buttons
Das waren die Anforderungen an das Grundgerüst. Den via USB 
angeschlossenen Controller oder "den richtigen" FT232 zu finden und ein 
Fenster-Testaufbau, anhand dessen ich sehen kann, wie sowas im Programm 
aussieht.

> - Text-Felder mit Scrollbalken
> - Timer
Das ergibt sich aus der Weiterführung des Programms und natürlich ist da 
mit weiteren Komponenten zu rechnen, die das Programm früher oder später 
brauchen wird.

> - Schöner Installer
Den brauche ich nicht, wenn ich sowas schreibe, dann soll das definitiv 
ohne Installer laufen. Mir ist nur aufgefallen, daß mein einfacher 
zusammengesuchter erster Test wie manche ultra billigen Installer oder 
Spiele aussieht (z.B. gleicher Standard-Font, um den ich mich noch nicht 
gekümmert habe und viele andere wohl offenbar auch nicht). Und wenn ich 
sowas als hässlich bezeichne, dann muss ich es selbst halt irgendwann 
besser hinkriegen - aber das werde ich dann sehen wenn es soweit ist und 
man sich um solche optischen Aspekte kümmern kann.

Diese Nachrichtenschleife finde ich eigentlich gar nicht so schlecht, 
ich hoffe es gibt die Möglichkeit, sich selbst beliebige Nachrichten zu 
schicken. Ich glaube dann liegt mir dieses Konzept weil's der 
Internetprogrammierung ähnelt. Irgend ein Prozess (a.k.a. User) stellt 
Daten zur Verfügung und möchte damit irgendwas gemacht haben bzw. das 
Programm will damit irgendwas machen.

> Das bezweifele ich, zumal du wenig bzw. fast gar keine Kenntnisse
> hast. Gerade beim Scrolling wirst du ganz schön staunen, wenn es
> bei der API ans Eingemachte geht.
Wieso? Es ist doch kein Problem, sich z.B. 20..30 Zeilen in einem Array 
zu merken, diese "bei Ankunft" einer neuen Zeile einmal durchzukopieren, 
dabei die erste wegzuschmeißen und die neue als letzte anzufügen und das 
Fenster einmal neu zu zeichnen. Das durchkopieren könnte man sich noch 
sparen wenn man sich die Stelle der ersten Zeile merkt, aber den 
Performancegewinn merkt man nur auf sehr langsamen Maschinen.

> Vermutlich steht er unter großem Zeitdruck. Vielleicht hat er
> einem Kunden zu viel versprochen und muss das nun ausbaden.
LOL nee. **lach** Das ist einer dieser Fehler, den ich selbst immer bei 
anderen sehe - was auch ständig in die Hose geht - und den ich daher nie 
machen würde. Wenn ich irgendwas an einen Kunden abgebe, dann nur Dinge, 
die bereits fertig sind oder wo ich mir absolut sicher bin, daß ich sie 
zum Tag X schaffe, plus 1..2 Wochen Sicherheitszuschlag. Mit einer 
Sache, die ich vorher nie gemacht habe (hier Windows-GUI) sage ich ganz 
sicher keine Termine zu. Das ist im Moment ein rein privates Projekt und 
ich hätte es nur gerne früher fertig gehabt als ich allein mit meiner 
Zeit schaffe wenn ich mir alles selbst erarbeiten muss. Daher die 
Anfrage nach dem Programmgerüst für das GUI und die USB-Kommunikation 
und ich wollte es auch nicht für lau haben. Erzählt bitte nicht solche 
gequirlte Scheiße obwohl ihr wisst, daß ich dafür ~300 Euro gegeben 
hätte. Wenn euch das nicht genug ist - okay - es hätte auch sein können 
jemand mit richtig Ahnung von den beiden Sachen hat da Spaß dran und 
freut sich drüber. Bei euch hapert es dann eben an einer dieser beiden 
Sachen und ich habe niemanden gefunden. Werde ich knapp überleben, da 
bin ich im Moment recht zuversichtlich. Ich verliere nur etwas Zeit.

> Was der TO noch nicht so eindeutig gesagt hat, ist, wie er
> die serielle Schnittstelle genau bedienen will. Er schrieb
> zwar was von Anfordern und Auslesen. Das wäre natürlich das
> Einfachste. Einen Button drücken, Anfrage schicken, Messwerte
> erhalten und bearbeiten bzw. in Liste schreiben.
Eines vorweg, es sind keine zeitkritischen Dinge und der Controller soll 
nichts aktiv selbst zum PC schicken. Wenn das Programm (auf dem PC) 
Daten haben will, dann bekommt der µC dazu ein kurzes Kommando welche 
Daten er schicken soll - und dann soll er das natürlich machen. Also 
entweder den aktuellen Messwerteblock oder geloggte Daten nenne ich es 
mal.

Daher kommt auch die Frage nach dem Timer, für den aktuellen 
Messwerteblock wäre es praktisch, wenn man diese einmal alle 1..3 
Sekunden automatisch aktualisieren kann (bzw. die Aktualisierung neu 
anstoßen kann) und der User da nicht immer wieder irgend ein Button 
klicken soll oder sonst was. Sollte es nun dazu kommen, daß man evtl. 
einen größeren geloggten Datenblock haben möchte, ist es nicht schlimm, 
wenn die Anzeige der aktuellen Messwerte dadurch zeitlich etwas 
ausgebremst wird.

Das Eingabefeld, nach dem ich im Programmgerüst gefragt habe, brauche 
ich nur, um dem Controller sowas wie Konfigurationsdaten zu schicken. 
Das ist noch nicht ganz ausgegoren was ich da letztlich genau brauche, 
aber von der Kommunikation her ist es kein Unterschied (nur daß das 
Kommando an den µC evtl. geringfügig länger wird als "gib mal Daten").

> Du hast dein Ziel erreicht.
Noch unvollständig. USB-Kommunikation bzw. virtuelle COM-Schnittstelle 
und die automatisierte Suche nach der richtigen wäre der nächste Punkt, 
den man sich anschauen muss.

> Warum die schlechte Laune?
Habe ich nicht. Mich "nervt" nur mal wieder ein wenig die Tatsache, daß 
man es nie allen recht machen kann.

von Stefan F. (Gast)


Lesenswert?

Ben B. schrieb:
> Was ich gerne vermeiden würde sind so "Fehler" wie daß ich mir das
> Scrolling z.B. selbst programmiere und dann jemand kommt "öh na du bist
> ja blöde, da hätte es doch dieses oder jenes Objekt gegeben wo du
> einfach alles reinschreiben kannst und Windows macht den Rest
> alleine..."

Dann löse dich von der Windows API und benutze das Franmework .NET. Die 
Windows API sollte dich nur für Fälle interessieren, die das Framework 
nicht abdeckt.

Ben B. schrieb:
> Diese Nachrichtenschleife finde ich eigentlich gar nicht so schlecht,
> ich hoffe es gibt die Möglichkeit, sich selbst beliebige Nachrichten zu
> schicken.

Anders geht es in Windows nicht. Das System sendet bestimmte 
Nachrichten, und du kannst eigene Nachrichten definieren. Manche 
Frameworks verbergen diese Schleife bloß in einer Bibliothek, so dass 
man sie nicht gleich sieht.

Ben B. schrieb:
> Noch unvollständig. USB-Kommunikation bzw. virtuelle COM-Schnittstelle
> und die automatisierte Suche nach der richtigen wäre der nächste Punkt,
> den man sich anschauen muss.

Vielleicht schwenkst du doch lieber auf mein Beispiel mit Qt um, denn da 
ist das alles schon drin. Ich würde dir auch gerne eine Variante in .NET 
geben, aber die habe ich halt nicht, und ich kenne mich mit .NET auch 
kaum aus.

> Mich "nervt" nur mal wieder ein wenig die Tatsache,
> daß man es nie allen recht machen kann.

Dir kann es auch nicht Recht machen.

von J. S. (jojos)


Lesenswert?

Win32 API für GUI zu benutzen ist wie Rasen mähen mit Nagelschere.
Kann man machen, ist halt…

von Udo K. (udok)


Lesenswert?

J. S. schrieb:
> Win32 API für GUI zu benutzen ist wie Rasen mähen mit Nagelschere.
> Kann man machen, ist halt…

Die Win32 Api ist für die Anforderungen des TE noch immer eine einfache 
und schnell zum Ziel führende Methode, und schneller zu durchschauen als 
Qt. Und wenn er mal richtig undurchsichtige und komplizierte Oberflächen 
machen möchte, dann hat er damit auch das nötige Grundgerüst, um 
sinnvolle Entscheidungen zu treffen.

Komischerweise liest der TE die Antworten auf seine Fragen nicht - 
eventuell ist er völlig überfordert mit anderen Dingen...
sonst wüsste er schon vor Tagen, dass er in Visual Studio nur ein neues 
Projekt mit dem Wizard aufzumachen braucht - der Wizard macht ihm all 
das was er sich jetzt irgendwo zusammenkopiert hat auf Knopfdruck.
Er könnte das auch mit verschiedenen Frameworks (Win32, MFC, .Net, WPF) 
machen, und die Ergebnisse vergleichen...

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

J. S. schrieb:
> Win32 API für GUI zu benutzen ist wie Rasen mähen mit Nagelschere.

Ganz genau.

Udo K. schrieb:
> Die Win32 Api ist für die Anforderungen des TE noch immer eine einfache
> und schnell zum Ziel führende Methode, und schneller zu durchschauen als
> Qt.

Ja schon, aber ohne Texteditor mit Scroll-Funktion. Den muss er sich 
dann selbst aus Grashalmen zusammen flechten - das wollte er (sinnvoller 
weise) vermeiden.

> Komischerweise liest der TE die Antworten auf seine Fragen nicht

Ich denke schon, dass er sie liest, aber er versteht sie nicht, weil er 
ohne Frameworks aufgewachsen ist. Dass die gängigen Frameworks genau das 
Gerüst sind, dass er sucht, liegt außerhalb seiner Vorstellungskraft.

Ich meine: Wir haben es mehrfach geschrieben. Wir haben ihm komplette 
ausführbare Projekte gegeben. Wir haben Screenshots gezeigt, und auf 
Tutorials verwiesen. Was soll man den sonst noch tun? Alles was darüber 
hinaus geht wäre Nötigung.

Der Ben muss das "einfach" mal ausprobieren. Ja, dazu muss man einiges 
an Doku lesen. Einen eigenen Texteditor auf Basis der Windows API zu 
klöppeln dauert aber garantiert noch viel länger. Ein ausführbares 
Programmbeispiel (wie meins) ist ohne Dokumentation auch nicht 
nützlicher. In der Zeit, wo ich sie schreibe, kann er auch gleich das 
Lesen, was schon da ist: Die Dokumentation des Frameworks.

von Thomas W. (Gast)


Lesenswert?

Man (oder Frau) nimmt C#, packt ein Combobox namens cmbPort, eine 
Multiline-Textbox namens textBox1 in ein Form (Form1).

In Form1_Load die Enumerieren der Seriellen Ports:
1
private void Form1_Load(object sender, EventArgs e)
2
{
3
   string[] ports = SerialPort.GetPortNames();
4
   foreach (string port in ports)
5
   {
6
     cmbPort.Items.Add(port);
7
   }
8
}

Jetzt Auswahl des Portes und Oeffnen des Portes:
1
private void cmbPort_SelectedIndexChanged(object sender, EventArgs e)
2
{
3
  serialPort1.PortName = cmbPort.Items[cmbPort.SelectedIndex].ToString();
4
  serialPort1.BaudRate = 9600;
5
  serialPort1.DataBits = 8;
6
  serialPort1.Parity = Parity.None;
7
  serialPort1.StopBits = StopBits.One;
8
  serialPort1.Open();
9
}

Und jetzt kommt der beruehmte DreiZeiler (Empfang die Daten):
1
private void serialPort1_DataReceived(object sender, SerialDataReceivedEventArgs e)
2
{
3
   string line = serialPort1.ReadLine();
4
   this.BeginInvoke(new LineReceivedEvent(LineReceived), line);
5
}

und schiebe die Daten in die Oberflaeche:
1
private delegate void LineReceivedEvent(string line);
2
private void LineReceived(string line)
3
{
4
   textBox1.AppendText(line + "\r\n");            
5
}

Wenn der Arduino/uC auch Daten bekommen soll:
1
private void textBox1_KeyPress(object sender, KeyPressEventArgs e)
2
{
3
   serialPort1.Write(e.KeyChar.ToString());
4
}

Das war's. Noch ein wenig magic fuer Auswahl der 
Schnittstellen-Parameter. Ob ReadLine() der Grosse Bringer ist, weiss 
ich natuerlich nicht. Aber die Idee sollte klar werden. Jetzt kann man 
sich Gedanken ueber die Scaling am Schirm oder/und ob man eine Textzeile 
zu senden.

Th.

von C-hater (c-hater)


Lesenswert?

Heinz B. schrieb:

> Ein ständiges Pollen ist da schon schwieriger, da ja auch
> die GUI bedienbar bleiben sollte.

Vernünftige OS und auch GUI-Frameworks stellen natürlich auch asynchron 
generierte Ereignisse für alles bereit, wo beim Lesen signifikante 
Wartezeiten auftreten können.

Da ist dann oft nur das Problem, die das "Ergbnis" der Behandlung des 
Ereignisses wieder sauber in den Kontext des GUI-Thread zu bringen.

> Vielleicht hat er ja deshalb
> nach einem Timer gefragt. Meiner Meinung nach ist da ein eigen-
> ständiger Prozess (Thread) zum ständigen Pollen besser geeignet.
> Meiner Erfahrung nach geht auch ein Timer, wenn der über 300 ms
> liegt. Dann bleibt auch die GUI bedienbar.
>
> Sollte nur mal so als Hinweis sein, da ich sowas schon selber
> gemacht hatte.

Das sind alles nur Notlösungen, die i.A nur zwei Sachen aufzeigen:

a) Das OS/Framework ist Scheiße, weil es eben keinen hinreichenden 
Support für sowas mitbringt.

ODER

b) der Programmierer ist Scheiße, weil er nicht in der Lage ist, den 
vorhanden Support (richtig) zu benutzen.

Heute ist fast immer eher Fall b) zutreffend...

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Na gut, dann bin ich eben Scheiße und das Windows OS ebenso.
Soll der TO doch sein Zeug mit den anderen zusammenfrickeln.
Ich weiß nur eines :
Wenn der TO mit etwas leichterem angefangen hätte, hätte er jetzt
schon ein passables Programm, wo evtl. nur noch der graphische
Teil (Diagramm darstellen) zu machen wäre.

Ich finde es für Schwachsinn, wenn jemand ohne jegliche Ahnung mit
der Windows-Api konfroniert wird. Deshalb wurden doch die Frameworks,
sei es jetzt versteckt in einem Basicdialekt oder sonstwie, erschaffen,
um einem neuen Anwender den Einstieg zu erleichtern.

Und damit verabschiede ich mich von diesen Thread.
Und Tschüß.

: Bearbeitet durch User
von C-hater (c-hater)


Lesenswert?

Heinz B. schrieb:
> Na gut, dann bin ich eben Scheiße und das Windows OS ebenso.

Windows fällt hier als Ursache aus. Das kann zumindest seit Win32s (und 
bei NT schon immer) jegliche Filezugriffe auch asynchron abhandeln. Und 
der "Hauptdatenpfad" eines COM-Ports IST ein File.

Aber darüber hinausgehend liefert Win32(s)/NT selbst für die vier 
exotischen "Modem-Ereignisse" (also Pegelwechsel an einer der vier 
Leitungen CD, CTS, DSR, RI) ein asynchrones API.

Die SerialPort-Klasse von .Net unterstützt das ALLES und stellt es als 
asynchrone Events bereit. Mono unter Linux übrigens ebenso. Wird dort 
natürlich nicht via Win32-API abgebildet, sondern mit den Mitteln, die 
Linux dafür bereitstellt...

Da bleibt eigentlich kein Wunsch offen.

von J. S. (jojos)


Angehängte Dateien:

Lesenswert?

Ich habe mal ein Gerüst in node-red zumsammengestrickt.
GUI ist über Webbrowser und NR läuft auf vielen Plattformen, auch 
Raspberry wenn es als Server 24*7 laufen soll.
Zentral ist der Switch Node, der leitet die Messages je nach topic an 
die Anzeigeelemente. Das sind eingebaute in NR, die werden nur 
konfiguriert. Für die LED oder anderes gibt es weitere als Zubehör.
Links die Inject Nodes sind nur zum Testen oder Simulieren, hier würde 
man den Datenlieferanten anklemmen. Das kann ein Node für die serielle 
Schnittstelle sein, aber auch TCP, UDP, MQTT, HTTP oder was es noch 
alles gibt. Auch die Ausgabe ist dann nicht auf Web beschränkt, es kann 
auch in Dateien oder Datenbanken geschrieben werden.
Das möchte ich nicht in C++ Plattformabhängig schreiben, damit würde man 
min. 30 Jahre rückwärts starten.
Bei der History habe ich noch geschummelt, eine einfache Listbox war 
nicht dabei. Aber da kommt ja die Frage nach der Persistenz auf: sollen 
alte Einträge irgendwo herkommen? Und da geht es wieder relativ einfach 
über eine DB oder JSON Dateien in NR.
Das Grundprinzip in NR ist auch einfach: die Verbindungen zwischen den 
Nodes sind Messages die immer topic und payload enthalten, alles läuft 
Ereiginsgesteuert.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Komischerweise liest der TE die Antworten auf seine Fragen nicht -
> eventuell ist er völlig überfordert mit anderen Dingen...
Was sollen diese dummen Unterstellungen jetzt schon wieder? Ey das sind 
alles erwachsene Leute hier, wieso kommen da so oft Reaktionen wie im 
Kindergarten? Hab ich euch irgendwas getan, die Buddelförmchen geklaut 
oder so? Der letzte Beitrag von Heinz passt auch prima dazu - warum so 
eine Reaktion? Soll ich jetzt auch mal sinnlos mutmaßen woran diese 
Probleme liegen könnten oder wollt ihr den Rest vom Feiertag gerne noch 
genießen? ... Schade.

> sonst wüsste er schon vor Tagen, dass er in Visual Studio
> nur ein neues Projekt mit dem Wizard aufzumachen braucht [..]
Ich habe mich bewusst gegen den Wizard entschieden weil ich ein 
möglichst einfaches Programm haben wollte und daß überhaupt erstmal 
irgendwas funktioniert. Ich wollte keine 10..20 Kilobyte-C-Bombe, wo ich 
wieder 'ne Woche brauche bis ich sie verstehe. Das wäre bei einem 
abgestimmten Programmgerüst schon schwierig geworden. Ich wollte erstmal 
nur ein Fenster-Programm haben, was sich ohne Probleme compilieren, 
starten und beenden lässt und hab dann herumgespielt, was ich mit dem 
Fenster so machen kann - die paar Textzeilen und daß so einfach immerhin 
rudimentäre Grafik funktioniert, hätte ich gar nicht erwartet. Ich 
dachte, dafür fehlt garantiert wieder irgendwas.

Ich habe echt das Gefühl, ihr versteht mich einfach nicht. Und ich weiß 
nicht wie ich das ändern soll. Meine, ich habe gefragt, ob die Win32-API 
ein Objekt oder eine Funktion beinhaltet, welche scrollbaren Text kann. 
Ein einfaches "Nein" hätte gereicht um die Frage zu beantworten. 
Stattdessen kommen nun schon wieder Mußmaßungen, ich möchte einen 
scrollbaren Texteditor. Nein, möchte ich nicht.

Ich habe vielleicht ein etwas falsches Verständnis vom Aufbau dieser 
Fenster bzw. wegen nicht besser wissen viele unzutreffende Vermutungen. 
Noch nicht mal Erwartungen. Etwa, daß es sowas wie scrollbaren Text 
kann, vielleicht sowas wie stdout für ein Fenster nutzen kann. Wenn es 
das nicht kann (Win32 API) und ich mir alles grafisch selbst bauen muss, 
dann weiß ich das jetzt. Also es gibt quasi keinen Textmodus, sondern es 
gibt nur einen Grafikmodus.

Die einzige Eingabemöglichkeit, die ich neben 1..2 Buttons und 
vielleicht sowas wie Checkboxen zum Einstellen irgendwelcher 
Programmfunktionen brauche, ist eine einzelne Textzeile, in die man ein 
Kommando für den µC eintippen und abschicken kann, darüber ein paar 
Zeilen Text für die Antwort des µC. Mehr nicht. Bzw. der Rest ist 
grafische Darstellung von ein paar Messwerten über eine Zeitachse und 
wie das funktioniert, habe ich bereits zur Hälfte herausbekommen.

@Thomas
Danke nochmal für Deine Mühe bezüglich der seriellen Kommunikation. Ich 
werde schauen was ich ohne .NET/C# davon verwenden kann. Ich weiß im 
Moment nicht wo die Trennung zwischen C++ (was ich eigentlich möchte, 
auch entschieden wegen späterer Verwendbarkeit zur Programmierung 
größerer Controller) und C# (was Du empfiehlst) ist. Wenn ich da zuviel 
vermische, dann habe ich am Ende wirklich noch ein Verwirrungs-Problem.

von C-hater (c-hater)


Lesenswert?

Ben B. schrieb:

> Meine, ich habe gefragt, ob die Win32-API
> ein Objekt oder eine Funktion beinhaltet, welche scrollbaren Text kann.

Wenn das deine Frage war: die Antwort ist JA.

Es gibt sogar zwei derartige "Controls" (hier als "Fensterklassen" 
tituliert).

Da ist zum einen die Textbox (mit Multiline) und zum anderen Rich-Text. 
Letzteres kann dann nicht nur scrollen, sondern auch bunte Farben und 
Textattribute wie etwa Fett oder Latin. Da geht also schon stark in 
Richtung der Möglichkeiten eines üblichen seriellen Terminals mit den 
entsprechenden Emulationen. Die du allerdings selber implementieren 
müsstest, Rich-Text stellt nur die Ausgabemöglichkeiten dafür bereit.

von Udo K. (udok)


Lesenswert?

Ben B. schrieb:
>> Komischerweise liest der TE die Antworten auf seine Fragen nicht -
>> eventuell ist er völlig überfordert mit anderen Dingen...
> Was sollen diese dummen Unterstellungen jetzt schon wieder? Ey das sind
> alles erwachsene Leute hier, wieso kommen da so oft Reaktionen wie im
> Kindergarten? Hab ich euch irgendwas getan, die Buddelförmchen geklaut
> oder so? Der letzte Beitrag von Heinz passt auch prima dazu - warum so
> eine Reaktion? Soll ich jetzt auch mal sinnlos mutmaßen woran diese
> Probleme liegen könnten oder wollt ihr den Rest vom Feiertag gerne noch
> genießen? ... Schade.

Irgendwie finde ich es ziemlich mühsam, mit dir zu kommunizieren.
Du forderst andauernd von den Leuten gratis Arbeit.
Du bist aber nicht in der Lage die Tipps anzunehmen, du liest ständig 
über die Antworten drüber und ignorierst die Ratschläge.  Du testest das 
Zeugs nicht, was dich im Falle von VS weniger als 5 Minuten an Zeit 
kostet. Behauptest aber unsinniges Zeugs von 10k Zeilen, die der VS 
Wizard erzeugt... ABER du hast trotzdem die Zeit, hier stundenlang 
rumzuhängen, und die Leute die versuchen zu helfen, anzupöbeln...

von Thomas W. (Gast)


Lesenswert?

Ben B. schrieb:

> @Thomas
> Danke nochmal für Deine Mühe bezüglich der seriellen Kommunikation. Ich
> werde schauen was ich ohne .NET/C# davon verwenden kann. Ich weiß im
> Moment nicht wo die Trennung zwischen C++ (was ich eigentlich möchte,
> auch entschieden wegen späterer Verwendbarkeit zur Programmierung
> größerer Controller) und C# (was Du empfiehlst) ist. Wenn ich da zuviel
> vermische, dann habe ich am Ende wirklich noch ein Verwirrungs-Problem.

Ich wuerde auf alle Faelle eine Qt-Loesung benutzen, wg. der 
Unabhaengigkeit vom Betriebssystem. Du hast deutlich klar gemacht, 
dass fuer Dich die Unabhaengigkeit nicht so wichtig ist -> Das 
Entwicklungssystem VisualStudio 2022 passt fuer Dich, es ist nicht so 
schlecht (ein sehr schoener Editor fuer die Masken), bei Deinem 
angedachten Szenarium (Windows 64bit) ist das .NET-Runtime Bestandteil 
des Betriebssystems.

Ich persoenlich finde ich C# nicht so gut (man ist so festgelegt auf 
MS), aber wenn das fuer Dich passt ist doch gut. Es ist platt, aber 
der Wurm muss dem Fisch gefallen, nicht mir.

Man kann jetzt ueber VisualStudio geteilter Meinung sein, aber richtig 
schlecht ist es eigentlich nicht. Und man kommt relativ schnell zu einem 
lauffaehigen Programm, der Debugger ist auch gut. Die Speicherverwaltung 
wird durch den Garbage-Collector gemacht.

Du musst natuerlich auch gucken, wie viel Zeit Du noch in die 
Programmierung dieser Fingeruebung versenken willst.

Gruesse

Th.

von C-hater (c-hater)


Lesenswert?

Thomas W. schrieb:

> Ich wuerde auf alle Faelle eine Qt-Loesung benutzen, wg. der
> Unabhaengigkeit vom Betriebssystem.

.Net ist ähnlich unabhängig. Zumindest für alle relavanten OS. Der 
Vorteil von Qt ist eher: das geht zur Not auch OHNE OS.

> Ich persoenlich finde ich C# nicht so gut (man ist so festgelegt auf
> MS)

Ähem, nö. Es gibt Mono. Damit hat man Linux und Android und IOs als 
mögliche Targets. Also ziemlich alles, was auch nur einigermaßen 
relevant ist.

> Man kann jetzt ueber VisualStudio geteilter Meinung sein

Eigentlich nicht. Das Ding hat einen absolut überragenden Komfort für 
Entwickler, ist einigermaßen logisch strukturiert und halbwegs 
fehlerfrei. Alles Sachen, die man z.B. über den ganzen Eclipse-basierten 
Scheiß so nicht sagen kann. DAS ist "pain in the ass". Ganz besonders 
unter Windows als Entwicklungssystem.

von Joe J. (j_955)


Angehängte Dateien:

Lesenswert?

Hi Ben,

im Anhang ein Gerüst für einen STM32H730. Ist eine CDC Klasse(VCOM - 
virtuell seriell).

Das ist die Controller Seite und funktioniert so bei mir.
Du musst dann entsprechend die CPU umstellen, wenn du dich für ST 
entscheidest.

Die Gegenstelle wäre dann noch zu tun.

Viele Grüße joe

von Nico S. (nico_s545)


Lesenswert?

Hallo Ben,

auch wenn hier schon ein paar Monate ins Land gegangen sind, hier meine 
Angaben über die von mir seit Jahren genutzte Lösung:

SW-Seite:

ich verwende von www.alanmacek.com/usb/ die usb.c & usb.h; damals in 
Visual C++ 6.0, mittlerweile in VisualStudio 2008 für die PC Umgebung 
(VC++ mit MFC).
Grafikprojekt (Layout vergleichbar mit einem Patientenmonitor im 
Krankenhaus) funktioniert auch.

HW-Seite:

ich nutze den MikroC Pro Compiler und dessen USB-Library für PIC18F14K50 
und PIC18F46J50. 16bit PIC24FJxx ist noch in Vorbereitung. PS: Die 
Mikrocontroller haben ein USB Modul implementiert.

Features u.a.:
- bidirektionale Kommunikation
- PC-Programm erkennt an-/abgestöpselte HW
- die Daten werden derzeit mit 150ms (+/-x) übertragen und visualisiert

Gruß
Nico

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.