Hallo,
ich habe ein komplettes Menüsystem für schwarz-weiß Grafik LCDs
erstellt.
Features:
Bis zu 16 MB Menü Größe im 24/32 Bit Adressen Modus
Bis zu 64 KB Menü Größe im 16 Bit Adressen Modus
Implementiert ist das ganze als Bytecode Interpreter.
Das Menü kann auf jedem beliebigen wahlfrei lesbarem Speicher
untergebracht werden.
Menü Objekte besitzen einen Fokus.
Optimiert für schwarz-weiß LCDs mit bis zu 256x256 Pixel Größe.
Niedriger permanenter RAM verbrauch.
Daten wie Texte oder Grafiken können wahlweise statisch in dem Menü oder
bei veränderbaren Texten/Grafiken im RAM gespeichert werden.
Vier Schriftarten sind bereits vorhanden.
Grafischer Menü Editor (programmiert mit Lazarus), läuft unter Linux und
vermutlich auch unter Windows.
Der Interpreter läuft sowohl auf einem AVR als auch auf dem PC.
Objekte: Fenster, Unterfenster, Box, Label, Button, Bild, Liste,
Checkbox, Radiobutton. Die Verwaltung der zustände für Listen,
Checkboxen, Radiobuttons und Wechsel zwischen den (Unter)Fenstern
geschieht komplett automatisch und erfordert keinen zusätzlichen
Programmcode.
Es werden ungefähr 5 KB Flash für den Interpreter benötigt.

Screenshots:
http://www.mikrocontroller.net/wikifiles/b/ba/Menu...
http://www.mikrocontroller.net/wikifiles/1/1c/MenuEdit.png

Ein Wiki Artikel wird es auch noch geben: MenuDesigner

Feedback wäre schön.

Und hier gibt es zum direkten Ausprobieren ein hex-file (6722 Byte
Flash) für einen ATMega8.
Die Menüausgabe erfolgt per UART an ein Terminal.
Bei 8MHZ Takt: 38400 Baud, bei 16 MHz wären es dann das Doppelte.
Viel Spaß

Olaf schrieb:

> Ich sehe jedoch ein Problem in der interaktion mit dem User.
> Folgendes ist denkbar:
>
> 1. TouchLCD
>
> 2. Eine eigene abgesetzte Tastatur
>
> 3. Einige wenige Tasten direkt unter oder neben dem Display,
>    Eventuell eine art Cursorkreuz.
>
> 4. Nutzung eines Winkelencoder mit Schalter.
>
> Alle diese Sachen machen es eigentlich notwendig eine eigene spezielle
> Grafikoberflaeche zu verwenden die speziell an diese Eingabeelemente
> angepasst ist. Wie hast du dir das vorgestellt?

Mit Außnahme des Listenelements reichen derzeit überall drei
verschiedene Tasten (vorheriger Fokus, nächster Fokus, Enter). 3 Taster
für die Liste gehen, wenn sie das einzige fokussierbare Objekt in dem
Fenster ist und auf "Page up", "Page down" verzichtet wird. Für direkte
Aktionen lassen sich auch 'Shortcut' Tasten definieren.

Von daher sehe ich einige Tasten neben dem LCD und/oder Winkelencoder
als optimal an.

Eine abgesetzte Tastatur ist wohl hauptsächlich für Texteingabe
interessant. Darauf ist das System nicht optimiert, aber mit etwas
tricksen ist auch das möglich.

Eine Methode "Wähle Objekt an Bildschirm Position x/y", gibt es nicht,
so dass ein TouchLCD für das Menüsystem daher derzeit nicht geeignet
ist. Aber da habe ich auch bisher kaum Bastelprojekte gesehen, die eins
einsetzen. Es wäre denkbar den Code für eine solche Funktion zu
erweitern, allerdings ist das nicht mal eben gemacht.

Ich selbst möchte das Menüsystem für einen mp3 Streaming Client benutzen
und dazu einen Drehencoder am Gerät + IR Fernbedienung als Eingabe
verwenden.

> Ein weiteres Problem sehe ich in der notwendigen Nebenlaeufigkeit.
> Mit anderen Worten die Grafikobeflaeche muss es irgendwie schaffen ihre
> Ein/Ausgaben vorzunehmen waehrend der Controller seine eigenen Aufgaben
> erfuellt. Und da sind leider je nach Hauptaufgabe verschiedene
> Strategien
> sinnvoll oder notwendig. So kann es z.B manchmal sinnvoll sein viel in
> einem IRQ laufen zu haben, ein anderes mal ist das undenkbar.
Bis auf weiteres reagiert das System nur auf zwei Funktionsaufrufe
(menu_redraw() und menu_keypress(key)). Nebenher dürfen gerne Interrupts
laufen, nur die anzuzeigenden Daten sollten währenddessen nicht geändert
werden. Ich denke dass ist für alles geeignet, solange man keine
Animationen haben möchte. Wie lange genau die Funktionen brauchen, habe
ich noch nicht ermittelt, falls es zu lange ist, fände ich den Einsatz
eines kooperativen Schedulers und das einfügen einiger Threadwechsel im
Quellcode sinnvoll.

Hi,
um mir doppelte Arbeit zu sparen,
leg ich erst ein Header-File an, in dem meine Variablen(struct)
deklariert sind,
und lass dann per Shell-Script ein GUI (Menu-Listen) erzeugen.
Dabei sind auch Sub-Menüs kein Problem!!
Damit erspart man sich einiges an Arbeit!
DBD
 Olli

