Hallo, ich habe immer wieder mal Anwendungen, bei denen ich ein HD44780-kompatibles Display an einem AVR betreibe. Es sollen mehrere Seiten (nur eine Ebene) dargestellt werden. Es sollen Messwerte angezeigt werden und manche Werte (Parameter) sollen editierbar sein. Ich habe da schon mal was "zu Fuß" erstellt. Am Ende war es aber dann doch eher umständlich (switch-case je nachdem welche Seite dargestellt wurde, welche Werte "fest" sind, welche editierbar sind usw.) Es gibt die Tasten "Auf" und "Ab" und eine für Edit/Bestätigen. Mit Auf und Ab wird zeilenweise gesprungen, ggf. auf die nächste Seite. Wie würdet ihr das machen? Gibt es vielleicht eine Library dafür? Gibt es irgendwo Architektur-Vorschläge? Danke. Third Eye
:
Bearbeitet durch User
Lerne Programmieren. Denke dir passenden Datenstrukturen aus. Implementiere diese.
Third E. schrieb: > Wie würdet ihr das machen Das https://www.ebay.de/itm/387340096847 nutzt einen einzigen Knopf dafür, lang und kurz drücken und abwarten, geht auch. Diese Ding hat 3 Tasten und erlaubt Eingabe von Schritten ganzer Ablaufsequenzen https://www.ebay.de/itm/115340606301 Entscheidend bei der Programmierung ist immer ein 'dont mode me in' also nur 1 Stelle im Programm an der die Tasten abgefragt werden, nur eine state machine um sie auszuwerten, man muss halt per Variablen wissen was gerade dargestellt wird. Simple Menüs haben nur 1 Ebene, mit 'vorwärts' blättert man also alle durch, nach dem letzten kommt der erste. Komplexere Menüs sind hierarchisch, man muss in Ebenen eintauchen und wieder raus, das ergibt auch fast von selbst einen Weg bis zum Wert und dessen Einstellmöglichkeit Ziffer für Ziffer. Fertig kenne ich flexiblen code nicht.
Third E. schrieb: > Gibt es irgendwo Architektur-Vorschläge? Ich denke nicht, dass es da eine ultimative Lösung gibt. Ich habe da schon die wildesten Implementationen gesehen mit Funktionspointern und was weiss ich was; aber je ausgeklügelter, desto weniger wartbar wird das Ganze, wenn plötzlich Anforderungen kommen, an welche nicht gedacht wurde oder die einfach nicht ins Konzept passen. Meiner Meinung nach also die Implementation möglichst einfach und flexibel halten, mit switch/case für jede Ansicht, das ist völlig ok. Schlussendlich ist es den Anwendern egal wie elegant es implementiert ist oder nicht, es muss einfach gut funktionieren.
Third E. schrieb: > Ich habe da schon mal was "zu Fuß" erstellt. Am Ende war es aber dann > doch eher umständlich (switch-case je nachdem welche Seite dargestellt > wurde, welche Werte "fest" sind, welche editierbar sind usw.) Bei unter 10 Bildschirmen ist eine Switch-Abfrage für die Darstellung eines bestimmten Bildschirms völlig OK – das nutze ich z.B. bei Bildschirmen mit dem MAX7219. Man muss nicht alles unnötig kompliziert machen, wenn es einfach geht und von der Performance her unproblematisch ist; und bei 99% der Fälle mit einfachen Bildschirmmenüs spielt die Performance überhaupt keine Rolle. Eine universelle Lösung für alles wird man eh nicht machen können und nach so einer Schablone krampfhaft zu suchen sollte man am besten auch nicht, denn es ändert sich immer etwas von Fall zu Fall. Eine gewisse Programm-Schablone für das nächste eigene Projekt kann man daraus später aber fast immer ableiten – wichtig ist nur, dass man sich in dem eigenen 'Programm-Chaos' nach kurzer Einlesephase zurechtfindet, also das ganze Geschriebene nach und nach gut strukturiert und kommentiert, um am Ende ein brauchbares Muster daraus ableiten zu können. Auf fremde Programme verzichte ich grundsätzlich immer, da ich das Geschriebene immer zu 100% verstehen möchte und das bei fremder Software oft nicht so einfach ist, zu durchschauen, was das Programm macht. Oft ist es auch so, dass die genaue Einarbeitung in den fremden Code in der Regel deutlich mehr Zeit erfordert als es selbst zu schreiben. Gewisse Techniken und Tricks abschauen kann man sich aber immer – verboten ist es nicht und etwas lernen kann man dabei manchmal auch noch, im Netz gibt es aber auch viel dummes Zeug, insofern sollte man beim Abschauen immer Vorsicht walten lassen und Skepsis an den Tag legen.
Keine Ahnung ob das produktiv brauchbar ist, als erste Anregung aber sicher nicht verkehrt: https://www.mikrocontroller.net/articles/Men%C3%BC https://www.mikrocontroller.net/articles/YaMen%C3%BC
Wenn es das fertig zu kaufen gibt und der Preis gerechtfertig ist und im bezahlbaren Bereich liegt, ist es besser was zu kaufen. Da bin ich ganz bei Michael. Lebenszeit ist sehr kostbar. Dann kann man auch Code "klauen" und anpassen. Im Grunde ist das ja schon bei einer Bibliothek schon so. Aber manchmal muss man halt auch selbst tippen was das Zeug hält. Meist mit der Erkenntnis, dass man schon wieder viel zu viel vergessen hat. Und dann, wenn man fertig ist, gelobt man, dass man doch wieder vieles selbst programmieren will und schon ist da wieder ein Code der fast passt ...
Ich stand auch vor dem Problem und hatte mir folgende Arduino Library mal angeschaut, aber habe es nicht weiterverfolgt, da Projekt pausiert: https://github.com/neu-rah/ArduinoMenu Ich meine es müssten HD44780 Displays unterstützt werden.
Timo N. schrieb: > Ich stand auch vor dem Problem und hatte mir folgende Arduino Library > mal angeschaut, aber habe es nicht weiterverfolgt, da Projekt pausiert: > https://github.com/neu-rah/ArduinoMenu > > Ich meine es müssten HD44780 Displays unterstützt werden. Warum fällt es euch Arduinos so schwer einfach mal was selbst zu entwickeln?
:
Bearbeitet durch User
Cyblord -. schrieb: > Warum fällt es euch Arduinos so schwer einfach mal was selbst zu > entwickeln? Euch Arduinos? Es fällt mir nur schwer, weil es Zeit kostet. Das ist alles. Es gibt so einen Spruch: Man muss das Rad nicht neu erfinden. Warum fällt es dir so schwer den PC, auf dem du das geschrieben hast selbst zu entwickeln? Die Platinen selbst zu designen und herzustellen, das Betriebssystem selbst zu schreiben, usw usw. Entwicklung hat immer schon auf Basis anderer, vorheriger Entwicklung stattgefunden. Wer meint etwas, was schon vorhanden ist selbst machen zu müssen, der hat: a) zu viel Zeit oder b) will nur etwas lernen oder c) ist mit dem Vorhandenen nicht zufrieden. Wenn b und c ausscheiden, weil es im gegebenen Fall nicht zutrifft, dem ist nicht zu helfen.
@Cyblord: Das mit den Arduinos ist wohl eine rhetorische Frage oder? Naja, weil es liegt meiner Meinung nach auf der Hand. Arduino-Lösungen sind äußerst bequem und führen einen zumeist ohne große Anstrengung und Aufwand zum Ziel. Den viel steinigeren Weg, den die Leute in der Vergangenheit auf sich genommen haben, will heutzutage fast keiner mehr gehen. Das soll aber überhaupt kein Vorwurf sein. Denn man muss sich dann immer selbst die Frage stellen, wäre ich in der heutigen Zeit nicht auch so? Die Zeit ist extrem schnelllebig geworden. Mich wundert es ja eigentlich, dass heute von Studenten noch verlangt wird, ganze Bücher zu lernen, wie es bei mir der Fall war. Oder ist dies eh bereits anders? Und den Groll der alten Generation auf die Arduinos kann ich auch nachvollziehen. Denn da gibt es nun eine Generation, die öfters eben nicht den harten Weg geht wie sie selbst und scheinbar nicht mehr so bereit ist, sich über lange Zeit anzustrengen und einem Ziel zu folgen. Da spielt mMn auch etwas Neid mit und man will ihnen den nun leichter erzielten Erfolg nicht so wirklich gönnen. Ich persönlich bin zum Beispiel mit Sicherheit alles andere als ein guter Programmierer und greife ebenfalls eigentlich fast immer auf einen Arduino zurück. Ich versuche aber wenigstens einigermaßen kreativ die Fertiglösungen zu kombinieren/adaptieren bzw. Zu etwas neuem zu vereinen.
Timo N. schrieb: > c) ist mit dem Vorhandenen nicht zufrieden. Gilt das nicht mittlerweile für fast alles ;-) @third-eye Dazu gibt es unzählige Lösungen, die Frage ist welche würde Dir gefallen?
Timo N. schrieb: > Euch Arduinos? > Es fällt mir nur schwer, weil es Zeit kostet. Das ist alles. > > Es gibt so einen Spruch: Man muss das Rad nicht neu erfinden. Ja nur geht es hier ja genau da drum dass der TE eben nicht mal schnell was fertiges findet. Und dann liegt es auf der Hand das selbst zu machen. Und nicht 4 Monate in Foren rumzufragen. Entwickler sollten entwickeln. Zumindest wenn es nötig wird. Christoph E. schrieb: > Und den Groll der alten Generation auf die Arduinos kann ich auch > nachvollziehen. Denn da gibt es nun eine Generation, die öfters eben > nicht den harten Weg geht wie sie selbst und scheinbar nicht mehr so > bereit ist, sich über lange Zeit anzustrengen und einem Ziel zu folgen. > Da spielt mMn auch etwas Neid mit und man will ihnen den nun leichter > erzielten Erfolg nicht so wirklich gönnen. Diese Prämisse ist völliger Unsinn. Vor allem hier kommt der TE ja nicht mal zum Ziel. ICH kann mir einfach eine Multi-Level Menülib schreiben wenn ich das brauche. Der TE offensichtlich nicht. Kaum ein Arduino-Kasper kann ja, trotz vermeintlicher Einfachheit, irgendwas sinnvolles damit tun, was über die Example Programm Komplexität rausgeht. Neid auf was? Ich hatte nie Mühle oder Qual irgendwas zu entwickeln und moderne Microcontroller machen uns allen das Leben sehr leicht. Wenn ich SELBST entwickeln und VERSTEHEN schrecklich finden würde, wäre ich Gärtner geworden. Oder Schlitzeklopfer aufm Bau. Bei Arduinos dominiert bei mir eher Mitleid. Weil die Nutzer selbst so wenig können und das merken die dann auch sehr bald. Und trotz der vermeintlichen Einfachheit klappt es einfach nie wirklich und Fehlersuche geht dann auch nicht, weil kein Wissen. Das muss frustrierend sein. Und der TE hat immer noch kein Menü. Nicht weil er nicht will, weil er weiß er kann gar nicht selbst. Er hat nur eine Chance: Jemand muss es gemacht haben und ihm geben. Mehr bleibt ihm nicht.
:
Bearbeitet durch User
Beitrag #7833942 wurde vom Autor gelöscht.
Christoph E. schrieb: > Die Zeit ist extrem schnelllebig geworden. Mich wundert es ja > eigentlich, dass heute von Studenten noch verlangt wird, ganze Bücher zu > lernen, wie es bei mir der Fall war. Oder ist dies eh bereits anders? Keine Ahnung. Wenn aber den Studenten heutzutage keine Grundlagen mehr abverlangt werden, dann frage ich mich, wer denn zukuenftig mal all die tollen Werkzeuge erstellen soll, die diese Spezialisten spaeter mal verwenden wollen. Christoph E. schrieb: > Da spielt mMn auch etwas Neid mit und man will ihnen den nun leichter > erzielten Erfolg nicht so wirklich gönnen. Hmm, also mein Erfolgserlebnis bekomme ich dadurch dass ich etwas eigenes erschaffen habe. Irgendetwas zu kopieren mag zwar auch zum Ziel fueheren, aber stolz bin ich auf so etwas nicht. Ich koennte ja auch neidisch auf alle Reichen sein, die sich so einen Kram einfach kaufen, anstatt es selbst zu bauen.
:
Bearbeitet durch User
Andreas B. schrieb: > Hmm, also mein Erfolgserlebnis bekomme ich dadurch dass ich etwas > eigenes erschaffen habe. Irgendetwas zu kopieren mag zwar auch zum Ziel > fueheren, aber stolz bin ich auf so etwas nicht. Hmm, also mein Erfolgserlebnis bekomme ich dadurch, dass ich für eine gegebene Aufgabe eine gute Lösung gefunden habe. Je schneller und aufwandsärmer desto besser. Das Rad neu zu erfinden mag zwar irgendwann auch zum Ziel führen, aber stolz bin ich auf so etwas nicht.
Tja, da sieht man, daß sich die Menschen halt unterscheiden. Stolz bin ich nur auf selbst geleistetes. Und irgend etwas zusammenzustöpseln, gehört halt nicht dazu. Klar kommt man damit (oft) schneller zu Ziel, aber die Frage bleibt bei einem Hobby: Was ist wichtiger: der Weg oder das Ziel? Und auch wenn es beruflich ist: Zusammenstöpseln und abgehakt, ok. Aber stolz darauf zu sein?
@Cyblord: Full Ack .... was noch dazu kommt, nicht nur die Programme, ääähh Sketches 😁, sind zusammen geschustert, auch die Schaltung selber, denn ohne Shields geht garnichts. Was evtl. geht, ist eine Platine malen, die alle Shields und den Arduino zusammenbacken.
ich hab so etwas mal gemacht: Beitrag "Menu zur Einstellung RTC per Fernbedienung" Man muss ja öfters irgendwelche Einstellungen auf dem uc vornehmen. Geht einfacher mit einer seriellen Verbindung zum pc.
Andreas B. schrieb: > Stolz bin ich nur auf selbst geleistetes Und ab wann ist es "selbst geleistet"? Transistoren selbst entworfen oder fertig gekauft? Integrierte Schaltkreise selbst entworfen oder fertig gekauft? Mikrocontroller selbst entworfen oder fertig gekauft? Assembler zur Hilfe genommen oder direkt in Hex geschrieben? Hochsprache zur Hilfe genommen oder direkt in Assembler geschrieben? Fertige Library (zB C Standard Library) genommen oder printf zu Fuß programmiert? Diese Fragen waren alle rhetorisch. Und jetzt frage dich mal, warum du ausgerechnet hier aufhörst und nicht eine weitere fertige Schicht dazu nimmst, so es sie gibt.
Klaus schrieb: > Und ab wann ist es "selbst geleistet"? Wenn man irgendwelche Leistungen dafuer erbracht hat. Und dazu gehoert eben nicht kopieren oder in Foren nach fertigen Loesungen zu fragen. Klaus schrieb: > Diese Fragen waren alle rhetorisch. Und jetzt frage dich mal, warum du > ausgerechnet hier aufhörst und nicht eine weitere fertige Schicht dazu > nimmst, so es sie gibt. Weil man Transistoren nicht einfach so selber baut. Ebenso IC's. das hat eben nichts mit Brain zu tun, sondern mit dem Equipment das man dazu braucht. SW hingegen ist auch fuer jemanden, der sich nicht alles leisten kann, erstellbar. In Assembler schreibe ich im uebrigen auch, wenn es notwendig ist (kleine Controller).
:
Bearbeitet durch User
Andreas B. schrieb: > Wenn man irgendwelche Leistungen dafuer erbracht hat. Und dazu gehoert > eben nicht kopieren oder in Foren nach fertigen Loesungen zu fragen. Doch, das gehört eben sehr wohl dazu. Jemand, der durch suchen, anpassen und zusammenfügen von exisitierenden Teillösungen etwas Neues erschafft, das seinen Anforderungen genügt, hat etwas geleistet. Beispiel: Wenn es eine Funktion zur Ausgabe von zur Laufzeit berechneten Strings gibt, dann nutze ich die. Und du vermutlich auch. Das Beispiel printf habe ich oben schon genannt. Wenn es eine Funktion zur Ausgabe eines Menüs und Auswählen eines Menüpunktes gibt, dann nutze ich die. Du nicht, warum auch immer.
:
Bearbeitet durch User
Ontopic: Johnny B. schrieb: > Ich habe da > schon die wildesten Implementationen gesehen mit Funktionspointern und > was weiss ich was; aber je ausgeklügelter, desto weniger wartbar wird > das Ganze, wenn plötzlich Anforderungen kommen, an welche nicht gedacht > wurde oder die einfach nicht ins Konzept passen. Abstraktion ist immer wichtig. Ich würde (und habe in einem ähnlichen Fall schon) Funktionspointer verwendet, um Handler für den Tastendruck und langen Tastendruck zuzuweisen. So wird das ganze eventbasiert und man braucht weder Switch-Orgien noch Zustandsautomaten. Der Vorteil dabei ist, dass man jeden Tastendruckhandler getrennt implementiert und bei neuen Einträgen nicht in den Swicth-Listen rumfuhrwerken muss und potentiell an unvorhergesehenen Stellen Fehler einbaut. Ich hab es dann auch so gemacht, dass beim Sprung im Menü über eine Funktion alle Tasten-Handler übergeben werden, die nichtbenötigten eben mit einem Null-Pointer, um sicher zu sein, dass man nicht noch Handler aus vorigen Menüebenen mitschleppt.
Klaus schrieb: > Wenn es eine Funktion zur Ausgabe eines Menüs und Auswählen eines > Menüpunktes gibt, dann nutze ich die. Du nicht, warum auch immer. wenn sie bei mir auf dem Schreibtisch liegt oder schnell gefunden ist, dann ja. Ansonsten schreibe ich sie eben selbst. Und wenn ich das nicht kann, lerne ich es.
Klaus schrieb: > Wenn es eine Funktion zur Ausgabe eines Menüs und Auswählen eines > Menüpunktes gibt, dann nutze ich die. Du nicht, warum auch immer. Hast du die Lib schon hier verlinkt? der TE sucht ja zufällig eine. Immer her damit.
:
Bearbeitet durch User
Cyblord -. schrieb: > Klaus schrieb: >> Wenn es eine Funktion zur Ausgabe eines Menüs und Auswählen eines >> Menüpunktes gibt, dann nutze ich die. Du nicht, warum auch immer. > > Hast du die Lib schon hier verlinkt? der TE sucht ja zufällig eine. > Immer her damit. Konditionalsätze sinnerfassend zu verarbeiten gelingt nicht jedem.
Klaus schrieb: > Cyblord -. schrieb: >> Klaus schrieb: >>> Wenn es eine Funktion zur Ausgabe eines Menüs und Auswählen eines >>> Menüpunktes gibt, dann nutze ich die. Du nicht, warum auch immer. >> >> Hast du die Lib schon hier verlinkt? der TE sucht ja zufällig eine. >> Immer her damit. > > Konditionalsätze sinnerfassend zu verarbeiten gelingt nicht jedem. Der Punkt ist doch gerade dass er eben keine passende lib findet. Deshalb einfach selbst machen. Da zieht halt das Deppen-Argument vom "Rad neu erfinden" nicht. Du bringst es trotzdem. Warum auch immer. Aber wie soll er? Wenn man keine Erfahrung im selber entwickeln hat, geht das eben auch nicht. Darum ist diese ganze Arduino-Sache eine Sackgasse. Man baut kein Wissen auf um da raus zu kommen und mehr möglich machen zu können als fertige libs hergeben. Man kann nicht 20 Jahre den Aufzug nehmen und dann eines Tages, wenn der kaputt ist, das Kletterzeug rausholen und raufklettern. Geht nicht.
:
Bearbeitet durch User
https://www.arduinolibraries.info/categories/display oder auf der Site nach 'Menu' suchen. Da gibt es reichlich. https://github.com/VasilKalchev/LiquidMenu https://github.com/Jomelo/LCDMenuLib https://github.com/Jomelo/LCDMenuLib2 sieht alles gut aus. Es gibt halt Leute für die ist die µC Programmierung nicht Lebenszweck sondern Mittel zum Zweck. Nicht jeder hat die Ideen alles generisch mit Funktionszeigern zu realisieren, da ist die Arroganz derjenigen die hier viel Zeit in C/C++/Asm Programmierung stecken völlig überflüssig.
J. S. schrieb: > Es gibt halt Leute für die ist die µC Programmierung nicht Lebenszweck > sondern Mittel zum Zweck. Nicht jeder hat die Ideen alles generisch mit > Funktionszeigern zu realisieren, da ist die Arroganz derjenigen die hier > viel Zeit in C/C++/Asm Programmierung stecken völlig überflüssig. Es würde sich um Arroganz handeln WENN man ohne Ahnung und Wissen komplexe Probleme lösen könnte. Aber der TE kann es nicht, sonst würde er hier nicht schreiben. Deshalb handelt es sich um Erfahrung. Vielleicht wissen diejenigen die viel Zeit in C/C++/Asm Programmierung stecken darüber ein paar Dinge einfach besser. Vielleicht haben die Recht? Wer weiß!
:
Bearbeitet durch User
Thorsten M. schrieb: > Ich würde (und habe in einem ähnlichen Fall schon) Funktionspointer > verwendet, um Handler für den Tastendruck und langen Tastendruck > zuzuweisen. So wird das ganze eventbasiert und man braucht weder > Switch-Orgien noch Zustandsautomaten. Der Vorteil dabei ist, dass man > jeden Tastendruckhandler getrennt implementiert und bei neuen Einträgen > nicht in den Swicth-Listen rumfuhrwerken muss und potentiell an > unvorhergesehenen Stellen Fehler einbaut. Klingt wie der direkte Weg in die Hölle überkomplexer Software. Nehmen wir nur 4 Tasten, up down left right. Nehmen wir simple Zahleneingabe 0000 bis 9999. Dann macht up +1, down -1 und right nächste Stelle von 1-4, wobei es nach Stelle 4 den Wert speichert und left steht mal für Abbruch, nicht 1 Stelle zurück. Da du keine Zustände 'wir sind auf Ziffer 2' speichern willst brauchen wir 13 Tastenhandler.
1 | upondigit1 digit[0]++; |
2 | downondigit1 digit[0]--; |
3 | rightondigit1 newhandler(upondigit2,downondigit2,rightondigit2,leftcancel); |
4 | upondigit2 digit[1]++; |
5 | downondigit12 digit[1]--; |
6 | rightondigit12 newhandler(upondigit3,downondigit3,rightondigit3,leftcancel); |
7 | upondigit3 digit[2]++; |
8 | downondigit3 digit[2]--; |
9 | rightondigit3 newhandler(upondigit2,downondigit2,rightondigit2,leftcancel); |
10 | upondigit13 digit[3]++; |
11 | downondigit3 digit[3]--; |
12 | rightondigit3 value1=atoi(digit); newhandler(uponmenuvalue1,downonmenuvslze1,rightonmenuvalue1,NULL); |
13 | leftcancel
|
und natürlich den ganzen code der das Display und den Cursor updated. Natürlich hast du eine state maschine, natürlich hast du einen Zustand, bloss nicht als einfach zugängliche Zahlen aktuellestelle=2 aktuellervalue=1 sondern kreuz und quer versteckt in Funktionspointern. Es ist so viel einfacher, ein case zu einem switch hinzuzufügen.
:
Bearbeitet durch User
Cyblord -. schrieb: > Da zieht halt das Deppen-Argument vom > "Rad neu erfinden" nicht. Oben ist eine Lib verlinkt, die ich nicht kenne und deren Eignung ich nicht einschätzen kann. Wenn ich aber vor der Aufgabe stünde würde ich die Lib auf Eignung prüfen und ggf. verwenden. Cyblords lassen sich dagegen lieber von Hasswörtern triggern und hauen ein pauschales Cyblord -. schrieb: > Warum fällt es euch Arduinos so schwer einfach mal was selbst zu > entwickeln? raus. Kann man machen. Ist halt deppert.
Klaus schrieb: > Cyblords lassen sich dagegen lieber von Hasswörtern triggern und hauen > ein pauschales > > Cyblord -. schrieb: >> Warum fällt es euch Arduinos so schwer einfach mal was selbst zu >> entwickeln? Daran ist nichts falsch. Darüber meckern immer nur die Versager die es nicht können. Die anderen machen einfach. Das mit dem selber entwickeln war ein Gratis-Tipp. Annehmen oder es lassen. So wie mit dem Hund und dem Knochen.
:
Bearbeitet durch User
Michael B. schrieb: > Es ist so viel einfacher, ein case zu einem switch hinzuzufügen. Allerdings kannst du mit Funktionspointern eben eine komplett in sich abgeschlossene Lib machen die ein Nutzer nicht anpassen muss. Die du sogar kompiliert ausliefern kannst. Dein Code ist im User Code verwoben und kann nicht mehr davon abgekapselt werden. Und mit einer abgeschlossene lib kannst du ein Problem wirklich nur EINMAL lösen und immer wieder für verschiedene Projekte verwenden. Das ist der große Vorteil von Funktionspointern. Allerdings muss kein Anfänger erst mal ein Problem mit Funktionspointern lösen es würde reichen erst mal ein halbwegs gutes Modul zu schreiben mit halbwegs guten Schnittstellen. Da wäre erst mal Aufgabe und Erfolg genug. Keine Frage.
:
Bearbeitet durch User
Cyblord -. schrieb: > Dein Code ist im User Code verwoben und kann nicht mehr davon > abgekapselt werden. Mein code IST der user-code und tut was, nämlich genau das was getan werden muss, ohne overhead der nichts tut sondern nur 'abkapselt' (aka den Überblick behindert). Du weisst übrigens gar nicht wie mein code wäre. Aber du heisst auch nicht Torsten.
Michael B. schrieb: > Cyblord -. schrieb: >> Dein Code ist im User Code verwoben und kann nicht mehr davon >> abgekapselt werden. > > Mein code IST der user-code und tut was, nämlich genau das was getan > werden muss, ohne overhead der nichts tut sondern nur 'abkapselt' (aka > den Überblick behindert). Ja das ist auch ok. Aber damit löst man eben das problem jedes mal wieder neu. Irgendwann will man evt. mal ein lib. Und dann geht das so nicht mehr. > Du weisst übrigens gar nicht wie mein code wäre. Aber du heisst auch > nicht Torsten. Ich habe nur den Code kommentiert den du gepostet hast. Abstraktion ist die eine Lösung um Komplexität in den Griff zu bekommen. "Überblick" bedeutet bei dir nur, dass man immer jedes Detail des Code im Blick haben MUSS. Eine gute Abstraktion sorgt dafür dass man nur wohldefinierte Schnittstellen im Blick haben muss, der Rest dahinter aber dann einfach funktioniert. Wer denkt, das wäre kompliziert hat Abstraktion nicht verstanden. Weil es das eine Tool ist, um überhaupt Komplexität zu meistern.
:
Bearbeitet durch User
Cyblord -. schrieb: > Darüber meckern immer nur die Versager die es > nicht können. Du bist ein arrogantes Arschloch. Aber das wusstest Du ja schon.
:
Bearbeitet durch User
Klaus schrieb: > Cyblord -. schrieb: >> Darüber meckern immer nur die Versager die es >> nicht können. > > Du bist ein arrogantes Arschloch. Aber das wusstest Du ja schon. Du hättest die Chance gehabt dich jetzt mal sachlich am Thema zu beteiligen. Aber du wählst immer den weg der persönlichen Beleidigung.
Cyblord -. schrieb: > Aber du wählst immer den weg der persönlichen Beleidigung Der beleidigt nur den, der es verdient. Du dagegen pauschal unpersönlich jene, von denen Du glaubst, dass Du ihnen überlegen bist. Also quasi alle.
Klaus schrieb: > Cyblord -. schrieb: >> Aber du wählst immer den weg der persönlichen Beleidigung > > Der beleidigt nur den, der es verdient. > Du dagegen pauschal unpersönlich jene, von denen Du glaubst, dass Du > ihnen überlegen bist. Also quasi alle. Schade dass du dem Thread keine Chance gibst in die Sachlichkeit abzudriften. Dein Hass ist zu stark. Vielleicht liegt es daran dass ich meine Meinung sachlich begründen kann und das auch tue. Hast du deine on topic Beiträge in diesem Thread mal gezählt? Es sind exakt 0. Wie wär es wenn du deinen Hass per PN weiter kultivierst und hier eine sachliche Diskussion einkehren lässt? Deal?
:
Bearbeitet durch User
Cyblord -. schrieb: > Wie wär es wenn du deinen Hass per PN weiter kultivierst und hier eine > sachliche Diskussion einkehren lässt? Deal? In dem Augenblick, wo Du deine Arroganz und deinen Hass auf alles und jeden der das Wort Arduino in den Mund nimmt, ablegst: > Lerne Programmieren. > Warum fällt es euch Arduinos so schwer einfach mal was selbst zu > entwickeln? > Kaum ein Arduino-Kasper > Bei Arduinos dominiert bei mir eher Mitleid. > Weil die Nutzer selbst so wenig können > Darüber meckern immer nur die Versager die es > nicht können. lege ich meine Verachtung für dich ab. Deal.
:
Bearbeitet durch User
Klaus schrieb: > lege ich meine Verachtung für dich ab. Deal. Du darfst deine Verachtung behalten aber du schädigst mit deinem Verhalten hier den gesamten Thread. Lerne deine persönlichen Animositäten in anderem Rahmen auszutragen wo es passender ist. Du hast immer noch keinen einzigen sachlichen On Topic Beitrag in diesem Thread geleistet. Fange doch mal damit an! Ich zumindest werde deine Ausbrüche hier nicht mehr kommentieren und nicht mehr darauf eingehen.
:
Bearbeitet durch User
Ich würde alle Parameter in einem Array organisieren, wo man dann mit up/down den aktiven Parameter auswählt. Das hilft dann auch bei einem einheitlichen Layout. Man nimmt sich also zuerst mal Papier und Stift und malt sich damit alle Darstellungsvarianten auf. Die Einträge in dem Array enthalten nur die Unterschiede, z.B.: Parameteradresse, Name, Format, Einheit, Min, Max, Gain, Offset. Man hat dann nur noch eine einzige Funktion zu schreiben und zu testen, die damit das Darstellen bzw. Einstellen steuert. Mit switch/case hat man nicht nur Unmengen an Schreibarbeit, es können sich auch leicht Fehler einschleichen (Texte stehen an falscher Stelle, überschreiben andere Anzeigen, lassen Reste stehen usw.).
Third E. schrieb: > Gibt es irgendwo Architektur-Vorschläge? Aus meiner Sicht gibt es zwei ganz grobe Vorgehensweisen, eine lightweight mit viel mehr Implementierung pro Seite und die andere eher komplizierter aber besser. Gemeinsam: - Eine Seite wird durch eine Struktur repräsentiert. - Alle Seiten werden einfach in einem statischen Array gehalten. Keine dynamaischen verlinkten Listen. 1.) Eine Seitenstruktur enthält im Prinzip nur einen Handler für die Seite, z.B. in Form eines Funktionszeigers. Dieser erwartet eine Funktion welche den gesamten String für die Seite zurückgibt. Evt. Seitenindex als Parameter. An allgemeiner Implementierung bleibt dann nur das durchlaufen mittels Up/Down und bei jeder Seite wird nur deren Handler aufgerufen und dessen Rückgabestring stumpf angezeigt. D.h. alle Parameter Einstellgeschichten müssen trotzdem einzeln implementiert werden. oder: 2.) Eine Seitenstruktur enthält: - Info ob die Seite einen Einstellwert enthält oder nur was anzeigt. - Zeiger auf den Einstellwert, wenn die Seite einen solchen Enthält. - Handler (Funktionszeiger) auf eine Funktion welche den Text liefert. Als Parameter evt. der aktuelle Einstellwert. Dann kann diese Funktion auch die Anzeige und Formatierung übernehmen. Es muss in diesem Fall nur einmal die ganze Logik zum Einstellen des Wertes implementiert werden. Vorausgesetzt der Wert hat immer den gleichen Datentyp. Sonst wirds komplizierter.
:
Bearbeitet durch User
Third E. schrieb: > Es gibt die Tasten "Auf" und "Ab" und eine für Edit/Bestätigen. Dann muß man sich einen Ablauf ausdenken, um die einzelnen Digits einer Zahl setzen zu können. Z.B. mit langem Druck von "Edit" wechselt man in den Setzmodus und das erste Digit blinkt. "Edit" kurz drücken schaltet ein Digit weiter. Langes "Edit" speichert dann den neuen Wert. "Auf" und "Ab" zusammen verwirft die Eingabe, der vorherige Wert bleibt erhalten.
Ich denke Peda hat einen wichtigen Punkt angesprochen: Vor der Implementierung kommt die Planung: Was GENAU soll möglich sein. Was ist nicht nötig. Das ist auch bald schon der schwierigste Teil. Und sowas trainiert man eben auch durch das Selbermachen.
:
Bearbeitet durch User
Cyblord -. schrieb: > Aber wie soll er? Wenn man keine Erfahrung im selber entwickeln hat, > geht das eben auch nicht. Darum ist diese ganze Arduino-Sache eine > Sackgasse. Na ja ... Wer behauptet denn, dass man dabei bleiben muss? Ich hätte den ganzen Scheiß in die Ecke geschmissen, vor allem nach dem ersten Assembler Buch, das so grottenschlecht für meinen Geschmack war, dass ich nichts daraus gelernt hätte. Vor allem in der wenigen Freizeit. Und die ganzen Libs, die es für Arduino gibt, die haben sich auch nicht selbst geschrieben. Ich war ziemlich raus die letzten 12 Jahre und als ich nun den Bremsentester bauen wollte, war ich erstaunt wie sehr das alles gewachsen ist. Ich glaube du stehst mit deiner Meinung (die sich wohl kaum in den Jahren geändert hat) ziemlich alleine da. Alleine was da mittlerweile an Hardware unterstützt wird. Dein Alleinstellungsmerkmal, dass du zu einer kleinen Elite gehörst, die so was kann, die ist schon lange vorbei. Zum Glück! Was wäre Steve Wozniak ohne Steve Jobs gewesen. Durch Arduino können vielleicht Entwicklungen ihren Anfang finden, die so nie entstanden wären. Und dem Controller siehst du es von außen nicht an, ob du oder ein Arduino Jünger den programmiert hat. Nicht einmal, dass er vielleicht das meiste zusammen kopiert hat. Wenn alles so funktioniert, wie es soll, ist doch alles gut. Und kommst du jetzt mit dem Speicherhunger, die Hersteller werden dann auch den bedienen. Siehe es endlich ein, du gehörst zu einer aussterbenden Art.
Frank O. schrieb: > Wer behauptet denn, dass man dabei bleiben muss? Das ist ja grade die Krux an einer Sackgasse. Man kommt nicht mehr raus.
Michael B. schrieb: > Klingt wie der direkte Weg in die Hölle überkomplexer Software. > > Nehmen wir nur 4 Tasten, up down left right. Nehmen wir simple > Zahleneingabe 0000 bis 9999. > Dann macht up +1, down -1 und right nächste Stelle von 1-4, wobei es > nach Stelle 4 den Wert speichert und left steht mal für Abbruch, nicht 1 > Stelle zurück. > > Da du keine Zustände 'wir sind auf Ziffer 2' speichern willst brauchen > wir 13 Tastenhandler. > [...] Das hast du falsch verstanden, natürlich speichert man Zustände. Und natürlich ist es sinnvoll die ganze Zahleneingabe wie eine Darstellungsseite zu behandeln. Selbst Parameterlisten wird man zusammenfassen und über ein Array o.ä. abbilden. Für die Parameterauswahl hat man dann einen eigenen Satz Tastenhandler und für die Wertauswahl einen getrennten. Jetzt hat man noch andere Menüpunkte, bspw. Parameter mit boolschem Wert, die werden dann getrennt implementiert mit ihren Handlern. Packt man das in Switch-Case-Listen, ist die Chance groß bei einer kleinen Änderung sich bestehende Menüpunkte zu zerschießen. Ich würde behaupten, wer den einfachen Ansatz mit einer zentralen hartcodierten Tastenabfrage wählt, wird so Dinge wie einen langen Tastendruck nicht vorsehen (Ausnahmen bestätigen die Regel), weil der Code dann schnell so unübersichtlich wird, dass eine funktionierende Implementierung schwieriger wird wie eine saubere Abstraktion. Und wenn man letztere schon nicht leisten kann.. > Natürlich hast du eine state maschine, natürlich hast du einen Zustand, > bloss nicht als einfach zugängliche Zahlen aktuellestelle=2 > aktuellervalue=1 sondern kreuz und quer versteckt in Funktionspointern. Die Zahlen helfen halt keinem, eine kleine Änderung, ein Eintrag herausnehmen, und man muss neu durchnummeriern. Erschwerend kommt hinzu, dass Menüs in der Regel baumförmig verzweigt sind. Neben den ganzen Parametereinstellunge gibt es bspw. noch einen Handbetrieb, die Tastenbedienung darin ist komplett anders und man tut gut daran, diesen Code nicht mit den Parametereinstellungen zu mischen. > Es ist so viel einfacher, ein case zu einem switch hinzuzufügen. Und dabei sich alles zu zerschießen.
Thorsten M. schrieb: > Das hast du falsch verstanden, natürlich speichert man Zustände Hmm Thorsten M. schrieb: > und man braucht weder Switch-Orgien noch Zustandsautomaten sehr wohl hätten Zustandsautomaten Zustände. Du speicherst also SOWOHL in der Belegung von Funktionspointern ALS AUCH in Zustandsvariablen den aktuellen Zustand der Menübedienung Also ein zerteilter Zustandsautomat, ein bisschen hier, ein bisschen dort, ohne klare Aufteilung, ihne klares Konzept. Klingt wie eine Einladung: Thorsten M. schrieb: > Und dabei sich alles zu zerschießen.
:
Bearbeitet durch User
Cyblord -. schrieb: > Das ist ja grade die Krux an einer Sackgasse. Man kommt nicht mehr raus. Wer kennt sie nicht, die Millionen Autofahrer, die einmal in eine Sackgasse gefahren und dann elendig verhungert sind.
Klaus schrieb: > Cyblord -. schrieb: >> Das ist ja grade die Krux an einer Sackgasse. Man kommt nicht mehr raus. > > Wer kennt sie nicht, die Millionen Autofahrer, die einmal in eine > Sackgasse gefahren und dann elendig verhungert sind. Wolltest du nicht an einem sachlichen Beitrag arbeiten? Wie weit bist du damit?
Habe das vor Jahren geschrieben. Weiss gar nicht mehr wie es genau funktioniert, aber ist nicht komplex. Prinzipiell muss man den scheiß konfigurieren. Beispiel war damals für eine PID heater. Leider habe ich das Projekt nicht mehr im Repo gefunden :( Sonst im header file findet man einige Funktionen mit den man im Menu selbs t hin und her springen kann. Wenn du ein Taster hast, oder mehrere dann kannst du die Funktionen bei bestimmten tastendruck aufrufen. Sonst der Menu wird nicht auf den Display erscheinen, sondern du musst extern void printLinkedList(const LinkedList * const item, uint8 lineStart); //Callout die Funktion selber implementieren. Hier kannst du entscheiden wie dein Menu aussehen soll, was wo hin und so. Sonst scheint der Zeug noch irgendwie mein task.h brauchen. Viel spass beim basteln! Keine Ahnung ob das Zeug noch tut, war vor mehreren Jahren.
Cyblord -. schrieb: > Man kommt nicht mehr raus. Liegt doch an einem selbst. Entweder versucht man ein Problem zu umgehen (könnte man in diesem Fall des TOs) oder man muss sich durchbeißen und muss sich dem Problem stellen und dann den harten Weg gehen. Ab da hast du recht, da muss man was tun. Aber auch da, wenn du mit Arduino angefangen hast, hast du automatisch schon einige Sachen gelernt und dann geht dir z.B. auch C besser von der Hand. Ich finde einfach immer Klasse, wenn man sich das leicht machen kann und die Lebenszeit ist begrenzt (das weiß ich nur zu genau). Mein Ziel ist und das sollte es immer sein, etwas zu bauen, was das Leben leichter macht oder sonst einen Zweck erfüllt. Der Mikrocontroller ist doch nur ein Stück Hardware auf dem Weg dahin. Das soll doch kein Selbstzweck sein. Gut, ich gebe zu, dass ich mich damals gefreut habe, wie ich mich kaum über anderes gefreut habe, als die Led blinkte. Genauso freue ich mich heute noch, wenn das Display heute beispielsweise anzeigt "Der Tank ist voll!" und die Pumpe abgeschaltet wird. Aber es geht dann immer noch und in erster Linie um den vollen Tank und die Automatik dahinter. Wenn ich das fertig kaufen kann, der Preis im Rahmen ist, kaufe ich es fertig. Ist das mit Arduino einfacher und schneller erledigt, mache ich das damit. Cyblord, mal eine Frage an dich: Nimmst du fertige Wandler für ein paar Euro oder baust du die alle noch selbst? Matze schrieb vor einiger Zeit, dass er die nur noch fertig nimmt, weil er die gar nicht so günstig bauen kann. Damals, als Arduino Fanboy und ich die Hardware proklamierten, die man dann in sein Projekt einbauen kann, denn es handelte sich immer noch um eine Atmega328, war von vielen der Aufschrei groß. Mal ganz offen, wer baut denn den Scheiß noch selbst zusammen, wenn der Platz nicht das Problem ist?
:
Bearbeitet durch User
Frank O. schrieb: > Cyblord, mal eine Frage an dich: Nimmst du fertige Wandler für ein paar > Euro oder baust du die alle noch selbst? Deppenfrage. Schon tausendmal durchgekaut. Arduino ohne Wissen führt meist nicht zum Ziel. Hat mit Fertig kaufen vs. Selber machen schlicht nichts zu tun. Arduino ist NICHT die schnellere Lösung. Das scheint nur so, weil triviale Beispiele ohne Aufwand funktionieren. Echte komplexe Anwendungsfälle gehen damit nicht, damit wird man nicht schneller sondern die meisten bekommen es dann schlicht nicht hin. Aber auch die Bitte an dich: Mach einen Thread auf wenn du über Arduino diskutieren willst. Bleib doch hier bitte beim Thema.
:
Bearbeitet durch User
Echte komplexe Anwendungsfälle, wenn du da bist und das als Hobbyist, dann kannst du das mit den benötigten Materialien oder du erarbeitest es dir an diesen Projekt. Aber in einem Punkt hast du definitiv recht. Irgendwann kommt der Punkt, an dem du mit zusammen kopieren nicht mehr weiter kommst und echte Arbeit leisten musst. Doch beim Hobby hat man entweder die Zeit und Muße dazu oder man passt das Projekt an sein eigenes Können an. Die meisten werden es wohl in die Ecke werfen. Aber selbst das ist legitim. Ist ihr Geld, ihre Zeit und ihre Entscheidung.
:
Bearbeitet durch User
Hier ein Beispiel der Firmware eines Netzteils, das mit einem Drehgeber bedient werden kann.
Hallo, hier eine Möglichkeit schnell an Ergebnisse zu kommen. Man kann sich kostenlos bei openai anmelden. Das Ergebnis bekommt man in Sekunden. Dazu ist es erforderlich möglichst genau die Vorgaben zu benennen. zB " Displaytyp, Entwicklungstool (Arduino, Microchip Studio usw.), Menügröße (2 oder mehr Menüpunkte) usw. Bei openai kann man soweit ich weiß 5 x pro Tag eine Anfrage stellen. "Hallo kannst du mir bei meinem Programm helfen? Vorgabe: Display ..., Prgrammiertool, andere Anforderungen ... Dann per Drag and Drop in openai eingeben. Ein paar sek warten und man bekommt ein Ergebnis. Den Lösungsvorschlag ausprobieren. wenn Fehler auftauchen kann man openai wieder für eine Lösung fragen. usw. Mir hat diese Vorgehensweise schon sehr geholfen und man kann dadurch viel dazulernen. Wenn die kostenlosen Versuche aufgebraucht sind kann man mit deepseek weitermachen. Ich hoffe diese Info hilft Viel Spass
Veit D. schrieb: > https://github.com/Jomelo/LCDMenuLib2 Hatten wir auch schon: Beitrag "Re: Implementierung von Menüs auf alphanumerischen Displays"
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.