https://littlevgl.com/
wurde hier schonmal erwähnt,
Beitrag "Re: LCD Displays, die Qual der Wahl :-("
Jetzt habe ich das mal in mein STM32F407 'Black' board reingehackt,
sieht schon ganz gut aus. Das bringt schon eine Menge Widgets mit um
irgendwelche Gerätchen zu bedienen, ist gut dokumentiert und Code ist
auf github.
Die Portierung ist noch nicht fertig, ich konnte aber recht schnell
fertige Screens aus dem Tutorial oder der Demo anzeigen.
Benutzt das hier noch jemand?
Moin,
ich versuche mich gerade an der selben Kombination.
Die Ansteuerung des Displays und das Schreiben einzelner Pixel
funktioniert ohne Probleme mit ensprechenden Funktionen.
Ich scheiter aber dabei die Funktion zum Pixelarray schreiben zu
implementieren. Darf ich da um Hilfestellung bitten.
Hallo Johannes
Danke erstmal für die schnelle Reaktion. Ich verwende den Code von
diesem Tutorial:
https://www.youtube.com/watch?v=NUErX4dx2Tw
nur halt angepasst für das 16-bit aufsteck Panel.
Das funktioniert auch soweit. Nur wenn ich die Routine zum Pixel
schreiben so umsetze wird das ganze etwas langsam. Der ganze FSMC
Geschwindigkeitsvorteil geht damit verloren.
Außerdem funktioniert mein XPT2046 Treiber noch nicht wirklich (ist
ebenfalls sehr langsam).
ja, der Code ist ok aber durch das setPixel wird das langsam. Beim ILI
kann man ein Fenster setzen und dann einfach alle Pixel rausfeuern.
Müsste auch mit DMA gehen, habe ich aber auch noch nicht umgesetzt.
* Inform the graphics library that you are ready with the flushing*/
19
lv_disp_flush_ready(disp_drv);
20
}
Die Namen für fsmcCommand/fsmcData werden bei dir anders sein, die musst
du aus dem FSMC Teil rausholen und public machen. Dazu brauchst du noch
setAddrWindow Kommando. Müsste auch schon irgendwo in deinem Code sein,
ansonsten:
Hmm,
> 17.10.2019
dann wird auchnoch auf mich verlinkt und ich habs bis heute nicht
gesehen.
Bisher habe ich nur vor mit littlegl mal zu arbeiten.
Wenn ich dann mal meine Universal UI anfange für meine zukünftigen
Projekte.
Bei meinem Wirkleistungsmessgerät hab ich das noch selber gemacht um mal
zu gucken wie sich sone Eigenbau GUI Lib schreibt mit Widgets und co.
Aber das macht echt kein Spaß und verkommt zur Zeitverschwendung.
ZUdem sieht das dann noch schlimmer aus als Win95 ;)
Johannes S. schrieb:> Beim ILI> kann man ein Fenster setzen und dann einfach alle Pixel rausfeuern.> Müsste auch mit DMA gehen, habe ich aber auch noch nicht umgesetzt.
MUSS man sogar machen bei den Displays die weniger Pixel haben als der
Controller.
So wie bei dem 240x240px fürn schmalen Taler, denn der Controller ist
für 320x240.
Was haste denn bisher damit gebaut?
Mw E. schrieb:> MUSS man sogar machen bei den Displays die weniger Pixel haben als der> Controller.
? Nein, es geht ohne DMA. lvgl verwaltet einen virtuellen Screen und
erkennt welche Bereiche gezeichnet und dann aktualisiert werden müssen.
Dazu reicht ein Buffer welcher nur min. 10*Breite groß sein muss. Wenn
der µC genügend RAM hat kann man auch einen kompletten Framebuffer oder
gar einen double Buffer anlegen. Auch GPU beschleunigtes Zeichnen ist im
Treiber vorgesehen (geht dann mit dem ST DMA2D ganz fix).
Ich habe bisher die Treiber für Mbed angepasst und eine einfache GUI für
Schrittmotortests gemacht. Bin jetzt aber zu Ethernet abgedriftet und
die Grafik lag erstmal still.
Na das war jetzt auf SPI + DMA + ILI und LCD px < Controller px bezogen.
Wenn du dann ein zweites (ganzes) Bild per DMA übertragen willst landet
das ja dann um 80px Versetzt auf dem LCD.
Beim Teilübertragen des Bildes mit der Lib ist das natürlich etwas
anders.
Kannst Du mir noch für das Touch Panel einen Hinweis geben. Das ist bei
mir wahnsinnig ungenau. Nicht nur die X/Y Position, sondern auch der
Z-Wert. Kalibrierst Du das und machst eine Art Mittelwert, oder was kann
man da machen...?
der Code für den Touchscreen ist im wesentlichen aus dem lvgl
Beispielcode. Darin wird ein Mittelwert über 4 gelesene Werte als
Standard gemacht. Es gab in dem Beispiel einen Fehler im return code,
den hatte ich gemeldet und als PR in das github Repo eingebracht. War
vor 4 Monaten, seitdem ist da auch nichts geändert worden. Für lvgl6,
mittlerweile ist ja schon v7 in Arbeit.
https://github.com/littlevgl/lv_drivers/tree/master/indev
Die Kalibrierwerte für den screen habe ich empirisch ermittelt, dazu
hatte ich die Rohwerte in die lv_indev_data_t struktur geschrieben damit
ich die auslesen kann (im raw member). Ist aber unschön weil die org Lib
geändert wird. Es gibt aber auch irgendwo eine Kalibrierroutine, die
habe ich aber noch nicht angesehen.
Die Kalibrierwerte als Konstanten sollten auch nur als Initwerte dienen,
können ja bei anderen touchs anders sein. Aber wie gesagt, die lib ist
bei mir auch noch nicht ganz fertig.
1
#define XPT2046_HOR_RES 320
2
#define XPT2046_VER_RES 240
3
#define XPT2046_X_MIN 200
4
#define XPT2046_Y_MIN 260
5
#define XPT2046_X_MAX 3750
6
#define XPT2046_Y_MAX 3860
7
#define XPT2046_INV 0
8
9
#define XPT2046_XY_SWAP 0
10
#define XPT2046_X_INV 1
11
#define XPT2046_Y_INV 1
12
13
14
**Datastructurepassedtoaninputdrivertofill*/
15
typedefstruct
16
{
17
lv_point_tpoint;/**< For LV_INDEV_TYPE_POINTER the currently pressed point*/
18
lv_point_traw;/**< For LV_INDEV_TYPE_POINTER the raw data point*/
19
uint32_tkey;/**< For LV_INDEV_TYPE_KEYPAD the currently pressed key*/
20
uint32_tbtn_id;/**< For LV_INDEV_TYPE_BUTTON the currently pressed button*/
21
int16_tenc_diff;/**< For LV_INDEV_TYPE_ENCODER number of steps since the previous read*/
22
23
lv_indev_state_tstate;/**< LV_INDEV_STATE_REL or LV_INDEV_STATE_PR*/
24
};
Sebastian T. schrieb:> Ich hab das alles sehr verschachtelt:
das mit vielen Pixeln multipliziert macht sehr viel aus...
Im Demo Code kann man den Screen mit dem Finger hin- und herschieben,
das folgt quasi dem Finger direkt ohne Ruckeln.
ich werd mal meinen Code aufräumen und die XPT2046 Routine überarbeiten.
Das mit den Festen Werten fürs Kalibrieren find ich nicht so dramatisch,
weil man das ja nur einmal einstellen muss und wenn man das bei jedem
Start neu Kalibrieren muss nervt das vermutlich.
Ansonsten find ich dieses Board nicht verkehrt. Mal sehen was sich damit
noch alles anstelllen lässt...
Sebastian T. schrieb:> Ansonsten find ich dieses Board nicht verkehrt. Mal sehen was sich damit> noch alles anstelllen lässt...
hier wird das auch verwendet:
Beitrag "STECCY - ZX-Spectrum-Emulator mit STM32"
aber mit 7" Display (was etwas aufwändiger anzuschliessen ist)
Ich benutze das mit Mbed, die SD Karte und der SPI Flash funktionieren
da auch. Mit einem zusätzlichen PHY Board kann das Dingen auch Ethernet.
So ein LAN8720 Phy bekommt man für 5€ beim Chinesen. Allerdings muss man
da mit der Belegung aufpassen, das RMII Interface überschneidet sich da
mit ein paar Leitungen für den TS.
Kanns sein dass manche Widgets die in der Doku drin stehen nicht
existieren?
So etwa das "Gauge" Widget:
https://docs.lvgl.io/latest/en/html/widgets/gauge.html#
Nicht einmal im "dev" Zweig ist Code davon zu finden...?
/edit
ah ok, Doku is veraltet
v8.0.0 (01.06.2021)
- `lv_meter` added as the unioin of `lv_linemeter` and `lv_gauge`
/edit2
Ach nein doch nicht. Ich bin nur zu blöd die richtige Version der Doku
auszuwählen.