Bei der Verwendung in einem etwas größeren Projekt (mp3 Player) sind mir
noch einige Bugs und fehlende Features, die die Verwendung umständlich
machten, aufgefallen.

Daher gibt es jetzt Version 1.1.
Im Interpreter und Editor gibt es jetzt 9 Bugs weniger und 8 Features
mehr.

Der Wiki Artikel MenuDesigner ist inzwischen auch fertig.

Tobias schrieb:
> Wäre das ganze auch auf einem PIC lauffähig?
Es handelt sich um 100% C Code. Wenn du also einen C Compiler
verwendest, gibt es keinen Grund, der dagegen spricht.

Hallo,
sehr interessantes Projekt, doch leider habe ich kein Delphi :(

Könntest du evtl. noch eine lauffähige .exe Datei beilegen, damit man
den Designer gleich testen kann?

MfG
Julian

Ich habe auch nur Lazarus http://www.lazarus.freepascal.org/ verwendet
(die ausführbaren Dateien werden bei Lazarus leider riesig). Ich hoffe
die .exe läuft. Unter WINE habe ich es ganz kurz getestet und es scheint
zu funktionieren. Windows habe ich hier derzeit nirgends zum testen.

So, hab mir dein Projekt mal etwas genauer angeschaut und muss sagen,
dass ich schwer beeindruckt bin! Respekt!!!

Doch eine Sache würde ich mir noch wünschen (ist auch schon im
WIKI-Artikel angesprochen):
 - "Erweitern der Auflösung auf 4096x4096 durch je ein zusätzliches Byte
    für die Position und Größe je Objekt."
(wobei 640x480 reichen dürfte)

In Kombination mit
Beitrag "Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"
oder
Beitrag "LCD Controller für 640x480 LCD mit mega8515"
könnte man geniale und genial einfache GUI's mit dem Micocontroller
realisieren.

Würde mich wirklich sehr freuen, wenn du das noch implantieren würdest!

Julian W. schrieb:
> Würde mich wirklich sehr freuen, wenn du das noch implantieren würdest!

Schwester! Skalpell, Tupfer ...

Ich habe mir das ganze auch mal näher angesehen - es ist wirklich eine
respektable Leistung ;-)

Eine Umsetzung auf einem PIC-Mikrocontroller ist ohne Weiteres leider
nicht möglich - einige Anpassungen sind (je nach verwendetem Compiler)
nötig.

Daher wäre eine Auswahl des Controllers in der GUI wünschenswert die
einem dann gleich den angepassten Code generiert! Vielleicht ist so
etwas ja möglich?!!?

Gruß,
 Tobias

Tobias John schrieb:
> Eine Umsetzung auf einem PIC-Mikrocontroller ist ohne Weiteres leider
> nicht möglich - einige Anpassungen sind (je nach verwendetem Compiler)
> nötig.
Eine Auswahl im Editor, die je nach dem ein passendes #define erzeugt,
wäre kein Problem, aber welche Konstrukte mögen denn die anderen
Compiler nicht? Hardware spezifische Sachen wie I/O verwendet mein Code
ja erstmal nicht.

Für größere Änderungen wie eine höhere Auflösung werde ich in den
nächsten Tagen erstmal keine Zeit finden.

Wollte mal Fragen, wie es momentan mit der Änderung der Auflösung
aussieht...

Möglicherweise in den nächsten Tagen (je nachdem wie leicht mich von
einer "sinnlosen" Ausarbeitung für die Uni ablenken lasse ;-)) Im
Interpreter habe ich die Unterstützung recht schnell binnen 1,5 Std
integrieren können, kanns aber ohne angepassten Editor noch nicht
testen.

Bin schon auf die neue Version gespannt. Wäre wirklich ein geniales
Projekt, auch dann für größere Projekte.
Es wunder mich eigentlich en bisschen, dass hier fast keine Disskusion
gibt, da dieses Projekt einfach super Praktisch ist, vor allem da man
sich das Menü ja quasi "zusammenklicken" kann.

So, jetzt müssten Auflösungen bis 4096x4096 gehen.
Ich habs aber nicht so intensiv getestet, wie bei den vorherigen
Versionen (vorallem garnicht auf dem AVR), da das mit der ASCII
Darstellung in der Konsole etwas problematisch ist und ich im Moment
kein großes Display habe.

Wer als Fehler findet, möge sich bitte melden.

Könntest du bitte wieder eine für Windows lauffähige Version des Editors
beilegen.
Wäre wirklich nett, da ich noch nie mit Delphi gearbeitet habe und keine
Ahnung davon habe (und jetzt auch nicht die Lust, da auszuprobieren, bis
es funzt). Denke mal, es wird vielen Forenbesuchern genau so gehn.

Ok, hier die passende menuedit.exe. Viel Spaß.

Eigentlich ist das Compilieren aber recht einfach:
1. Auf http://sourceforge.net/projects/lazarus/files/
  lazarus-0.9.26.2-fpc-2.2.2-win32.exe herunterladen und installieren
2. Lazarus starten -> Project -> Open Project -> menuedit.lpi öffnen
3. Run -> Build

Danke, wie immer funzt der Build prima. Konnte bis jetzt auch noch keine
Fehler finden.

OK, werde das nächste mal dann selbst probieren, das Projekt zu
compilieren

