Hi folks, ich bin bei der Programmierung meiner "Home-Automation" an der Stelle angelangt, die Zentraleinheit (und darauf basierend dann auch diverse Controller-Module) mit einem Nutzerinterface zu versehen. Dafür suche ich nun eine Art "Display-Control-Language", da ich das Rad ggf. nicht zwei mal erfinden möchte. Das ganze soll in etwas so funktionieren: * es gibt eine Datenstrukur (Liste), die Informationen über darzustellende Inhalte bzw. auszuführende Display-Operationen enthält * diese Liste wird von bestimmten "Threads" des Hauptprogramm je nach Situation (Eingang von Daten, Nutzer-Interaktion per Tastatur) aktualisiert * ein "Thread" gibt die Informationen auf dem Display aus Zu lösen sind dabei also neben der Formatierung der Ausgabe solche Dinge wie * Timing der Ausgabe (welcher Eintrag wird wie lange dargestellt) * Abfolge der Ausgabe * Verzweigung zu diversen je nach aktuellem Status (z.B. Anzeigen im Idle-State, aktive Menüführung usw.) und nicht zuletzt auch simple Dinge wie * Display an/aus * Hintergrundbeleuchtung an/aus . Der Inhalt der besagten Datenstruktur (Liste!?) ist also quasi eine Kontrollsprache für den Ablauf der Display-Darstellung. Hat jemand sowas schon mal irgendwo gesehen oder vielleicht sogar selbst entwickelt und wäre bereit, das zu teilen? Womöglich sogar gleich komplett mit Algorithmen zur Menüsteuerung? (:D) Ralph
Suche mal hier im Forum. Das gibt es zuhauf.
Möglicherweise bin ich einfach zu blond - aber ich habe schon gesucht und nichts in der Art gefunden. Gib doch mal 'nen Tipp, wonach ich genau suchen könnte ;) - Danke
Da kann man sich vertun ... um wieviel Rechenleistung geht es? Quadcore mit 2GHz? Allenfalls XWindows, QT, .. Oder etwas Schmaleres? Ich wuerd das Rad neu erfinden und auf die Beduerftnisse anpassen.
Danke - meine Suchen waren wohl zu kompliziert :D Also ich werde das jetzt erstmal in aller Ruhe studieren...
Bin noch nicht durch alles durch - aber für heute mein Fazit: alle Beiträge beschäftigen sich mit der Implementierung von mehr oder weniger statischen Menüs. Was mich interessiert, ist eine abstrahierende Beschreibungssprache, mit der man dynamisch zur Laufzeit Menüs (im weitesten Sinne) erstellen, modifizieren, verwalten kann. Die konkrete Implementierung von Anzeige, Ablauf, Eingaben und so weiter ist dafür unerheblich.
>Was mich interessiert, ist eine abstrahierende Beschreibungssprache, mit >der man dynamisch zur Laufzeit Menüs (im weitesten Sinne) erstellen, >modifizieren, verwalten kann. Sowas gibt es, meiner Kenntnis nach nicht. Ich kenne niemanden, der erst noch ein Zwischensprache erfindet, wenn er die Menuedatenstrukturen direkt, d.h. durch Funktionen manipulieren kann. Das schluckt nur Performance und führt weitere Fehlerquellen ein.
Also ich finde die Vision von Ralph ziemlich cool. Evtl. muss es kein Laufzeit-Interpreter dieses Script sein, das ist möglicherweise zu teuer an Resourcen bei den kleinen uCs. Aber es könnte ein Precompiler werden, der ein Menusteuerungs-Script in eine C Library oder in ein C++ Objekt übersetzt. Oder in "Bytecode", der Runtime das Menü steuert.
Als Ausgangspunkt oder jedenfalls Anregung könntest Du evtl. die XML-Files von Glade nehmen. Ein Programm mit dem man GTK+ Menüs gestalten kann. GKT+ lädt die dann einmal am Anfang. Das ist so ziemlich das ähnlichste zu Deinem Vorhaben, was ich kenne.
Bitflüsterer schrieb: > Als Ausgangspunkt oder jedenfalls Anregung könntest Du evtl. die > XML-Files von Glade nehmen. Ein Programm mit dem man GTK+ Menüs > gestalten kann. GKT+ lädt die dann einmal am Anfang. Das ist so ziemlich > das ähnlichste zu Deinem Vorhaben, was ich kenne. Das hatten so ziemlich alle Toolkits seit es Toolkits gibt in verschiedenen Formen. Etwa Ressourcenskripte mit Compiler zu binären Datenstrukturen die zur Laufzeit ausgewertet werden, diverser UNIX-Kram (Qt etc.) mit Compiler zu Quellcode oder Auswertung von XML zur Laufzeit etc. Andere Ansätze findet man bei Spiele-UI-Middleware (Scaleform, librocket), die dürften aber zu fett für deine Sachen sein, wenns nicht gerade ein Application processor ala rPi oder so ist. Ansonsten sind da Skriptsprachen beliebt. Eher realistisch: Wenn die MCU dick genug ist, kann man Pawn (läuft sogar auf 8-Bittern) oder eLua (eher was für ARMs) benutzen. Gibt dann auch noch haufenweise weitere Sprachen.
Wenn du ein Zielsystem hast, dass C++ oder sogar Java kann, kannst du auf "Design Patterns" zurückgreifen, da gibt es eines (hab den Namen vergessen) das sich mit dem Aufbau von Menues beschäfftigt. Ich habe es mal so gelöst, dass einige Menupunkte aus Listenelementen bestehen, die ein bestimmtes Interface implementieren und jeweils ihre eigene Menustruktur tragen. Das führt in Verbindung mit GetNxt() und GetPrv() Methoden dazu, dass sich das Menu durch einfügen und löschen von Elementen automatisch anpasst. Dazu kommen Methoden wie WhoAreYou(), wo ein Objekt schreibt was es ist und welche Parameter es trägt.
@ Marian B. (phiarc) Oh je. Das habe ich alles nicht in die Richtung der Frage des TO eingeordnet. Das alles auf einem 16*2 Display... Aber richtig. Wenn Glade die Richtung ist, dann auch das von Dir genannte. Vielleicht hilfts ihm ja.
Der TO erwähnte ja bisher leider nicht, wie seine Hardware etwa aussieht. Bei "Home-Automation" ist alles möglich... HD44780, VGA+ Touchscreen, ...
Tschuldigung für das Chaos in meinem Opening. Meine Zielarchitekturen sind aktuell ein HD44780 an 'ner 8bit-Schleiche (ATmega328) bis hin zu kleinen Graphik-Displays an ATxmega256A3U. Eben gerade das macht die Angelegenheit etwas kritisch hinsichtlich der Resourcen. Das ganz konkrete Problem, wegen dem ich angefangen habe nachzudenken, war folgendes: die Module der Anlage sollen Informationen darstellen können, von denen sie zum Zeitpunkt der Programmierung noch gar nichts wissen. Sprich: es werden neue Module integriert oder bereits existierende funktionell erweitert. In der Konsequenz muss jedes Modul die Daten, die es verteilt, so beschreiben, dass andere Module daraus ableiten können, was damit anzufangen ist. Erledigt wird das durch entsprechende Klassifizierungen der Daten, wobei diese Klassifizierung natürlich jedem Modul bekannt ist. Zweitens: es gibt in der Anlage Module, die die Datenströme koordinieren und deshalb potenziell einer "DOS-Attacke" erliegen könnten - sprich: diese Module müssen halbwegs echtzeitfähig sein. Das führt zu dem Gedanken, die Komplexität einer flexiblen Baumstruktur zur Laufzeit soweit möglich zu reduzieren - idealerweise bis hin zu einer linearen Liste. Drittens: die Module sollen bzgl. ihrer Darstellung von Informationen flexibel zur Laufzeit konfigurierbar sein. Zuerst dachte ich, ich erzeuge klassisch einen Menü-Baum und mache dessen Nutzung dann mit Hilfe einer State machine mit History flexibel. Aber dann kam mir gestern abend der unausgegorene Gedanke, dass es doch möglich sein sollte zu jedem Zustand (also Konfiguration + vorliegende Datenmenge) besagte lineare Liste dynamisch anhand von Regeln zu erzeugen, die z.B. statisch im EEPROM gespeichert werden und beliebig komplex sein können, da dort genug Speicher da ist. Aber hier komme ich mangels ausreichender Erfahrungen ins Schwimmen: wie beschreibt/kodiert man diese Regeln, so dass der Interpreter zur Laufzeit ressourcenschonend ist? Wie regelt man auf einem 8-Bitter die "Thread"-Priorität, damit im Ernstfall die lebenswichtigen Aufgaben erledigt werden (wobei sich die vorliegende Datenmenge ändert) und dann, wenn Zeit dafür ist, der Interpreter die passende "Nutzeroberfläche" erzeugt? Na ich hoffe ihr verzeiht mir meine Unbedarftheit ;) Wie schon gesagt, ist das ist bei mir noch im Status von Brainstorming... Ich hatte aber die vage Idee, dass es dafür schon eine generische Lösung geben könnte, sozusagen den RADGRÖSSENVERÄNDERLICHEN-UND-SPEICHEN-ERSETZENDEN-EINRAD-GENERATOR :D
> besagte lineare Liste dynamisch anhand von Regeln zu erzeugen möglich ist das schon. Die Frage ist eher, ob du das auf einem kleinen Mega328 überhaupt willst. Je kleiner der µC, desto mehr willst du auf alles dynamisch allokierte verzichten. > so dass der Interpreter zur Laufzeit ressourcenschonend ist? Interpreter ist ein großes Wort, dass du hier schnell ad acta legen solltest. > die Module der Anlage sollen Informationen darstellen können Da ist dein Ansatzpunkt. Du musst dir überlegen, wie du deine gewünschte Klasse von Informationen in einer gemeinsamen Datenstruktur beschreibst. Greif das HTML Prinzip auf und trenne Inhalt von Darstellungsform. In der Datenstruktur beschreibst du nur Inhalte, garniert mit zb zusätzlichen Informationen, die eine Benutzereingabe lenken. Wie die dann angezeigt werden, entscheidet das Anzeigemodul. Und denk am Anfang noch nicht über zu viel Flexibilität nach. Du verzettelst dich nur. > Wie regelt man auf einem 8-Bitter die "Thread"-Priorität, > damit im Ernstfall die lebenswichtigen Aufgaben erledigt werden Aufgaben? Wieso Aufgaben? Wo kommen jetzt auf einmal Aufgaben her?
:
Bearbeitet durch User
Aufgaben? Ja na klar, Hauptaufgabe ist das Entgegennehmen und Verteilen von Daten im Netzwerk. Und auch wenn da gerade zufällig Hochbetrieb ist, sollte nach Möglichkeit der Empfangs-FIFO nicht überlaufen, bloss weil eine langsame User-Interface-Funktion gerade vor sich hin dödelt. (Der FIFO ist übrigens schon zweistufig: Hardware-FIFO + IRQ-getriggerter Software-FIFO. Und Kollisionen sowie DOS werden auch behandelt, echte Katastrophen wird es also nicht geben.) Eine einfache radikale Lösung wäre, im Bereich User-Interface nur das allernötigste zuzulassen, solange wie der FIFO mehr als halbvoll ist. Quasi die Ausgabe einer Message: "BITTE WARTEN..." :D . Nein, schön ist sowas nicht. Wenn ich Eure Empfehlungen so lese schwant mir, dass es unter dem Aspekt von Aufwand/Nutzen angemessener wäre, ggf. auf eine schnellere Architektur zu setzen. Oder es bei der Minimalvariante zu belassen, die aber aufgrund mangelnder Flexibilität so ihre Unschönheiten hat - nix für Ästheten der Mensch-Maschine-Schnittstellen. Und jetzt bitte keine Kommentare von wegen: "LCD character display und Ästhetik - häh???" ! Auf einfache Dinge haben eine funktionelle Ästhetik, wenn alles zusammen passt. Für mich hat der Thread seinen Sinn erfüllt. Danke für Eure Tipps. Aber falls es doch noch die eine oder andere interessante Sache zum Thema gibt: immer her damit ;) LG, Ralph
Ralph K. schrieb: > Aufgaben? Ja na klar, Hauptaufgabe ist das Entgegennehmen und Verteilen > von Daten im Netzwerk. Äh. Bis jetzt war immer nur von 'Anzeigen in einer Art Menüstruktur' die Rede. > Und auch wenn da gerade zufällig Hochbetrieb ist, > sollte nach Möglichkeit der Empfangs-FIFO nicht überlaufen, bloss weil > eine langsame User-Interface-Funktion gerade vor sich hin dödelt. Das ist aber lediglich eine Frage dessen, wie du das programmierst. Wenn du natürlich an allen Ecken und Enden aktiv auf Ereignisse wartest, dann ist klar, dass dir alles übergeht. Aber so programmiert man das auch nicht. > (Der > FIFO ist übrigens schon zweistufig: Hardware-FIFO + IRQ-getriggerter > Software-FIFO. Und Kollisionen sowie DOS werden auch behandelt, echte > Katastrophen wird es also nicht geben.) Eine einfache radikale Lösung > wäre, im Bereich User-Interface nur das allernötigste zuzulassen, > solange wie der FIFO mehr als halbvoll ist. Quasi die Ausgabe einer > Message: "BITTE WARTEN..." :D . Nein, schön ist sowas nicht. Ich bin nicht sicher, ob ich verstehe, was du mir da jetzt sagen willst. Irgendwie hab ich das Gefühl, dir ist nicht wirklich klar, wie man Programme schreibt, die scheinbar mehrere Dinge ohne merkbaren Zeitverzug gleichzeitig machen. > Wenn ich Eure Empfehlungen so lese schwant mir, dass es unter dem Aspekt > von Aufwand/Nutzen angemessener wäre, ggf. auf eine schnellere > Architektur zu setzen. Ganz ehrlich. Mir schwant eher, dass du erst mal deine Hausaufgaben machen solltest und lernen, wie man solche 'Multitasking' Systeme auf kleinen AVR macht ohne den Luxus eines Multitasking-Betriebssystems darunter liegend zu haben. Die Technik ist nicht so schwer. Aber lernen muss man sie trotzdem. > Und jetzt bitte keine Kommentare von wegen: "LCD character display und > Ästhetik - häh???" ! Auf einfache Dinge haben eine funktionelle > Ästhetik, wenn alles zusammen passt. Hab ich kein Problem damit. Aber wenn eine Benutzereingabe das halbe System lahmlegt, dann ist nicht das LCD Schuld und auch nicht der Drehencoder, sondern dann hat der Programmierer geschlafen.
Bei allem Respekt, Karl, das sind starke Worte. Nun, in der Tat habe ich - seitdem ich vor 30 Jahren in meiner Jugend mal einen Einplatinenrechner auf Z80-Basis gebaut und darauf Graphentheorie gemacht habe - nichts mehr mit 8-Bit-Prozessoren zu tun gehabt. Die ganze Geschichte, an der ich hier gerade bastle, ist für mich nichts anderes, als - sozusagen am Ende der 8-bit Ära - nochmal zu schauen, was so alles geht. Insofern bin ich natürlich kennungsarm, und das merkt man dann beim Lesen meiner Beiträge. Aber was Du scheinbar übersehen hast, ist die Perspektive, aus der ich an die Sache herangehe. Um mal das Gleichnis mit dem (Fahr-)Rad zu bemühen: wenn ICH ein Fahrrad baue, dann schaue ich nicht, wie DAS Fahrrad gebaut werden kann, welches ich gerade haben will. Ich schaue, wie im allgemeinen Fall ein Fahrrad gebaut wird bzw. gebaut werden könnte. Das macht die Sache kompliziert, weil ich logischerweise sowohl in den Grenzbereich des state-of-the-art gerate als auch selbst an meine Grenzen gelange. Aber gerade das macht das für mich reizvoll - mich interessieren keine Dinge, die ich kann. Für Pragmatiker ist das natürlich ein Ärgernis - tut mir leid. Warum Du Dir als Admin nun die Mühe machst, auf etwas einzugehen was Dir suspekt zu sein scheint, verstehe ich allerdings nicht. Zumal Du offensichtlich den Thread nicht aufmerksam gelesen hast. Hmm, an Deiner Stelle hätte ich einen solchen Thread vermutlich schlicht auf die ignore-list gesetzt. Falls Du aber an dieser Stelle Idealist bist und Dein Anliegen damit ist, dem Forum eine gewisse pragmatische Substanz/Kultur zu erhalten, verstehe ich Dich gut. In diesem Fall hätte ich dem TO allerdings vorgeschlagen, mit seinem Einverständnis den Thread in die Rubrik "Sonstiges" zu verschieben wo er dann in Frieden ruhen möge ;) Friede sei mit Dir Ralph
Kurzer Nachtrag. Die Basics des program flow control einer MCU glaube ich zu kennen: Interrupts für alles was zeitkritisch ist, Beachtung derer Priorität, gezieltes Aktivieren/Deaktivieren bestimmter oder aller IRQs während besonders zeitkritischer Operationen. Keine aufwendigen Operationen in ISRs, also im Wesentliche nur state machine(s) beeinflussen. Hauptschleife, die den Rest erledigt, wenn dafür Zeit ist. Zustandsmaschine wenn nötig zur Priorisierung dieser Aufgaben einsetzen. Habe ich was wesentliches vergessen? Dann wäre ein Hinweis auf eine lesenswerte Quelle nett. <META level="abgehoben" fun="moderat"> In Fleisch und Blut ist mir das mangels Beschäftigung mit der Materie natürlich kaum übergegangen. Und daher komme ich dann ins Grübeln, ob man nicht so etwas wie ein elementares Multitasking-System machen könnte. Bzw. eigentlich nicht ob, sondern wie - so dass das dann elegant, effizient und universell ist. Oder ob es das schon gibt. Sollte es ja eigentlich. Hmm, könnte mal einen Thread dazu aufmachen und schauen, was dabei rauskommt </META> <signature> Es gibt immer eine einfache pragmatische Lösung. Es ist die schlechteste, die ihren Dienst tut. </signature>
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.