Hi, ich weiß es gibt schon ein paar Beiträge zum Thema, aber ich konnte nichts passendes finden. Ich möchte einen Microcontroller/ Raspberry Pi nutzen um verschiedene Daten auszulesen, verarbeiten und steuern. (Auslesen über Uart, CAN, Steuern über GPIOs). Zudem sollen die Werte an einem Windows Rechner dargestellt werden. Ich habe bereits Erfahrung im µC Programmieren und C, C++. Allerdings habe ich noch keine GUI programmiert und weiß nicht wie ich das ganze am PC darstellen soll. Eine Idee von mir wäre zum Beispiel über einen Raspberry Pi das als Website darzustellen und dann per Lanverbindung am PC anzuschauen. Andernfalls über Uart die Daten an den PC senden und dort dann aufbereiten? Welche Ideen habt ihr? lieber µC oder Pi? Wie kann ich das am einfachsten programmieren und Darstellen? Vielen Dank Michael
Michael schrieb: > Eine Idee von mir wäre zum Beispiel über einen Raspberry Pi das als > Website darzustellen und dann per Lanverbindung am PC anzuschauen. Dann musst Du auf dem PC gar nichts programmieren. Wenn Du es hinbekommst, auf Deinem Pi den Kram als Webseite zu erzeugen, bist Du fertig.
Das hört sich ziemlich nach etwas an was man mit Hausautomatisierungen erschlagen könnte. Schau Mal bei OpenHAB, Home Assist oder ähnlichem vorbei. Bestimmt gibt es da ein Plugin für CAN und GPIO. Daten darstellen dann vielleicht über eine Graphana Instanz.
Harald K. schrieb: > Dann musst Du auf dem PC gar nichts programmieren. Wenn Du es > hinbekommst, auf Deinem Pi den Kram als Webseite zu erzeugen, bist Du > fertig. Ja klar, nur ist die Frage wie ich das am besten mache. Ich habe wie gesagt Erfahrung mit Microcontrollern, aber nicht mit Pi programmierung.
> Eine Idee von mir wäre zum Beispiel über einen Raspberry Pi das als > Website darzustellen und dann per Lanverbindung am PC anzuschauen. Das klingt nach einer modernen Loesung im Zeichen unserer Zeit welche alle Probleme ohne Ruecksicht auf Bandbreite und Resourcen loesen kann. Du koenntest auch einfach nur auf dem Raspi programmieren und das Fenster deiner Anwendung dann auf einen X11 client oeffnen. Sowas konnte Unix schon vor 20Jahren und man wuerde annehmen das die Windowswelt sowas mittlerweile darstellen kann. > Andernfalls über Uart die Daten an den PC senden und dort dann > aufbereiten? Auch das klingt letztlich nach einer brauchbaren Loesung. Vor allem wenn du die Muskeln eines Raspberry sonst nicht brauchst und alles mit einem lokalen Billigcontroller loesen kannst. > Ich habe bereits Erfahrung im µC Programmieren und C, C++. Wenn du C++ schon kannst dann nimm einfach Qt und du bist schon fast fertig. Vanye
Michael schrieb: > Erfahrung mit Microcontrollern, aber nicht mit Pi programmierung Dann nimm z.B. einen ESP32, der kann auch eine Webseite erzeugen.
Du holst Dir die kostenlose Community Eddition der C++ Builders von Embarcadero / Idera. Mit ihm kannst du in C++ programmieren. Die GUI wird dort visuell entworfen und automatisch in C++ umgesetzt, du brauchst dann nur noch die Verbindung von Deinem Programm zur GUI herzustellen. Schau Dir den Builder an, der ist geil! mfg
Geht in Basic auf dem ESP8266: https://www.esp8266basic.com/download.html Simples Beispiel: WebGUI https://www.esp8266.com/viewtopic.php?f=40&t=4848 Einfacher gehts nicht!
Michael schrieb: > Ich habe bereits Erfahrung im µC Programmieren und C, C++. Michael schrieb: > Ich habe wie gesagt Erfahrung mit Microcontrollern, > aber nicht mit Pi programmierung. Du kannst den Raspberry Pi in C und C++ programmieren. Eine Web GUI ist komplexer als eine klassische Desktop Anwendung, weil deine C++ Anwendung dann HTML Seiten und Grafiken erzeugen muss, die der Browser dann kombiniert darstellt. Wenn du bereits mit Web-Programmierung vertraut bist, dann fein, mach es. Ansonsten: Überlege dir gut, ob es den Aufwand Wert ist. Tipp dazu: Für Messwerte bietet sich SVG an. SVG Bilder kann man mit printf() erzeugen. https://wiki.selfhtml.org/wiki/SVG Mein Favorit für Desktop Anwendungen in C++ ist das Qt Framework. Für den Einstieg könnte dieses Tutorial helfen: http://stefanfrings.de/qt_lernen/index.html Kleine kompakte Web-Server lassen sich ganz gut in der Programmiersprache Go programmieren. Die Sprache ist ähnlich zu C, plus ein rudimentärer Ansatz objektorientierter Programmierung. In Go ist es besonders einfach, ein Programm zunächst unter Windows zu entwickeln und danach für Linux (den Raspi) zu compilieren, so dass es dort lauffähig wird. Falls du dir Go anschauen willst: http://stefanfrings.de/go_webserver/index.html
:
Bearbeitet durch User
Vanye R. schrieb: > ... Probleme ohne Ruecksicht auf Bandbreite und Resourcen loesen > kann. > Du koenntest auch einfach nur auf dem Raspi programmieren und das > Fenster > deiner Anwendung dann auf einen X11 client oeffnen. Sowas konnte Unix > schon vor 20Jahren und man wuerde annehmen das die Windowswelt sowas > mittlerweile darstellen kann. Ach. Ein paar MB für die Webseite und danach ein paar Bytes/sec für Messwerte/Aktionen sind dir zu viel, aber Gigabytes an unkomprimierten Grafikdaten über X11 sind OK? Oder willst du dem TE ein Uralt-X11-Tooklit andrehen, was tatsächlich noch die X11-Zeichenfunktionen nutzt? Aber selbst da ist die Webseite bandbreitentechnisch weit im Vorteil.
Vanye R. schrieb: >> Eine Idee von mir wäre zum Beispiel über einen Raspberry Pi das als >> Website darzustellen und dann per Lanverbindung am PC anzuschauen. > > Das klingt nach einer modernen Loesung im Zeichen unserer Zeit > welche alle Probleme ohne Ruecksicht auf Bandbreite und Resourcen loesen > kann. [...] > Du koenntest auch einfach nur auf dem Raspi programmieren und das > Fenster deiner Anwendung dann auf einen X11 client oeffnen. [...] Na da hat ja mal jemand richtig "Ahnung"... rolleyes
Michael schrieb: > Ich möchte einen Microcontroller/ Raspberry Pi nutzen um verschiedene > Daten auszulesen, verarbeiten und steuern. (Auslesen über Uart, CAN, > Steuern über GPIOs). Zudem sollen die Werte an einem Windows Rechner > dargestellt werden. > Ich habe bereits Erfahrung im µC Programmieren und C, C++. Allerdings > habe ich noch keine GUI programmiert und weiß nicht wie ich das ganze am > PC darstellen soll. Naja, die GUI wäre ein Ding, aber... zuerst müssen die Daten ja irgendwie vom RasPi auf den PC, und das ist dann wieder ein ganz anderes Ding. Klar könntest Du da was mit dem auf dem RasPi ohnehin bereits vorhandenen SSH-Server und in Deiner GUI-Software mit libssh arbeiten, aber dann wird Deine Anforderung von "möglichst einfach" vermutlich nicht erreicht. > Eine Idee von mir wäre zum Beispiel über einen Raspberry Pi das als > Website darzustellen und dann per Lanverbindung am PC anzuschauen. > Andernfalls über Uart die Daten an den PC senden und dort dann > aufbereiten? Die Website wäre sicherlich der einfachste Weg: Du mußt kein Kabel für die Serielle zum Rechner ziehen, mußt auch nichts über SSH implementeren, Dich nicht um die Verwaltung von SSH-Schlüsseln kümmern, ... Was den Webserver angeht... da kannst Du etliche verschiedene Wege nehmen. Klassischerweise würde man einen der Üblichen Verdächtigen (Apache, NGinx) nehmen und die Software in einer Skriptsprache schreiben; der Vorteil von Skriptsprachen liegt an dieser Stelle in der kurzen Entwicklungszeit, wird jedoch mit einem höheren Verbrauch an Ressourcen erkauft. Dafür bietet zum Beispiel die Skriptsprache Python mit dem Micro-Webframework Flask und den vielen performanten Bibliotheken zur Datenverarbeitung und -Visualisierung (numpy, scipy, Pandas, Matplotlib, Seaborn, Plotly, ...) eine großartige Umgebung, mit der Du (nach einer kleinen Lernkurve) schnell und effizient arbeiten, und auch künftige Änderungen oder Erweiterungen schnell einbauen kannst. Ganz besonders schick: mit entsprechenden serverseitigen Endpoints kannst Du Deine Datenvisualisierungen sogar leicht interaktiv machen, dann werden die Daten serverseitig nur ausgewählt und aggregiert, dann (gern im JSON-Format) an Deinen Webbrowser gesendet, und der sich selbständig um die Darstellung kümmert. Wenn Du eine perfekte Benutzererfahrung mit maximaler Funktionalität, eine sehr hohe Flexibilität und eine kurze Entwicklungszeit haben möchtest, dann ist das der Way to go. Für C und / oder Cpp gibt es ebenfalls Webframeworks, zum Beispiel Oatpp [1], Drogon [2] oder wt [3]. Ich persönlich mag Drogon -- dazu gleich noch was -- aber am Ende solltest Du Dir jedes der drei Frameworks einmal anschauen, ein kleines bisschen Code damit entwickeln und dann entscheiden, welches Dir am besten gefällt. Die Sache mit den clientseitigen Javascript-Visualisierern funktioniert natürlich auch mit diesen Frameworks. C++ hätte den Vorzug, daß Du keine neue Sprache lernen müßtest, allerdings würde ich mir dazu nicht zu viel erhoffen: das C++, das Du von Mikrocontrollern kennst, wird eine andere "Art" von C++ als das sein, was Du für diese Webframeworks brauchst. Trotz meiner Vorlieben für Flask und Drogon würde ich so etwas aber heute wohl eher mit Golang entwickeln, wenn es nicht allzu häufig verändert, erweitert, oder anderweitig angepaßt werden soll. Go bringt einen eigenen Webserver mit, die statischen Binaries sind besonders angenehm beim Deployment, gerade in Containerumgebungen wie Docker, und bieten eine minimale Angriffsoberfläche (das dürfte für interne Services wie bei Dir nicht so wichtig sein...) Zudem ist der Go-Webserver ausgesprochen performant und steht diesbezüglich einer Implementierung in C++ in nichts nach, verbraucht dabei aber womöglich noch weniger Ressourcen... :-) Tja, am Ende hast Du jetzt immer noch die Qual der Wahl, aber hoffentlich konnte ich Dir ein paar Anregungen geben, was Du Dir anschauen kannst. Viel Vergnügen und Erfolg bei Deinem Projekt! :-) [1] https://github.com/oatpp/oatpp [2] https://drogon.org/ [3] https://www.webtoolkit.eu/wt
Steve van de Grens schrieb: > Eine Web GUI ist komplexer als eine klassische Desktop Anwendung, weil > deine C++ Anwendung dann HTML Seiten und Grafiken erzeugen muss, die der > Browser dann kombiniert darstellt. Ja, äh, nein, man kann (und sollte) sich die serverseitige Generierung von Grafiken einfach sparen, sondern einfach nur JSON ausliefern, und das dann clientseitig zu hübschen Visualisierungen und Tabellen rendern lassen. Das entlastet nicht nur die Server- und die Netzwerkressourcen, ermöglicht eine interaktive Darstellung im Webbrowser (siehe zum Beispiel hier [1], da [2], dort [3] oder dahinten [4]) und verlagert den Rechenaufwand wirksam auf den Client, als quasi eine Art "poor man's distributed computing". Und, ach ja: JSON läßt sich gut komprimieren, think HTTP-Header "Accept-Encoding". [1] https://plotly.com/python/box-plots/ [2] https://observablehq.com/@d3/streamgraph-transitions?intent=fork [3] https://docs.bokeh.org/en/latest/docs/examples/basic/data/transform_markers.html [4] http://mpld3.github.io/examples/interactive_legend.html
Εrnst B. schrieb: > Ach. Ein paar MB für die Webseite und danach ein paar Bytes/sec für > Messwerte/Aktionen sind dir zu viel, aber Gigabytes an unkomprimierten > Grafikdaten über X11 sind OK? hüstel Über SSH ließe sich der X11-Traffic zumindest verschlüsseln und komprimieren, auf Kosten der Reaktionslatenz bei der Bedienung... :-)
> Tja, am Ende hast Du jetzt immer noch die Qual der Wahl, aber
Dein Posting zeigt sehr schoen warum das Internet in den letzten
20Jahren mit immer hoeherer Geschwindigkeit gegen die Wand faehrt.
Dreihundertdroelfig unterschiedliche Sprachen, gerne auch noch in
den unterschiedlichsten Versionen, je nach Mode jedes Jahr anders
die irgendwie undurchsichtig zusammenwirken.(oft auch mal nicht)
Am Ende muss dann der User seine Unterlippe vorstuelpen und "BLBLBLBL"
machen, aber ich wollte doch nur eine Zahl uebertragen.... :-D
Vanye
Vanye R. schrieb: > Dein Posting zeigt sehr schoen warum das Internet in den letzten > 20Jahren mit immer hoeherer Geschwindigkeit gegen die Wand faehrt. Genau das tut es nicht, weil all die schönen Frameworks und Toolkits am Ende wieder auf einen gemeinsamen Nenner heruntercompiliert werden, HTTP, HTML5, ECMAScript. Es ist also überhaupt kein Problem, wenn es da viele Wahlmöglichkeiten gibt. Die stören sich nicht gegenseitig und es gibt keinen Zwang die regelmäßig zu wechseln. Genau wie bei Autos: Die Straßen sind kompatibel mit allen Modellen aller Hersteller. Nur weil Tesla ein neues Model rausbringt, werden die Straßen nicht plötzlich inkompatibel mit allen Vorgängermodellen und den KFZ anderer Hersteller.
Heute hat man für sowas einfach ein Web GUI. Irgendwelche lokalen GUIs sind komplett out und daneben.
Cyblord -. schrieb: > Heute hat man für sowas einfach ein Web GUI. Irgendwelche lokalen GUIs > sind komplett out und daneben. Auf Handys als App (vulgo: Fatclient) verpackt sind die total hip und trendy. Und jede dämliche Webanwendung bringt eigene Bedienelemente mit die sich von der nächsten Webanwendung maximal unterscheiden. Aber hey, niemand jucken die User.
:
Bearbeitet durch User
G. K. schrieb: > Cyblord -. schrieb: >> Heute hat man für sowas einfach ein Web GUI. Irgendwelche lokalen GUIs >> sind komplett out und daneben. > > Auf Handys als App (vulgo: Fatclient) verpackt sind die total hip und > trendy. Nur zeigen diese Apps am Ende oft nur die Webseite an. Bei Apps kommt zudem das automatische Update zum tragen. Lokale PC Anwendungen sind schwerer Up to date zu halten.
> Bei Apps kommt zudem das automatische Update zum tragen. Lokale PC > Anwendungen sind schwerer Up to date zu halten. Das will ich als Nutzer ja gar nicht. Sowas schaltet man immer als erstes ab. (oder blockiert die IP dazu .-) Schliesslich moechte ich bei Problemen wissen, "oh..stimmt ich hab ja gerade geupdatet" und nicht "hm...woran mag das jetzt liegen" Und dann gibt ja noch die Probleme mit Programmierern die ploetzlich wichtige Funktionen weglassen, oder einen in irgendwelche Kostenmodelle oder Cloud zwingen wollen. Daher muss man vor einem Update immer erst mal pruefen ob man eine Sicherheitskopie der aktuellen Version rumliegen hat. Nene, automagisch ist absolutes NoGo! Dafuer sind Programmierer einfach nicht vertrauenswuerdig genug. Vanye
Vanye R. schrieb: > Das will ich als Nutzer ja gar nicht. Sowas schaltet man immer > als erstes ab. (oder blockiert die IP dazu .-) Deshalb eben keine lokale GUI sondern Web.
Vanye R. schrieb: > Dein Posting zeigt sehr schoen warum das Internet in den letzten > 20Jahren mit immer hoeherer Geschwindigkeit gegen die Wand faehrt. > > Dreihundertdroelfig unterschiedliche Sprachen, gerne auch noch in > den unterschiedlichsten Versionen, je nach Mode jedes Jahr anders > die irgendwie undurchsichtig zusammenwirken.(oft auch mal nicht) Vanye R. schrieb: > Und dann gibt ja noch die Probleme mit Programmierern die ploetzlich > wichtige Funktionen weglassen, oder einen in irgendwelche Kostenmodelle > oder Cloud zwingen wollen. Hört, hört, der "Fachmann" spricht... Dreihundertdrölf... genau: HTML, ECMAScript und CSS. Vanye R. schrieb: >> Bei Apps kommt zudem das automatische Update zum tragen. Lokale PC >> Anwendungen sind schwerer Up to date zu halten. > > Das will ich als Nutzer ja gar nicht. Sowas schaltet man immer > als erstes ab. (oder blockiert die IP dazu .-) > [...] > Daher muss man vor einem Update immer erst mal pruefen ob man eine > Sicherheitskopie der aktuellen Version rumliegen hat. > > Nene, automagisch ist absolutes NoGo! Dafuer sind Programmierer einfach > nicht vertrauenswuerdig genug. Weißt Du, warum die Entwickler das so machen? Wegen nichtvertrauenswürdiger User wie Dir. Diese aktualisieren nämlich nie, wenn die von ihnen genutzten Funktionen der Software (in ihren Augen) zu funktionieren scheinen. Daß die Software im Hintergrund ein riesiges Sicherheitsproblem hat... Sowas "sagen die blöden Entwickler eh nur, um die armen Benutzer zum Update zu zwingen". Aber wehe, irgendein A-Loch ist in die Sicherheitslücke eingestiegen und hat die Nacktbilder vom Hund geklaut. Dann ist das Geschrei aber groß, dann sind die nichtvertrauenswürdigen Programmierer dann "(unfähig|dumm|verbrecherisch|<you-name-it>)" und überhaupt kann nicht sein, was nicht sein darf, nämlich daß man selbst das Problem verursacht hat, weil man ein besserwisserischer Vollidiot war und die Updatefunktionen nicht benutzt, ausgeschaltet... oder sogar gewaltsam erwürgt hat. Schwa^WNicht so besonders starke Köpfe wie Du sind der Grund dafür, warum sich Entwickler so verhalten und ihre Wahl so treffen, wie sie es tun. Wenn Dir das nicht paßt, benutz keine Computer, keine Tablets, und keine Handies mehr, denn am Ende gewinnen wir. Immer. Und zwar auch gegen die allergrößten Ignoranten.
Sowohl Web basierte Anwendungen als auch lokale Desktop Anwendungen haben zahlreiche Vor- und Nachteile. Dazu kommt, dass in den vergangenen 30 Jahren mehr Web- und GUI Frameworks entstanden sind, als normale Menschen begreifen können. Entsprechend ist es auch fast unmöglich, eine wirklich vernünftige Fakten basierte Entscheidung zu treffen. Man muss heute schon zufrieden sein, wenn es einigermaßen Funktioniert. Ich Entwickle in dem Umfeld seit Ende der 90er Jahre.
Ein T. schrieb: > Daß die Software im Hintergrund ein riesiges Sicherheitsproblem hat Welcher Idiot bringt denn Software mit Sicherheitsproblemen in Umlauf? LG, Sebastian
Sebastian W. schrieb: > Welcher Idiot bringt denn Software mit Sicherheitsproblemen in Umlauf? Praktisch jeder, irgendwie. Jedenfalls, sobald die Software irgendwelche Netzwerkaktivitäten entwickeln kann und irgendwelche von außen kommende Daten verarbeiten soll. Da ist nicht nur eine Firma wie Microsoft ganz groß drin. Software, die garantiert niemals irgendein Sicherheitsproblem haben kann, ist entweder trivial oder aber läuft in einem Umfeld, das alle denkbaren Angriffsvektoren fernhält.
Warum muss es denn auf den PC? Bildschirm am Raspi reicht nicht?
Sebastian W. schrieb: > Ein T. schrieb: >> Daß die Software im Hintergrund ein riesiges Sicherheitsproblem hat > > Welcher Idiot bringt denn Software mit Sicherheitsproblemen in Umlauf? William Henry Gates III., KBE.
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.