Hallo Malte,
bin gerade am ausprobieren. Möchte es evtl. für meine Scopeuhr nutzen.
Nun wollte ich mir ein "Testmenu" bauen.
Es sollte nur eine Liste mit "Untermenus" enthalten.
Was ich nicht verstanden habe, wie fülle ich eine Liste mit Texten bzw.
diese müssen dann ja mit den Untermenus verknüpft werden.

Ein kleines Howto wäre evtl. nicht schlecht.

Danke schon mal für Hilfe.

900ss

900ss D. schrieb:

> Es sollte nur eine Liste mit "Untermenus" enthalten.
> Was ich nicht verstanden habe, wie fülle ich eine Liste mit Texten bzw.
Wenn sich der Text nicht ändert, schreibst du den in das Feld "Text or
#define name". Jede Zeile wird ein Eintrag.

> diese müssen dann ja mit den Untermenus verknüpft werden.
Ok, an den Fall dass je nach ausgewählten Element in einer Liste ein
unterschiedlicher neuer Bilschirm erscheint habe ich nicht gedacht...
Da musst du etwas Tricksen.
Grober Ablauf:
Lege für jeden neuen Bildschirm einen Shortcut an und gib der Liste eine
Action. In der menu_action Funktion merkst du dir (Variable) dass ein
Bildschirmwechsel folgen soll. Sobald die Funktion menu_keypress zu ende
ist, prüfst du die oben genannte Variable. Falls gesetzt, Liest du den
Index der Liste aus und je nach Index rufst du dann noch mal
menu_keypress mit dem vorher für den passenden Shortcut festgelegten
Wert auf.

Das AVR Beispiel zeigt, wie man einen Index aus der Liste abfragt und
wenn man complexavrdemo.xml im Editor öffnet, sieht man auch wie die
Listen gefüllt werden.

Wer das System mal auf einem LCD am Laufen hat, kann hier gerne mal ein
paar Bilder posten. :-)

Ich habe erstmal versucht, deine Beispiele in "testing" zu kompilieren.
Da ich kein Linux habe, verwende ich Cygwin.
Im Verzeichnis  "testing" habe ich ./runpctest.sh ausgeführt. Es kommt
zu elendig vielen Warnungen und es wird alles abgebrochen mit z.B. "Test
largesubwindowtest.xml failed".

Eine Warnung z.B.:

menu-interpreter.c: In function `menu_text_byte_get':
menu-interpreter.c:143: warning: comparison is always false due to limited range of data type

Die Warnung ist auch richtig, da wird "if (baseaddr < MENU_TEXT_MAX) {"
abgefragt. MENU_TEXT_MAX ist in menu-interpreter-config.h definiert und
ist 0.
"baseaddr" ist vom typ unsigned long oder unsigned short, je nach
USE16BITADDR. Das kann so also nicht funktionieren. Von diesen Warnungen
gibt es sehr viele, ich vermute überall aus demselben Grund.
Benutzt habe ich deine letzte Version 1-20.

Es entstehen allerdings die gewünschten *.txt files. Und sie scheinen
auch OK zu sein. Nur der Test mit shasum klappt scheinbar nicht.
Im Anhang sind die Testfiles. Kannst du sie bitte mal püfen?
Und die Warnung ist unschön aber es macht in diesem Fall auch keinen
Ärger, wenn ich das richtig verstanden habe??
Weg sollte sie trotzdem :-)

>Ok, an den Fall dass je nach ausgewählten Element in einer Liste ein
>unterschiedlicher neuer Bilschirm erscheint habe ich nicht gedacht...
stirnrunzel Wenn ich dich richtig verstehe, sollten Untermenus auf
eine andere Weise ausgewählt werden, aber nicht durch die Listbox? Mit
der könnte ich dann aber "beliebig" viele Untermenus aus der Listbox
auswählbar machen. Oder hab ich was falsch verstanden? Ob 255 Untermenus
sinnvoll sind, das ist ja eine andere Frage ;-) Aber ich könnte mehr
Untermenus unterbringen, als auf den Schirm passen, da ich in der Liste
ja scrollen kann.

Ich wollte das System nicht auf einem LCD laufen lassen, sondern auf
meiner Scopeuhr. Ist aber noch 'ne Weile hin, bis ich alles soweit habe.
Bin nur auf Dein Menusystem gestoßen und ziehe es in die engere Wahl ;-)

Ich nochmal: Die Eingabe mehrerer Zeilen für die Listbox funktioniert
nicht in dem Menueditor (unter Windows) oder bin ich zu dumm?
Wie kann ich die einzelnen Einträge trennen, wenn sie in dem Editor
einer Zeile stehen sollen (und in der Liste dann aber als einzelne
Listeneinträe erscheinen sollen).

Gruß 900ss

900ss D. schrieb:

> Im Verzeichnis  "testing" habe ich ./runpctest.sh ausgeführt. Es kommt
> Eine Warnung z.B.:
>

> menu-interpreter.c: In function `menu_text_byte_get':
> menu-interpreter.c:143: warning: comparison is always false due to
> limited range of data type
> 

Die Warnungen sind ok, es sollten aber die einzigen bleiben.

> Die Warnung ist auch richtig, da wird "if (baseaddr < MENU_TEXT_MAX) {"
> abgefragt. MENU_TEXT_MAX ist in menu-interpreter-config.h definiert und
> ist 0.
Die Max Werte werden durch den Editor beim Export je Menü neu generiert.
Und wenn im kompletten System keine dynamischen Texte vorkommen, ist der
Wert halt 0. Die Abfrage muss aber sein, damit ein ungültiger Byte Code
keine Speicher Zugriffsfehler produzieren kann.
Unter Linux gibts die Warnung aber nur wenn man auch mit -Wextra
compiliert, so dass ich dies weg genommen hatte. Möglich dass neuere gcc
Versionen das schon mit -Wall akreiden.

