ich bin gerade von LCDMenuLib auf LCDMenuLib2 umgestiegen. Dabei ist mir aufgefallen, dass in der neuen Lib der Display (i2c 20x4) bei jeder Bewegung des Cursors (Encoder) komplett neu geschrieben wird.
In der alten Lib wurde der Display nur beim Überschreiten des Cursors des aktiven Menüfensters komplett überschrieben, nicht jedoch beim Bewegen des Cursors innerhalb des aktiven Menüausschnittes oder beim Erreichen und Scrollen über die Menügrenzen (bei _LCDML_DISP_cfg_scrollbar = 0). Ansonsten wurde lediglich der Cursor selbst geupdated.
Insgesamt war der Menüfluss damit sehr flüssig.
In der lib2 wird der Display jedoch permanent mit LCDML_lcd_menu_clear überschrieben, was den ganzen Menüablauf sehr unruhig macht. Gibt es die Möglichkeit die alte Funktionsweise auf die neue lib zu übertragen oder wird dieses Menüverhalten für neue Funktionen der lib2 benötigt?
Ich schätze mal die Funktion wird bei der LCDMenuLib in LCDML_DISP_update_content und bei der LCDMenuLib2 in LCDML.DISP_checkMenuUpdate codiert, hab es bis jetzt aber noch nicht geschafft die ältere Funktion zu integrieren.
Grüße
Marvin
Moin, das stimmt.
Es ging auch eine lange Zeit mit der LCDMenuLib2 so. Ich schau mal nach wann es verloren gegangen ist und wie ich es zurück bekommen.
@skorpi080
Mit Plattform IO habe ich die Lib noch nicht übersetzt. Kann daher dazu bisher wenig sagen. Wenn du einen Weg findest nehm ich das als Anleitung auf GitHub mit auf
momentan ist es mit dem Beispiel LCDML_021_dynUpdatedContent so dass alle dynamischen Menüs jede sekunde blinken.
Wie kann man es lösen dass nur das Menü mit dem Timer aktualisiert wird? Oder noch besser nur der dynamische Content von dem Menü.
Zeile 54 ein kommentieren und in Zeile 58 eine 1 setzen ?
// enable debug strings (remove comments from this line) #define LCDML_DBG 1
// debug special method groups // enable a flag to control the function call order #define LCDML_DBG_function_name_LOOP 0 #define LCDML_DBG_function_name_MENU 1
Und dann mal schauen ob beim "zucken" eine Aktion ausgeführt wird. Normalerweise sollte da nichts kommen (erst wenn der Screensaver startet).
Ich werde das Problem in den nächsten Tagen beheben. Einen kleinen Teil in der Lib muss ich anpassen.
Das Beispiel aktualisiert das Menü, sobald ein dyn Element gefunden wurde. Nun muss dieses dyn Element aber nicht das Element sein, welches permanent aktualisiert werden soll. Bei einer Aktualisierung wird aktuell das gesamte Menu gelöscht und neu geschrieben. Durch den "Clear" kommt dieses blink Verhalten.
Nun ist es recht einfach den Bug auf einem Zeilen Display zu beheben. Bei einem grafischen Display z.b. einem welches über die U8GLib angesprochen wird, ist es etwas komplizierter, da hier meistens eine Page neu geschrieben wird.
Lösungsansatz / Herausforderung:
verschiedene Displaytypen berücksichtigen
Trigger auf spezielle dynamische Element erlauben, damit diese kontinuierlich aktualisiert werden. (Der Polling Ansatz ist hier nicht der beste)
=> Das Beispiel bleibt nicht so bestehen wie es aktuell ist.
Ich habe mir das Problem nochmal im Detail angeschaut. Im Moment gibt es keine andere Lösung zu der, die im Beispiel abgebildet ist. Sobald ein Dyn-Element sichtbar ist (sich im Angezeigten Fenster befindet) wird das Menü neuaufgebaut, weil es könnte sich ja um das kontinuierlich verändernde Element handeln.
Eine Unterscheidung zwischen einem "statisch" angezeigten Dyn-Element (nur Änderung durch User Aktion) und einem "zeitlich angepassten" Element wird von der Menüstruktur nicht unterschieden. Eine neue Variablen in einem Element anzulegen, die diese Eigenschaft verwalten würden den Speicherverbraucht auch für die 95% der User, die dieses Feature nicht nutzen erhöhen.
Sprich, um dies zu umgehen müsste ich ein Task System im Hintergrund laufen lassen, welches dann aktiviert wird, wenn genau die vom Programmierer gewünschte Funktion aktualisiert werden sollte. Könnte man so machen, ist aber für diesen einen Anwendungsfall recht viel Aufwand.
Wenn mir ein cleverer Ansatz einfällt werde ich es anpassen. Ich versuche bei allen Änderungen immer abzuwägen, dass Speichernutzung vs Anzahl der Lib User die es gebrauchen könnten in einem fairen Verhältnis bleibt. Anpassungen die sich über die bestehenden "Register / Flags" noch abbilden lassen sind immer möglich.