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/MenuInterpreter-demo.pnghttp://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ß
> Feedback wäre schön.
Ich finde die Idee grundsaetzlich gut. Genauer gesagt mangelt es
eigentlich noch genau an einer derartigen Software vor dem
Hintergrund das GrafikLCDs gerade fuer kleine Controller immer
attraktiver werden. Daher habe ich da selber auch schonmal drueber
nachgedacht.
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?
Eine generelle Beschraenkung auf LCDs mit einer gewissen Groesse und
eventuell eingeschraenkte Funktionalitaet finde ich gut. Man kann nicht
auch bei Microcontrollern damit anfangen so unsaeglich lahme
Uebermonster
Umgebungen zu schaffen wie es sich auf normalen PCs leider durchgesetzt
hat.
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.
Deshalb bin ich von einer eigenen Realisierung erstmal abgekommen. .-)
Olaf
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.
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.:
1
menu-interpreter.c: In function `menu_text_byte_get':
2
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.:>
1
> menu-interpreter.c: In function `menu_text_byte_get':
2
> menu-interpreter.c:143: warning: comparison is always false due to
3
> limited range of data type
4
>
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?
1
$ sha1sum --version
2
sha1sum (GNU coreutils) 6.10
3
Copyright (C) 2008 Free Software Foundation, Inc.
4
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
5
This is free software: you are free to change and redistribute it.
6
There is NO WARRANTY, to the extent permitted by law.
7
8
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:
1
text="cat
dog
sheep"
Unter Windows so:
1
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.
>
1
> $ sha1sum --version
2
> sha1sum (GNU coreutils) 6.10
3
> Copyright (C) 2008 Free Software Foundation, Inc.
4
> License GPLv3+: GNU GPL version 3 or later
5
> <http://gnu.org/licenses/gpl.html>
6
> This is free software: you are free to change and redistribute it.
7
> There is NO WARRANTY, to the extent permitted by law.
8
>
9
> Written by Ulrich Drepper, Scott Miller, and David Madore.
10
>
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:>
1
> text="cat
dog
sheep"
2
>
>> Unter Windows so:>
1
> text="Hallo
Du
Da
"
2
>
>> 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

 entspricht und 
 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:>>