Eigentlich hatte ich die Sachen in testing für mich selber hinein getan,
weil ich manuelle das Testen ob nach Änderungen am Quellcode noch alles
funktioniert satt hatte.
Ist denn das Programm sha1sum unter Cywin überhaupt vorhanden?

>>Ok, an den Fall dass je nach ausgewählten Element in einer Liste ein
>>unterschiedlicher neuer Bildschirm erscheint habe ich nicht gedacht...
> stirnrunzel Wenn ich dich richtig verstehe, sollten Untermenus auf
> eine andere Weise ausgewählt werden, aber nicht durch die Listbox?
Ich hatte immer jeden Element als Aktion einen nachfolgendem Bildschirm
zugeordnet, was bei meinen Anwendungsmethoden immer gereicht hat.

> Mit
> der könnte ich dann aber "beliebig" viele Untermenus aus der Listbox
> auswählbar machen. Oder hab ich was falsch verstanden?
Mit dem oben genannten Trick schon.

>
> Ich wollte das System nicht auf einem LCD laufen lassen, sondern auf
> meiner Scopeuhr. Ist aber noch 'ne Weile hin, bis ich alles soweit habe.
> Bin nur auf Dein Menusystem gestoßen und ziehe es in die engere Wahl ;-)
Mach trotzem mal Bilder, wenn du es verwendest.

> Die Eingabe mehrerer Zeilen für die Listbox funktioniert
> nicht in dem Menueditor (unter Windows) oder bin ich zu dumm?
> Wie kann ich die einzelnen Einträge trennen, wenn sie in dem Editor
> einer Zeile stehen sollen (und in der Liste dann aber als einzelne
> Listeneinträe erscheinen sollen).
Auch wenn das Feld recht klein aussieht, es unterstützt mehrere Zeilen.
Nur die Preview scheint unter Windows (oder zumindest in WINE) mit
mehreren Zeilen Probleme zu machen.

Malte __ schrieb:
> Die Warnungen sind ok, es sollten aber die einzigen bleiben.

Es sind die einzigen.

> Wert halt 0. Die Abfrage muss aber sein, damit ein ungültiger Byte Code
> keine Speicher Zugriffsfehler produzieren kann.

Da muß dann halt der Code noch angepaßt werden. Warnungen verwirren
und wenn eine wichtige dabei ist, dann übersieht man genau diese.

> Ist denn das Programm sha1sum unter Cywin überhaupt vorhanden?

$ sha1sum --version
sha1sum (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Ulrich Drepper, Scott Miller, and David Madore.

>
>>>Ok, an den Fall dass je nach ausgewählten Element in einer Liste ein
>>>unterschiedlicher neuer Bildschirm erscheint habe ich nicht gedacht...
>> stirnrunzel Wenn ich dich richtig verstehe, sollten Untermenus auf
>> eine andere Weise ausgewählt werden, aber nicht durch die Listbox?
> Ich hatte immer jeden Element als Aktion einen nachfolgendem Bildschirm
> zugeordnet, was bei meinen Anwendungsmethoden immer gereicht hat.

Du meinst jetzt nicht jedem Listbox-Element sondern einem Button o.ä.?

>
>> Mit
>> der könnte ich dann aber "beliebig" viele Untermenus aus der Listbox
>> auswählbar machen. Oder hab ich was falsch verstanden?
> Mit dem oben genannten Trick schon.

Ich find das gut. Wenn man es braucht ist es sehr hilfreich.

>> Bin nur auf Dein Menusystem gestoßen und ziehe es in die engere Wahl ;-)
> Mach trotzem mal Bilder, wenn du es verwendest.

Werde ich machen. Aber es wird noch lange dauern. Die HW steht auch noch
nicht, nur ein Breadboard mit Testschaltungen.

> Auch wenn das Feld recht klein aussieht, es unterstützt mehrere Zeilen.
> Nur die Preview scheint unter Windows (oder zumindest in WINE) mit
> mehreren Zeilen Probleme zu machen.

Bei dir sieht der Texteintrag in der generierten XML-Datei dann so aus:

text="cat
dog
sheep"

Unter Windows so:

text="Hallo
Du
Da
"

Würde es trotzdem funktionieren? Ich denke nicht wegen dem 0xD da drin
oder?

Gruß 900ss

900ss D. schrieb:
> Malte __ schrieb:
>> Wert halt 0. Die Abfrage muss aber sein, damit ein ungültiger Byte Code
>> keine Speicher Zugriffsfehler produzieren kann.
>
> Da muß dann halt der Code noch angepaßt werden. Warnungen verwirren
> und wenn eine wichtige dabei ist, dann übersieht man genau diese.

Mal sehn, eventuell gibt es ein Compiler Flag um genau diesen Fall zu
ignorieren. Alternativ könnte man auch den Code mit einem #ifdef im 0
Fall entfernen. Aber das möchte ich nicht, da der Code jetzt schon sehr
viele #ifdef Fälle enthält und das sonst sehr unübersichtlich wird.

>

> $ sha1sum --version
> sha1sum (GNU coreutils) 6.10
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by Ulrich Drepper, Scott Miller, and David Madore.
> 

