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...
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.
> 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.
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.
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.
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.
>> 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.
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"?
> 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.
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.
> 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.
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.
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
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.
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.
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.
Hier liefert der Hersteller den Quellcode mit: https://www.diamex.de/dxshop/USB-Temperatur-Sensor-Tester-fuer-DS18B20-Rev-E
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.
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?
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.
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.
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.
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.
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...
> 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.
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.
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/
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
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.
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...
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.
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. "
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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?
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.
@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.
Angehängte Dateien:
-
Unbenannt.PNG
210 KB
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.
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.
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
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
> 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.
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.
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.
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.
Ε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
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.
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.
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.
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...
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.
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.
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.
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.
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.
Beitrag #7410522 wurde von einem Moderator gelöscht.
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
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;-)
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%.
>> 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.
> 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.
Angehängte Dateien:
-
ioModule.png
24 KB -
ioModule2.png
50 KB
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.)
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.
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.
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)
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
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.
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.
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.
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.
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.
@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.
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?
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.
> 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?
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.
Okay, also darf man Qt nicht wie eine C-Erweiterung verstehen. Dann müsste ich irgendwann Deine Toolchain übernehmen.
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/
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.
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)
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.
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
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.
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.
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.
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.
> 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?
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..
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
> 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.
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.
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.
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
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"?
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
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.
> 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.
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
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#.
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.
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.
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.
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)
Angehängte Dateien:
-
KSEMIS4.PNG
16 KB
Das zugehörige Bild ist leider verlorengegangen, irgendwie bekomme ich nur eine einzige Datei an den Text geklebt.
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.
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.
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.
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.
> 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.
Fange einfach mal an, anstatt weiter Zeit mit Diskutieren zu vergeuden.
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
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.
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.
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.
Angehängte Dateien:
-
Test1.jpg
11 KB
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!
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.
Angehängte Dateien:
-
2023-05-16_11-55.png
10 KB
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.
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.
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.
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...
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.
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 ?
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.
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)?
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
> 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?!
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.
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.
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
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.
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.
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?
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)
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.
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?
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
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.
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.
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.
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)
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.
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.
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.
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)
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.
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.
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?
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.
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...
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.
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, ...
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.
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.
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.
Win32 API für GUI zu benutzen ist wie Rasen mähen mit Nagelschere. Kann man machen, ist halt…
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...
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.
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.
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...
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üß.
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.
Angehängte Dateien:
-
dashboard.png
25 KB -
flow-dispatcher-ui.png
74 KB -
node-switch.png
5,8 KB
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.
> 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.
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.
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...
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.
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.
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.