1
>> text="Hallo
Du
Da
"
2
>>
>>>> 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> 
 entspricht und 
 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
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.
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
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,
habe gerade mal einige Tests mit dem Code und dem Tool gemacht. Ein
wirklich gutes Teil, und ein grosses Lob dafür!
Leider stehe ich im Moment vor einem Problem, für das ich keine Lösung
finde, daher die Bitte um Hilfe!
Ich möchte gerne eine Liste mit Texten füllen, die im Ram liegen -
Praktisch, da aktuelle Werte so in Listenform dargestellt werden können.
Das scheint so ohne Weiteres jedoch nicht zu funktionieren. Oder habe
ich ein Brett vorm Kopf... ?
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
@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 !
Günter S. schrieb:> Mal ein Beispiel von mir:
Wow! Ziemlich gelungen würde ich sagen. Ziehe mal den Hut.
Ein super Beispiel für den Menu-Designer.
Ab in den Kunstwerke-Thread damit :-)
sowas habe ich lange gesucht, prima.
nur eine Frage:
wie bekomme ich größere / andere Schriftgrößen hin.
bei änderung über "Font's" sehe ich in der Vorschau keine Auswirkungen.
Gruß Hardy
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.
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.
Hallo,
Es ist auf alle Fälle ein super Projekt, leider bekomme ich beim Versuch
den MenuEditor zu compilieren immer folgende Fehlermeldung
mainedit.pas(573,31) Error: Can't take the address of constant
expressions
Wäre super wenn mir hier jmd. helfen könnte
Gruß fkaiser
Also,
schon mal vielen Dank für die Hilfe und die schnelle Antwort.
Ich hab jetzt wieder alles compiliert, und den Menueditor compiliert er
jetzt, aber er bringt noch viele andere Fehler.
Ich hab die Ausgabe mal Angehängt.
Grüße, fkaiser
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.
Hallo,
ich wollte den Menu Designer auch mal einsetzen.
Kompilieren klappt auch wunderbar, aber leider scheint er nicht auf
Tastendrücke zu reagieren.
Der wichtige Codeteil ist wohl:
1
intmain(void)
2
{
3
MainInit();
4
menu_redraw();
5
//menu_keypress(5);
6
while(1)
7
{
8
if(get_key_long(1<<KEY0))
9
{
10
menu_keypress(1);
11
}
12
if(get_key_short(1<<KEY0))
13
{
14
menu_keypress(2);
15
}
16
if(get_key_short(1<<KEY1))
17
{
18
menu_keypress(3);
19
}
20
}
21
}
Interessanterweise reagiert er auf den Aufruf von menu_keypress, wenn
ich dabei (globale) Shortcuts aufrufe. Wenn ich aber die Focus_Prev_Key,
Focus_Next_Key, Focus_Enter_Key Tasten aufrufe passiert einfach nichts.
Was mache ich falsch?
Vielen Dank
Gruß Christian
Soweit kann ich keinen Fehler erkennen. Aber es gibt mehrere
Fehlerquellen die ich ohne das Menü nicht überprüfen kann:
1. Es gibt nur ein Fokusierbares Element
2. Die Prev/Next/Enter Keys sind im Menü nicht richtig eingestellt.
3. get_key_short(1<<KEY0) ist nie wahr.
Hm, die genannten Fehlerquellen habe ich alle ausgechlossen.
Ich habe mal die xml-Datei angehängt, falls das hilft.
Ich habe mittlerweile auch festgestellt, dass die Variable
"menu_objects", soweit ich das verstehe die Anzahl der Objekte im
aktuellen Fenster, beim Aufruf von menu_keypress anscheinend immer null
ist.
Gut, ich sehe grad, in der angehängten xml-Datei werden 4 und 3 für Next
und Prev genutzt und in meinem Codestückchen 2 und 3, aber das liegt nur
daran, dass ich einfach alles schonmal durchprobiert habe. Daran sollte
es also eigentlich nicht liegen.
Grüße Christian
Hmm. Bei mir funktioniert dein Menü und ich hab mir noch mal den
Quellcode angesehen, beim setzen von menu_objects kann ich keinen Fehler
erkennen.
Welchen Controller verwendest du?
Eventuell ist dein RAM voll oder du hast anderen Code der auf falsche
Speicherbereiche zugreift?
Ich benutze einen ATMega1284p, genügend Ram sollte also eigentlich da
sein.
Ich habe nochmal meine komplette main.c angehängt.
Meine menu_action Funktion ist noch ein Dummy und gibt nur 1 zurück,
aber ich denke, das ist erstmal okay?!
Sieht soweit alles in Ordnung aus. Ohne Hardware Aufbau kann ich da
leider nichts mehr tun. Aber wenn du sagst, dass menu_objects immer 0
ist, dann würde ich da weiter schauen. Sehen wo sie gesetzt wird und was
der Code da macht.
Okay, vielen Dank schonmal soweit, ich werd mich dann demnächst mal ans
debuggen machen und mich danach wieder hier melden, fall ich
weitergekommen bin.
Hallo
Ich habe eine Frage.
Ich habe den Thread gefunden und durchgelesen. Leider blicke ich nicht
ganz durch wie ich mit dem MenüEdit Tool ein Menü für den Atmega
erstellen kann.
Als Display verwende ich ein graphisches mit 128x64 Pixel und eine
ST7565R Controller. Dazu eine Atmega 2560. Gibt es irgendwo eine
Kurzanleitung für das tolle Projekt?
wollte die menuDesigner_1-50.exe mit Lazarus erstellen. Leider bekomme
ich immer einen Fehler. Vieleicht kann jemand die neueste Version als
exe online stellen.
Fehlermeldung:
menuedit.lpr(21,1) Error: Can't open resource file
"D:\menuDesigner_1-50\menuEditor\menuedit.rc"
Die Datei menuedit.rc gibt es auch nicht.
Hm, ja, unter Windows meckert er auch bei mir. Bei einer früheren
Lazarus Version wurde das Fehlen ignoriert. Auf meiner Festplatte gibt
es die Datei. Probier es mal mit
1
1 VERSIONINFO
2
FILEVERSION 0,1,0,2
3
PRODUCTVERSION 0,1,0,1
4
{
5
BLOCK "StringFileInfo"
6
{
7
BLOCK "040904E4"
8
{
9
VALUE "Comments", "\000"
10
VALUE "CompanyName", "\000"
11
VALUE "FileDescription", "\000"
12
VALUE "FileVersion", "0.1.0.2\000"
13
VALUE "InternalName", "\000"
14
VALUE "LegalCopyright", "\000"
15
VALUE "LegalTrademarks", "\000"
16
VALUE "OriginalFilename", "\000"
17
VALUE "ProductName", "\000"
18
VALUE "ProductVersion", "0.1.0.1\000"
19
}
20
}
21
BLOCK "VarFileInfo"
22
{
23
VALUE "Translation", 0x0409, 0x04E4
24
}
25
}
als Inhalt in der menuedit.rc
Wenns funktioniert füge ich die bei Gelegenheit einer nächsten Version
des Editors bei.
danke hat geklappt.
Wenn ich ein Menü erstelle und exportiere bekomme ich 4 Dateien
menudata.bin,menudata.c,menudata-progmem.c,menu-interpreter-config.h
Wie bekomme ich nun das Menü auf dem Display angezeigt. (Verwende ein
Display mit ST7565R Controller)
Christoph B. schrieb:> Wie bekomme ich nun das Menü auf dem Display angezeigt. (Verwende ein> Display mit ST7565R Controller)
Du musst dir eine passende Ansteurungsroutine schreiben, mit dem du
einzelne Pixel auf deinem LCD setzen/löschen kannst. Eventuell findest
du für deinen Controller was passendes in der Code Sammlung.
Dann musst du wie in
http://www.mikrocontroller.net/articles/MenuDesigner#Funktionsweise
beschrieben die dort beschriebenen Funktionen implementieren bz
aufrufen.
In dem Ordner avr-demo findest du eine Beispielimplementierung, die
statt eines LCDs die serielle Schnittstelle verwendet.
Ein kleines Problem bei der geschickten Umsetzung eines Menüs. Bei einer
Hardware setze ich einen Drehencoder ein, der die Tasten
1(li),2(re),3(button) emuliert/erzeugt.
Nun möchte ich mit dem Menüdesigner möglichst einfach eine Uhrzeit
einstellen.
2 Varianten fallen mir dazu ad hoc ein:
a) Oberhalb und unterhalb der Stunde/Minute jeweils ein Pfeilsymbol, das
die Uhr hoch/Runterzählt. Nicht besonders schön, da der gesamte
Bildschirm voller Pfeile ist, eine Variable kann nur geändert werden
durch einen Tastendruck. Diese Lösung eignet sich eher, wenn ein
Touchscreen eingebaut wird.
b) Stunde/Minute ist als Button ausgeführt. Fläche für Stunde auswählen
(Drehencoder li/re), mit Tastendruck Feld auswählen. Die Stunde/Minute
sollen dann bei Links/Rechtsdrehung verstellt werden. En weiterer
Tastendruck bestätigt die Einstellung, schaltet dann wieder in den
Auswählmodus zurück. Diese Variante wäre für einen Drehencoder die
sinnvollste, eine geschickte Lösung fällt mir dazu aber nicht ein. Hat
irgendwer eine gute Idee?
Mach einen Button "Minuten". Der öffnet ein SubWindow (mit einem Label
was eingestellt ("Minuten setzen")wird), welches mit hoch und runter
drehen den Wert einstellt und sich per Button druck wieder schließen
lässt. Mit etwas Programmierung kann das Label auch den aktuellen Wert
anzeigen.
So hab ich das fürs Einstellen der IP Adresse und Lautstärke bei meinem
mp3 Player gemacht.
Hallo Malte,
die Lösung basiert darauf, das der Drehencoder keine Tasten li/re an das
Menü senden kann. Wenn die Struktur im Subwindow angekommen ist, müssen
menu_keypress(Taste li); bzw. menu_keypress(Taste re); extra abgefangen
werden und eine Variable ändern.
Ist das korrekt?
menu_keypress bleibt so wie sie ist.
Du legst in dem SubWindow zwei Shortcuts an, die jeweils auf links bz
rechts reagieren und ein passende Action auslösen. Die Einträge Focus
Previous und Next Keys des SubWindow lässt du bei einer nicht benutzten
Key.
In deiner Funktion menu_action musst du dann passend deine Variable
erhöhen/reduzieren.
Auf https://sourceforge.net/projects/menudesigner gibt es jetzt eine
Version 1.6.
Bugfix: Compiliert wieder mit der aktuellen Lazarus Version (1.0.2 oder
1.0.4)
Feature: Multi-images. Dies ermöglicht einen einfaches Umschalten
zwischen angezeigten Bildern, so dass sich animierte Grafiken mit wenig
Aufwand realisieren lassen.
Servus Leute,
ich muss im Rahmen meiner Forschungspraxis in der Uni gerade ein
DOGXL160 für einen ATMEL controller (fürs erste ein Atmega2560 auf einem
STK600) in Betrieb nehmen und eine Menüstruktur entwerfen etc. Der
Microcontroller steuert dabei außerdem einen externen AD-Wandler welcher
kontinuierlich Messwerte erfasst. Da ich mich mit Microcontrollern
leider noch nicht allzu gut auskenne habe ich leider einige Probleme das
ganze zum Laufen zu bekommen ^^ Folgende Fragen:
- Hat schon mal jemand die vom Programm erstellte Steuerung in AVRStudio
(4) mit WinAVR GCC implementiert?
- Hätte jemand evtl ein Minimalbeispiel wie ich das Display mit Hilfe
des Menu Designers zum laufen bekomme? Das mit dem Hello world bekomme
ich irgendwie nicht hin ^^ Ich habe zwar bereits selber einige
Funktionen zum Ansteuern des Displays über 4-Wire 8-Bit SPI geschrieben,
bekomme aber im Moment nur strings in 5x7, linien, boxen und Bitmaps auf
die Reihe... das Tool wäre mir eine große Hilfe schnell ein gescheites
Menü zusammen zu schustern. Was ich leider noch garnicht hinbekommen
habe ist ein Cursor in irgendeiner Form, da ich später über das Display
und 3-4 Taster auch Werte eingeben und im EEPROM des uC abspeichern
muss... hierbei muss das Display diese natürlich nur anzeigen und nicht
vom Display eingelesen und zurückgegeben werden.
- Funktioniert die Eingabe mittels der 3 Taster dann eigentlich mit
Input-Interrutps oder anders?
- Funktioniert bei euch die Testfunktion des Programms unter Win7
x86/x64? Bei mir kommen leider immer blos Fehler ^^ Weis jemand wie ich
das zum Laufen bekomme?
Wäre nett wenn mich jemand in die richtige Richtung weisen könnte :)
Schon mal im Vorraus viele Dank für die Hilfe!
Grüße
Chris
Chris G. schrieb:> - Hat schon mal jemand die vom Programm erstellte Steuerung in AVRStudio> (4) mit WinAVR GCC implementiert?
Mit GCC: Ja, mit AVR Studio 6: Ja (verwendet GCC) -> Funktioniert prima
> - Hätte jemand evtl ein Minimalbeispiel [...]
Die Minimalbeispiele sind im Paket enthalten. Du musst lediglich Deinen
Displaytreiber anpassen. Dieser Besteht aus
a) Initialisierung
b) schreiben der Daten in Dein Display. Das passiert entweder im Ram,
das Du dann in den Displaycontroller hochlädst oder direkt im Display
(so es auch gelesen werden kann).
> - Funktioniert die Eingabe mittels der 3 Taster dann eigentlich mit> Input-Interrutps oder anders?
Die Tasten werden extern von Deiner Software ausgewertet und das
Ergebnis an den parser gesendet (menu_keypress()) und dort ausgewertet.
Die Struktur, die Malte aufgebaut hat ist deswegen so genial, weil sie
nur auf Events 'Tastendruck' reagiert und die vorkompilierte verkettete
Liste (aus dem MenuDesigner) selbständig abarbeitet. Das Ergebnis dieser
Operation stösst die Generierung der Displaydaten an - nur dann wird
Rechenzeit benötigt.
> - Funktioniert bei euch die Testfunktion des Programms unter Win7> x86/x64? Bei mir kommen leider immer blos Fehler ^^ Weis jemand wie ich> das zum Laufen bekomme?
Ich vermute Du meinst den Menu Designer. Mit Lazarus compiliert unter
Win7 kein Problem. Keine Tricks, alles standard wie im Paket
vorgefunden.
>> - Funktioniert bei euch die Testfunktion des Programms unter Win7>> x86/x64? Bei mir kommen leider immer blos Fehler ^^ Weis jemand wie ich>> das zum Laufen bekomme?> Ich vermute Du meinst den Menu Designer. Mit Lazarus compiliert unter> Win7 kein Problem. Keine Tricks, alles standard wie im Paket> vorgefunden.
Du meinst den "Test" Knopf oder?
Wenn ich mich richtig erinnere hatte ich nie eine Windows Version des
dahinter liegenden Programms geschrieben, sondern nur mit Hilfe von
Cygwin die Linux Variante unter Windows verwendet. Da sind wie in der
fast-start-hello-world.pdf beschrieben, ein paar Anpassungen notwendig
damit das geht. Wer möchte darf hier gerne mal eine native Windows
variante schreiben.
Alles andere hat ja CSpecker schon super beantwortet.
Hallo
ich wollte dieses schöne Programm gerade einmal genauer anschauen,
jedoch leider ohne Erfolg.
Da ich mich mit Pascal leider nicht im geringsten auskenne kann mir
hoffentlich hier jemand einen sachdienlichen Hinweis geben.
Ich bekomme folgende Fehlermeldung bei dem Versuch das ganze
(menuDesigner 1.6.1) per compile.sh zu kompilieren:
1
Compiling menuedit.lpr
2
Compiling mainedit.pas
3
mainedit.pas(755,14) Error: identifier idents no member "executable"
4
mainedit.pas(756,14) Error: identifier idents no member "parameters"
5
mainedit.pas(756,31) Error: Illegal expression
6
mainedit.pas(756,32) Fatal: Syntax error, ")" expected but ";" found
7
ERROR: failed compiling of project menuDesigner_1-6-1/menuEditor/menuedit.lpi
bei dem Versuch das Projekt aus Lazarus heraus zu kompilieren:
1
Compiling exporter.pas
2
Compiling check.pas
3
Compiling help.pas
4
mainedit.pas(755,14) Error: identifier idents no member "executable"
5
mainedit.pas(756,14) Error: identifier idents no member "parameters"
6
mainedit.pas(756,31) Error: Illegal expression
7
mainedit.pas(756,32) Fatal: Syntax error, ")" expected but ";" found
8
### TCodeToolManager.HandleException: "Bezeichner nicht gefunden: parameters" at Line=758 Col=14 in AVR/menuDesigner_1-6-1/menuEditor/mainedit.pas"
BS: Ubuntu 12.04 64
Lazarus: 0.9.30.2
freeglut3/dev
GNU make 3.81
(alles aus den offiziellen Repos)
Ich habe bereits ältere Versionen des menuDesigners ausprobiert (1.6 1.4
1.2).
MfG
Johnny
Das scheint ein Bug in Lazarus/Freepascal zu sein:
http://comments.gmane.org/gmane.comp.ide.lazarus.general/55755
Bei mir unter Debian mit 0.9.30.4-6 geht es. Fürs erste kann ich dir
daher nur empfehlen die betreffenden Zeilen einfach auszukommentieren
(//). In dem Fall dürfte dann der "Test" Button nicht funktionieren -
alles andere aber weiterhin normal. Ich hoffe das Hilft erstmal.
Prima, vielen Dank für deine Antwort.
Auskommentieren hat erstmal geholfen, jetzt weiss ich wenigstens woran
es liegt.
MfG und einen schönen Sonntag noch.
Auf Sourceforge gibt es jetzt Version 1.7:
Das wesentliche neue Feature sind 5x5 Pixel Fonts für sehr kleine
Displays.
Font 12: Fixe 5x5 Pixel Schrift
Font 13: Abstände zwischen Buchstaben sind je 1 Pixel, die Zeichen
selbst sind gleich.
Font 14: Buchstaben werden leicht verkürzt, Zahlen sind immer 3x5 Pixel,
so dass sich andere Zeichen nicht verschiebt wenn sich ständig ändernde
Zahlen angezeigt werden.
Font 15: Maximal platzsparend.
Ansonsten gibt es diverse kleinere Verbesserungen und hoffentlich keine
Probleme mehr beim Compilieren auf verschiedenen Plattformen. Getestet:
1
Debian Linux 32bit + Lazarus 0.9.30.4 + gcc 4.7.2: Entwicklung und Testsystem, alles funktioniert
2
Windows Vista 32bit + Lazarus 1.2.2 + Cygwin (gcc 3.4.4): Menuedit compiliert, alle Tests erfolgreich
3
Windows XP 32bit + Lazarus 1.2.2: Menuedit compiliert, keine weiteren Tests durchgeführt
4
Windows Vista 32bit + Lazarus 0.9.28.2 + Cygwin: Compiliert nicht, Lazarus zu alt
Blödsinn, da steckt einiges an Arbeit drin und ist trotzdem frei
verfügbar.
Setz dich dich selber hin und übersetz es in diese merkwürdige Sprache
oder benutz halt ne anständige...
Es gibt jetzt bei Sourceforge Version 1.8:
https://sourceforge.net/projects/menudesigner/files/
Die wesentlichen Neuerungen sind:
-UTF-8 Support, erlaubt es leichter beliebige Sonderzeichen zu benutzen
-Bei den für UTF-8 notwendigen Änderungen wurde auch gleich eine 8x15
Pixel Schriftart mit eingebaut. (ist jetzt nicht mehr eine separate zu
pflegende Version)
-Visualisierung der Fensterwechsel und Aktionen mittels Graphviz. Das
hilft um besser einen Überblick zu behalten.
-Kommentarfunktion für jedes Fenster. Auch dies dient der
Übersichtlichkeit.
-Diverse Anpassungen an neuere Lazarus Versionen, 64Bit Betriebssysteme,
neuere Cygwin Programme.
-Diverse kleinere Fehler korrigiert
Ich hoffe dass jetzt wieder alles auf allen Plattformen ohne große
Anpassungen läuft. Irgendwie ist immer wieder ein hinterher-pflegen
notwendig. :/
Langfristig hab ich vor irgendwann Unterstützung für farbige LCDs
einzubauen. Diese sind inzwischen bei Ebay schlicht günstiger als
Schwarz/Weiß LCDs.
Viel Spaß
Hallo,
vielen Dank für das neue Update, das Tool macht immer noch einen
Heidenspass und erstaunt immer noch.
Einen kleinen Bug habe ich im Menu Editor gefunden: Wenn Multi-Language
und Multi-Image gleichzeitig verwendet werden, wird Multi-Image nicht
übersetzt, multi-lang hat Vorrang. Siehe 'exporter.pas':
1
if (multilang) then begin
2
temp := max(getOptval(obj, 'multilang')*16, 0); //not every object has this attribute
3
end else begin
4
temp := max(getOptval(obj, 'multiimage')*16, 0); //shares same bit as multilanguage
Hallo,
es hat etwas gedauert bis ich Zeit hatte mich drum zu kümmern. Danke für
den Hinweis, damit war klar wo ich suchen musste.
Im SVN ist es jetzt korrigiert (entscheidend ist nur exporter.pas):
https://sourceforge.net/p/menudesigner/code/54/
Nach langer Zeit gibt es jetzt Version 1.9
https://sourceforge.net/projects/menudesigner/files/
Neue Features:
Unterstützung für 7 Segment Displays
Unterstützung für 4Bit Graustufen Displays - als Vorbereitung irgendwann
auch Farbe zu können. Dafür werden dann aber leider kleinere Änderungen
an der API und den xml Projektdateien nötig sein.
Mein ST7735 lag dafür schon seit 2,5 Jahren unausgepackt im Schrank. Und
inzwischen sind die günstiger als die meisten schwarz/weiß Displays.
Version 2.0 gibt es jetzt bei Sourceforge.
Die wesentliche Neuerung ist die Unterstützung von Farben. Die Bitanzahl
ist recht frei konfigurierbar, so dass hoffentlich jede denkbare LCD
Variante ohne unnötig viel Bitschieberei nutzbar sein sollte. Außerdem
gibt es ein Beispiel für einen STM32. (Selbst die größten AVRs haben bei
kleinen Displays nicht genug internen RAM für einen Framebuffer.)
Hallo,
Karli schrieb:> Wo findet man das STM32 - Beispiel?
Im Unterordner menuInterpreter/stm-demo/ ist das Beispiel - allerdings
wird der "Screen" einfach per UART angezeigt, nicht wie im Bild auf
einem LCD. Aber hier eine andere Ausgabemöglicheit einzubauen (anpassen
von menu_to_hal.c) ist nicht schwer.
> Würde gerne ein Menü am Display (Oled mit ssd1306) erstellen.
Ein Bild vom Erfolg wäre schön :)