Ok, dann gibt es zwei Möglichkeiten an denen es liegen könnte. sha1sum
scheint verschiedene Modi zu haben -b und -c. Zum zweiten gibt sha1sum
auch leider immer den Dateinamen mit aus, so dass der beim
Stringvergleich mit berücksichtigt wird.

Wie hast du eigentlich den Test unter Cygwin ausgeführt? Hast du die
Mühe gemacht das Linux binary für menuedit unter Cygwin zu erzeugen,
oder hast du den Test so angepasst dass er die Windows .exe nimmt?

> Du meinst jetzt nicht jedem Listbox-Element sondern einem Button o.ä.?
Ja

> Bei dir sieht der Texteintrag in der generierten XML-Datei dann so aus:
>

> text="cat
dog
sheep"
> 

>
> Unter Windows so:
>

> text="Hallo
Du
Da
"
> 

>
> Würde es trotzdem funktionieren? Ich denke nicht wegen dem 0xD da drin
> oder?
Ha, das hat ein paar interessante Nebeneffekte. Der Exporter schreibt
das Zeichen für Zeichen in das Binary, egal welche Art von Umbrüchen
gewählt wird. Und der Interpreter interessiert sich nur für '\n' was
&#xA entspricht und &#xD als nicht druckbares Zeichen wird einfach nicht
angezeigt. Ohne es jetzt aus zu probieren, müsste es somit
funktionieren, aber das Binary unter Windows bei Zeichenumbrüchen
minimal größer werden.

Malte __ schrieb:
> Mal sehn, eventuell gibt es ein Compiler Flag um genau diesen Fall zu
> ignorieren.
Glaub ich nicht.

> Alternativ könnte man auch den Code mit einem #ifdef im 0
> Fall entfernen. Aber das möchte ich nicht, da der Code jetzt schon sehr
> viele #ifdef Fälle enthält und das sonst sehr unübersichtlich wird.

Genau. Hab noch nicht drüber nachgedacht, aber es gibt sicher eine
Lösung.

> Wie hast du eigentlich den Test unter Cygwin ausgeführt? Hast du die
> Mühe gemacht das Linux binary für menuedit unter Cygwin zu erzeugen,
> oder hast du den Test so angepasst dass er die Windows .exe nimmt?

Nöö, man brauchte nix anpassen. Ich habe einefach die Windows-Exe in das
Verzeichnis menuEditor kopiert und Cygwin kann sie starten.

>> Unter Windows so:
>>

>> text="Hallo
Du
Da
"
>> 

>>
>> Würde es trotzdem funktionieren? Ich denke nicht wegen dem 0xD da drin
>> oder?
> Ha, das hat ein paar interessante Nebeneffekte. Der Exporter schreibt
> das Zeichen für Zeichen in das Binary, egal welche Art von Umbrüchen
> gewählt wird. Und der Interpreter interessiert sich nur für '\n' was
> &#xA entspricht und &#xD als nicht druckbares Zeichen wird einfach nicht
> angezeigt. Ohne es jetzt aus zu probieren, müsste es somit
> funktionieren, aber das Binary unter Windows bei Zeichenumbrüchen
> minimal größer werden.

Nun ja, dass kann man dem Designer sicher abgewöhnen, aber ein Drama ist
es ja auch nicht. Nur nicht schön.

Gruß
900ss

900ss D. schrieb:
> Malte __ schrieb:
>> Mal sehn, eventuell gibt es ein Compiler Flag um genau diesen Fall zu
>> ignorieren.
> Glaub ich nicht.
Hmmm... laut
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
gibt es die Warnung nur, wenn -Wtype-limits angegeben ist. Und dass ist
laut der Doku nur bei -Wextra, nicht aber -Wall der Fall. Explizit
deaktivieren lässt es sich wohl leider nicht.

@malte

sehr schönes projekt. habe mir mal den editor zu genüte geführt und
finde das echt klasse was du da auf die beine gestellt hast.
ich habe im rahmen meines never-ending-projects ^^ ebenfalls eine
grafische oberfläche für ein touch-panel (128x64) programmiert welches
einen ähnlichen weg geht. ich verwende ebenfalls einen byte-code stream.
nur das bei mir die grafik-objekte recht einfach in einem separaten
modul erweiterbar sind. aber der aufbau ähnelt sich doch schon sehr
stark.
je nachdem ob ich dazu komme werde ich meine arbeiten auch mal hier
einstellen. nur müsste ich dazu eine weitere abstraktionsschicht
einbauen da ich doch schon einen sehr speziellen display-controller
verwende bzw mein display wird über einen fpga angesteuert und bietet
noch eine kleine grafik-engine, die dann erstmal in c implementiert
werden müsste damit das menü-system überhaupt sinnvoll für andere
nutzbar wäre ^^. und bei der gelegenheit werden wohl noch weitere
abstraktionsschichten (datenzugriff, quelle für den byte-code-stream,
interface für einheitliche displayansteuerung usw) folgen. nur das ich
dann wohl auch nicht mit 5kb hinkommen würde ;-)

@ Rene Böllhoff
Ja, das hört sich tatsächlich nach einer gewissen parallel Entwicklung
an. Es würde mich mal interessieren wie dein Byte-Code Interpreter
arbeitet.
Auch mein Menü System war/ist Teil eines "Endlos Projektes", wobei ich
inzwischen doch nah genug am Ende bin, dass man was sehen kann:
http://www.youtube.com/watch?v=N-m6TGZMfso

@malte ...

woow ... sieht echt sehr schick aus die menü-führung. alle achtung. in
meinem projekt ist noch nicht soviel menü-mäßig integriert, aber ich
werde davon ebenfalls mal ein video einstellen (wenn ich da noch etwas
mehr zeigen kann).
die beschreibung meines byte-code interpreters werd ich die tage mal
vorstellen. vllt kann man sich da ja zusammen tun. allerdings hab ich
noch ne menge daran zu tun, da das ganze schon ziemlich speziell
geworden ist, und ich erstmal "entflechten" muß (daher auch die oben
angesprochenen abstraktionsschichten).
soviel vorab : es gibt für jeden objekt-typen eine eigene funktion,
somit kann das ganze system sehr einfach erweitert werden (sämtliche
objekte sind in einem einzigen modul untergebracht welches unabhängig
von der eigentlichen menü-steuerung ist).

kannst mir ja mal deine email adresse zukommen lassen, dann kann man
sich mal weiter austauschen.

mal eben auf die schnelle ein video bei youtube (allerdings nur das
video ohne ton [abgesehen vom rauschen des handy-mikros :-)])

http://www.youtube.com/watch?v=Zi71ckn5Ags

ein komplettes demo von dem richtigen synthesizer (dann wahrscheinlich
mit anderer hardware da ich in dieser alle funktionen des synthesizers
implementiert habe, bzw das userinterface dort schon fertig habe)

Deine GUI ist auch sehr schön. Vor allem die "Scrollbalken" gefallen
mir. Ich selbst habe bisher keine in meinem System, da ich die nicht
unbedingt brauchte.

>Vor allem die "Scrollbalken" gefallen mir.

um ehrlich zu sein find ich die am langweiligsten :-) bzw die werden
noch deutlich schicker ... aber die scroller lassen sich sehr schön
bedienen ... die potis (nicht zu sehen da ich da noch was vor hab :-)))
find ich am besten. dafür werd ich mir auch noch was einfallen lassen
(so z.b. poti anfassen und dann über eine kreisbewegung die stellung des
potis verändern)
es kommt leider nicht in dem video so rüber, aber durch verwendung des
fpgas ist das display bzw die ganze darstellung ratten-schnell. hoffe
mal das eine reine uC-lösung eine ähnliche geschwindigkeit bzw
performance bringt.
alles mal schauen :-) erstmal alles soweit fertig- bzw ausprogrammieren
damit der synthesizer mal vorgestellt werden kann. und dann sieht und
hört man auch mehr vom gesamtsystem.

Ich hoffe nun nicht das ich geschlagen werde wenn ich hier ebenfalls
einen Link zu meinen Audio-Projekt-Vorstellungen poste (ich will ja
nicht den Thread von Malte kapern), aber es passt so schön hier rein.

http://www.youtube.com/watch?v=LUvqG7hGzsg

So, auf Sourceforge gibt es jetzt Version 1.3:
http://sourceforge.net/projects/menudesigner/
Ein SVN zur Versionsverwaltung ist einfach angenehm :-)

Behobene Bugs:
Listbox scrollt endlich genau wie gewünscht
Tests laufen auch unter Windows mit MinGW
Unter Windows müsste jetzt der gleiche Bytecode generiert werden, wie
unter Linux

Features:
Werden bestimmte Objekte nicht benötigt, wird der Code automatisch
entfernt, dies spart Platz, vor allem wenn man keine Listen oder
Grafiken braucht.
Der Editor erkennt ob Texte und Grafiken doppelt vorhanden sind und fügt
sie zusammen. Bei meinem Musik Spieler (Youtube Video siehe oben) spart
das rund 5% der Bytecode Größe.

Die Warnungen mit dem
> warning: comparison is always false due to limited range of data type
bekommt man unter Windows nicht weg, solange die MinGW gcc Version immer
noch eine alte 3.4er ist.

Keine schlechte Idee, das Projekt auf sourceforge zu veröffentlichen.

Lediglich wäre es noch schön, eine Windows-Version des Designer's
beizulegen.

Aber sonsten kann ich nur sagen, bin ich von deinem Porjekt schwer
beeindruckt!
Das einzigste, was du noch verbessern könntest, wäre das die Menü's auch
noch bunt dargestellt werden könnten ;)

MfG
Julian

Gibt es so etwas eigentlich auch für BASCOM?
Wie sieht es mit Touchscreen-Unterstützung aus?

Mfg Sam

Samuel C. schrieb:
> Gibt es so etwas eigentlich auch für BASCOM?
Ich hatte damals generell kein vergleichbares System gefunden.

> Wie sieht es mit Touchscreen-Unterstützung aus?
Die gibt es derzeit nicht. Mit Ausnahme des Listen Elements, wäre eine
Implementierung aber durchaus machbar. (Man müsste halt alle Objekte des
Bildschirms in umgekehrter Reihenfolge durchgehen und das erste Objekt
nehmen, bei dem der Druckpunkt innerhalb der Koordinaten liegt).

Hallo zusammen,
scheint ja, als wär ich der Erste mit "Beweisfoto" ;)

Zunächst mal ein dickes DANKE für dieses Stück Software!
Sowas hab ich schon lange gesucht!

Das Display stammt von Pollin, hat 128x64 pixel Auflösung, und einen
KS0108-Controller.
Die Integration in das Menusystem war überhaupt kein Problem. Das
Einzige, was mir im Moment noch etwas Kopfzerbrechen bereitet, ist die
ausschließliche Bedienung mit einem Inkrementalgeber und einem Taster.
Allerdings hab ich dieses menuSystem gestern hier entdeckt, heute
implementiert, und hatte noch keine Zeit mich Intensiv mit den Details
zu beschäftigen. Das folgt nun als nächstes.
Ich werd hier dann weiter berichten.

Harry

p.s....ich seh gerade, daß ich versehentlich das Foto doppelt angehängt
hab....Sorry!

<edit> unter dem Display werkelt ein ATMega644 mit 16MHz</edit>

Hallo Malte,

habe mir vor ein paar Tagen auch mal den Menu Designer angesehen ....

Ich bin begeistert. Wirklich ein tolles Projekt.

Einfach Lazarus installieren, Build Prozess starten und schon hat man
den Menu-Designer als exe. Danach ein paar Menüs gestalten und die in
sein avr-projekt einbinden.
Dann noch ein paar Ausgaberoutinen für das LCD anpassen und fertig !

Ich selber will folgendes System damit aufbauen.

- Webradio auf ATXMEGA128 Basis mit LCD 240 x 128 (t6963c)
- Freertos (Anpassung an den Atxmega128 läuft schon)
- uip Stack
- Platine ist schon fertig Beitrag "KICAD - ATXMEGA128A1 Board mit Ethernet, SDRAM und SD-Karte"
- Interfacekarte VS1053 von Watterott
- Elm-chan File System

Na, da habe ich mir etwas vorgenommen .....

--------------------------------------
Noch ein kurze Anmerkung ...

In der Funktion

void menu_text_draw_base(SCREENPOS x, SCREENPOS y, unsigned char font,
                         unsigned char storage, MENUADDR baseaddr,
                         unsigned short offset, SCREENPOS maxpix) {

ist noch ein kleiner Fehler. Nutze ein 240x128 lcd.
maxpix += x; Kann einen Überlauf haben; z.B. in zeile 230 an Spalte 40
auf den lcd. Text wird dann nicht mehr ausgegeben.

Schön, dass mal jemand ein Bild zeigt.

@Harald L:
Bezüglich Inkrementalgeber + Taster, das müsste soweit funktionieren,
nur mit der Liste ist es ohne extra Knöpfe etwas knapp. Deswegen habe
ich bei meinem Menüs Listen immer einen eigenen Bildschirm gegeben, so
dass kein Knopf für einen Fokuswechsel notwendig ist.

Den Bug mit menu_text_draw_base habe ich im Sourceforge SVN eben gefixt.
Der Fehler war etwas gemein, da es in gewissen Fällen sogar zu einem
Überlauf des Textes auf die linke Seite kommen konnte (nur bei LCDs mit
249-255 Pixeln Breite).

Übrigens kann die Version im SVN auch deutsche Umlaute (iso 8859)
darstellen.

@Günter S:
Einen Streaming Client hatte ich mir auch gebaut und dafür das
Menüsystem entwickelt.

Bezüglich Inkrementalgeber + Taster

Selbe Problematik hatte ich auch; habe die Tasterfunktion aufgeteilt

1. kurzer Tastendruck

2. langer Tastendruck

damit kann ich den Inkrementalgeber "doppelt" belegen und Rückgabewerte
beeinflussen.


Schönen Dank noch einmal an Malte wegen ...void menu_text_draw_base

Hallo Malte,
die Idee mit dem Subwindow für die ListBox ist Gold wert! Ich mach das
jetzt so, daß ich ein Label Im Ram anleg, rechts daneben eine kleine
Grafik mit einem Pfeil nach unten. Wenn ich den anklick, öffnet sich das
Subwindow. Das Label zeigt das aktuell gewählte Listenelement an. Auf
diese Art emullier ich eine ComboBox. Das geht dann auch mit
Inkrementalgeber und nur einem Taster.

Jetzt hab ich folgendes Problem:
In der ListBox seh ich kein gewähltes Element. Wenn ich die Bilder im
Wiki richtig interpretier, sollte das doch unterstrichen sein. Bei mir
ist nichts unterstrichen...ich kann allerdings scrollen.
Hab ich da was falsch verstanden?

Harry

Ja, die Sache mit dem fehlenden Unterstrichen ist mir auch manchmal
passiert ;)
Es gibt in dem Editor eine Einstellung "Font" und eine "Font focus". Bei
der Liste wird letztere für das ausgewählte Element verwendet.
Die Fonts 0 und 1 sind ohne Unterstrich, die Fonts 2 und 3 mit.
1 und 3 sind Fixed Fonts, 0 und 2 haben schmale Buchstaben.

Ahhhhhhhh


It works!!!! :)

Danke dir!

wie gross wär der Aufwand, das selektierte element invertiert (also auf
dunklem Hintergrund) anzuzeigen?

Harry

Die einfachste Methode wäre wohl einen weiteren Font zu definieren (bis
zu 16 verschiedene sind möglich). Der Font müsste dann eine Höhe von 9
Pixeln haben damit es oben und unten schwarz ist -> menu_font_heigth()
anpassen.

In menu_char_draw müsste dann bei den menu_screen_set Funktionen in
Abhängigkeit des Fonts die Farbe (1 <-> 0) getauscht werden, das ganze
einen Pixel nach unten geschoben und oben pauschal noch ein dunkler
Pixel gesetzt werden.

In menu_text_draw_base müsste noch eine 9 Pixel Linie gezeichnet werden,
damit die Lücken zwischen den Buchstaben dunkel werden.

Wenn man einfach immer auf if (font & 4) prüfen würde, hätte man schmale
und feste Fonts gleich als Schriften 4 und 5. 6 und 7 wären dann auch
vorhanden, würden mit dem Unterstrich nicht so viel Sinn manchen.

Einziger Haken: Damit es in der Liste gut aussieht müsste eventuell
links jeweils ein Leerzeichen stehen und rechts der Leerraum mit
Leerzeichen aufgefüllt werden.

ich stell mir das etwas einfacher vor:
man könnte bei dem selektierten Eintag die komplette Zeile per XOR
invertieren.
Übrigens fänd ich es sinnvoll, wenn wir diesen Typ "ComboBox" in den
MenuEditor einbauen.
Bei meinen Display-Routinen ist die Farbe "2" das invertieren

ist es gewollt, daß nach dem return aus einem SubWindow der Focus wieder
auf dem 1. Elelement liegt?
Das erschwert die Programmierung meiner ComboBox

Also du könntest in der Funktion
menu_list hinter dem menu_text_draw_base Aufruf einen in der Art
if (t == selectedline)
  menu_draw_box(x, y, sx-9, menu_font_heigth(font), 2);

einfügen. Gegebenenfalls noch den Text +1 nach unten versetzten, die
Fonthöhe jeweils um eins erhöhen, damit oben und unten Schwarz ist.

Zeit weitere Typen zu implementieren habe ich leider keine.

Eigentlich müsste der Fokus bei einem "RET" aus einem Subwindow
restauriert werden.

Hallo,
ich hab ein ganz ähnliches Problem mit den Listen.
Wenn ich ein Listenelement ins RAM, statt ins Flash lege, steht in der
menu-interpreter-config.h ziemlicher Müll bei dem Listenellement. (da
fehlen ein paar #define Anweisungen - nicht compillierbar).

Ein anderes Problem betrifft den Zugriff auf die statischen
Listenelemente im Flash: ich möchte nicht nur auf die Position des
gewählten Element in der Liste, sondern auf den statischen Text des
Listenelement zugreifen (das, was auch in der Listbox angezeigt wird).
Gibt es einen einfachen Weg dafür?

Harry

@CSpecker
Listen im RAM funktioniert wie folgt:
Liste auf "RAM Storage" setzen, einen <Namen> in das "Text or #define
NAME" Feld schreiben. Dann im Quellcode
menustrings[MENU_TEXT_<Namen>] = "123\nabc\ndef"; schreiben. Das ergibt
eine Liste mit drei Zeilen, jeweils mit dem \n als Indikator für eine
neue Zeile.
Wenn sich der Text ändern soll, kannst du zb snprintf verwenden also

static char[128] listeninhalt;
menustrings[MENU_TEXT_<Namen>] = (unsigned char *) listeninhalt;
while(1) {
  int a = getadc(0);
  int b = getadc(1);
  snprintf(listeninhalt, 128, "Sensor 1: %i\n Sensor 2: %i", a, b);
  menu_redraw();
}

@Harald
Hast du eventuell noch weitere Zeilen in dem "Text or #define NAME"
stehen? Bei mir funktioniert es einwandfrei. Ansonsten hänge bitte mal
eine .xml Datei an, die das Problem zeigt.

Eine einfache Methode an den Text zu kommen gibt es derzeit nicht. Wenn
ich Zeit habe kann ich aber dafür sorgen, dass der Editor ein paar
passende Defines für die Position der Texte in den Bytecode generiert.

Mal ein Beispiel von mir:

Webradio (ATXMega128) mit Freertos und LCD 240 x 128 und Menu-Designer


So etwas wie den Menu-Designer habe ich lange gesucht. Perfekt !

Die Vorschau im Editor ist sehr simpel und hat was die Schriftgröße
angeht nur bedingt was mit der Ausgabe zu tun.

Du musst dir in menu-text.c einen passenden Renderer schreiben. Sprich
menu_font_height muss die Höhe deines neuen Fonts in Pixeln zurück
liefern und menu_char_draw muss den Font zeichnen und die Breite in
Pixeln zurückgeben. Derzeit gibt es halt nur einen 5x7 Font in 4
Varianten.

abo

Bevor ich die Anleitung in die nächste Version integriere, gibt es
Unklarheiten, Fehler oder hat jemand sonstige Anmerkungen?

So, es gibt jetzt eine neue Version auf Sourceforge:
http://sourceforge.net/projects/menudesigner/files/

Wesentliche Neuerungen:
Bugfixes
Testfunktion im Editor
Teilweise Touchscreen/Maus Unterstützung (Bezahlt von einer Firma)
Hello-World Anleitung
Mit ein paar Defines kommt man jetzt auch außerhalb des Menüs an
statische Daten ran.

fkaiser schrieb:

>
> mainedit.pas(573,31) Error: Can't take the address of constant
> expressions

Ist wohl eine Free Pascal 2.2 und 2.3 Inkompatibilität.

Ersetze mal die mainedit.pas durch die aktuellste Version unter:
http://menudesigner.svn.sourceforge.net/viewvc/men...
und sag mir ob es funktioniert.

Da müsste ich den Fehler korrigiert haben (wenn nicht noch weitere mit
Version 2.3 drinne sind).

Dir fehlen die passenden Pakete für die Include Header. Je nach
Distribution oder Version sind die gegebenenfalls aber auch einfach in
einem anderem Verzeichnis zu finden.
Du müsstest halt herausfinden wo sich eine "pgmspace.h" befindet und
welches Paket glut.h bereitstellt (vermutlich freeglut3-dev) und diese
installieren beziehungsweise die Pfade anpassen.