LVGL

[Pavel Hudecek]

Zaujalo mě "ruzne paralelni 8/16b sbernice, tam to je SW dost pomale ale 
snesitelne".

Já tedy nejčastěji používám celou paralelní sběrnici (např. 18b) a dostal 
jsem se na asi 6-8 MHz na WR pinu. Tedy něco jako 100 MHz SPI.

Takže mě by "pomalé, ale snesitelné" přišlo těch 10-20 MHz na SPI:-)

Ještě dotaz: Je tam nějaká podpora pro refresh hodnot?
Příklad: Zobrazuju něco z ADC, ono se to mění. Když to budu jen tak 
dokolečka zobrazovat, bude to i při neměnné hodnotě poblikávat, protože 
třeba ILI9341 nemá v běžném režimu žádný Vsync. Můžu si samozřejmě napsat 
program, kde se to bude překreslovat jen po změně hodnoty, ale je s tím dost 
práce. Kdyby pro to byla nějaká podpora typu zavolat funkci "tady máš 
pointer na číslo, sem ho zobrazuj ve formátu 0.0## fontem F1" bylo by to 
super.

PH

-----Původní zpráva----- 
From: Jaroslav Buchta
Doporucuje se udelat buffer asi na 20% pameti displeje, funguje to i s
mensim, minimum je asi 1 radek. Ono to vykreslovani je velmi rafinovane,
kazdy prvek se umi vykreslit jen z casti do odpovidajiciho okna. Takze
pokud se invaliduje treba jen cast nejakeho prvku, tak to zavola
vykreslovaci funkci kde budou jako parametr souradnice toho obdelniku a
funkce by mela vykreslit jen tu cast do bufferu. Jsou tam dalsi
vychytavky, ze okno muze byt jako prazdne a vykresli jen pripadny
ramecek atp. Samozrejme cim mensi bufer, tim pro mensi kousky to vola
vykreslovaci funkce a tim je to pomalejsi ale mam vyzkousene, ze to neni
uplne dramaticke. Kdyz se jeste  vychyta to, ze se treba texty meni jen
pokud se opravdu meni a prvek se neprekresluje, tak to dost pomuze.
Preruseni nesezere nic, jen inkrementuje promennou pro casovani, obsluha
pak podle toho, co se prekresluje - jednotky az desitky ms u takoveho
displeje bych tipnul. Vzdy se vykresli vse, co je invalidovano, v
nejhorsim cela plocha. Ideal je treba pri pouziti FreeRTOS udelat pro to
extra vlakno nebo pouzit vlakno s nizkou prioritou, ktere toho moc
nemusi delat a hlavne nezalezi na latenci, presun bufferu treba s pomoci
DMA a procesor ma dost casu pro dulezitou praci.
Spravu pameti to ma implicitne vlastni, nechavam to takto oddelene, kdyz
dojde pamet tak selze GUI (jen se neco nevykresli pokud je to dobre
osetrene) ale program muze bezet dal. Typicky staci 16-32kB, kdyz se u
programovani premysli, tak se to ani nefragmentuje. Vetsinou mam nejaky
TAB s obrazovkama, kde vzdycky pri prepnuti zalozky puvodni prvky
uvolnim a vytvorim nove, stejne vic casu zabere vlastni vykreslovani nez
vytvareni designu. Ted jsem naplacal asi 6 tabu bez teto vychytavky na
displeji 800x480 jen pro prezentaci a staci na to necelych 30kB, kdybych
uvolnoval, vejdu se do 16 (mam tam vlastni graf ktery z toho alokuje na
ukladani vzorku pro 6 kanalu  takze ted presne nevim) Vyuziti pameti si
lze nekde v rohu zobrazit, sledovat a optimalizovat. Std fce malloc/free
lze pouzit asi taky aby se zbytecne neplytvalo pameti.

Pouzival jsem to s SPI TFT displeji 320x240, i tam to funguje dost dobre
a napadne je v podstate jen pomalejsi vychozi plneni cele obrazovky (10
MHz teoreticky limit, 20MHz displeje v pohode snasi ale uz to je 2x vic
nez v DS), ruzne paralelni 8/16b sbernice, tam to je SW dost pomale ale
snesitelne, s pouzitim FMC rychle jako blesk a nejlepsi je mit
samozrejme MCU, ktery ma primo radic pro RGB displej, tam to je fofr ;-)


Dne 20.11.2018 v 17:53 Jiří Nesvacil napsal(a):
> Kolik RAM v CPU mate pro tu LVG s 320x240 ? 15k bytu tj. 10% grafiky ? 
> Nebo od kolika je to pouzitelne. Jak jsem pochopil, tak se vse nejdrive 
> vykresli do RAM v CPU a pote kopiruje na LCD, treba i po mensich dilech.
>
> Trosku me u te knihovny zarazi, ze nemam odhad kolik vykonu vezme v tom 
> preruseni ci main obsluze u zpetneho volani. Mozna nevim ani kolik RAM a 
> zda malloc a free neni nejak caste nebo tu pamet jeste neroztrha.
>
> S tim LVG se daji delat animace i podkreslni bitmapou, ale je to asi dan 
> za to vse.
>
> Pokud se podivat na FTDI chipy pro grafiku, tak tam prikazy posilate do 
> bufferu toho FTDI a skoro to hlavni chip neomezuje, ale je to dalsi svab.
>
> Jirka
>
>
> Dne 20.11.2018 v 16:55 Jaroslav Buchta napsal(a):
>> Proc myslite, ze se to neda takto pouzit? Je otazka, co myslite malym 
>> armem, ale pokud ma treba aspon 128kB FLASH (fonty jsou trosku rozezrane 
>> ale i do 64kB by se asi vlezlo) a 32kB RAM tak nejaky maly design 
>> obrazovky nebude problem. V konfiguraci se da lecos povypinat, treba 
>> animace, nejake narocnejsi prvky atd. a pak to je asi dost nenarocne i na 
>> FLASH.
>> V STM32F103 to chodi s SPI displejema slusne, ESP32 luxusne, M4 a M7 
>> samozrejme levou zadni.
>> Kdyby to chtel nekdo vyzkouset, muzu poslat projekt pro MSVS kde to mam 
>> jako simulator integrovano i s nejakym projektem (na strankach je 
>> simulator take ale delal jsem vlastni uz kdysi davno)
>> Integrace do MCU je velmi snadna, staci pravidelne casovani z nejakeho 
>> periodickeho preruseni, funkce pro kopirovani obdelniku na displej a 
>> funkce pro cteni aktualnich souradnic touchpadu + detekce doteku a 
>> periodicky po par ms volat obsluznou funkci z nejakeho vlakna nebo fce 
>> main. Ma to i moznost pohybovat se v oknech tlacitky.
>>
>> Dne 20.11.2018 v 16:35 Pavel Hudecek napsal(a):
>>> Původně mě potěšilo, že se to dá použít k nějakému malému ARMu s 
>>> displejem a pár tlačítkama, ale podle toho co píšete, tak jsem se asi 
>>> mýlil.
>>>
>>> PH
>>>
>>> -----Původní zpráva----- From: Michal Grunt
>>> To vypadá na zajímavý projekt. Mám tu x let rozdělanou herní konzoli
>>> na staré hry - RPi/Retropie (RPi 2, malý TTF LCD 320x240, 12 tlačítek
>>> pře I2C expander... je toho plný internet). Tato knihovna by se mi
>>> hodila...
>>>
>>> Pokud by to někoho zajímalo uvedu trochu informací z praxe...Když jsem
>>> to sestavil (bez krabičky) a zkoušel to v praxi tak to bylo absolutně
>>> nepoužitelný co se týče ovládání. Chtěl jsem to na cesty tzn. bez USB
>>> klávesnice (celé to ovládat jenom pomocí 12 tlačítek) a hrát na tom
>>> různé hry, které mají různé ovládání (předem nebudu vědět kterou budu
>>> chtít hrát) a u některých her je potřeba zmáčknout tlačítko/klávesu,
>>> která není předem namapovaná... No prostě to bylo nepoužitelný (možná
>>> tak někde v obýváku u televize s klávesnicí). V Retropie je RetroArch,
>>> ale jednak se mi to neporařilo na RPi rozchodit a pak co jsem koukal
>>> na internet co to umí tak by to stejně nesplnilo moje požadavky (USB
>>> klávesnice prakticky nutnost na nastavení/vytvoření dalšího profilu a
>>> vůbec je to celé takové složité a monstrózní). Takže cíl byl takový
>>> ovládat celou konzoli jenom pomocí 12 tlačítek a úplně ignorovat USB
>>> klávesnici. K dispozici jsem měl i touchscreen na LCD. Tlačítka jsou
>>> ovládáná pomocí jednoduchého softwaru Retrogame od Adafruit, který
>>> ukládá konfiguraci tlačítek do souboru retrogame.cfg a toho jsem
>>> využil. V první fázi jsem naprogramoval průhlednou virtuální
>>> klávesnici na LCD (na grafiku jsem využil dispmanx, přímí přístup do
>>> fb0 se neosvědčil - pomalé, ale třeba jsem to dělal špatnou
>>> metodou...) tím jsem eliminoval v některých případech nutnost USB
>>> klávesnice a v dalším kroku jsem využil souboru retrogame.cfg a
>>> vytvořil jsem takový manager tohoto souboru (přímou editaci souboru,
>>> vytvoření dalšího profilu... a vše jednoduše pomocí grafiky - ukládá
>>> se x kopií tohoto souboru v mém případě existuje 20+1 kopie a kopii
>>> přepíši "ostrý" soubor). Sice to má svoje mouchy (spíš po SW stránce,
>>> které je nutno dodělat), ale když si řeknu, že nyní bych chtěl
>>> vyzkoušet nějakou hru, kterou jsem ještě nehrát a u které neznám její
>>> ovládání není problém si pomocí touchscreenu vytvořit další profil
>>> (kopii retrogame.cfg) pro tlačítka a mohu vesele hrát (vyvolat tento
>>> soubor). A když je nutno během hry zmáčknout nějakou klávesu, která
>>> není v profilu nastavena, vyvolám si virtuální klávesnici a je
>>> hotovo... Proč to píši, protože ten můj software je takové vrabčí
>>> hnízdo a pomocí knihoven littlevgl by to vypadalo dalko lépe a hlavně
>>> by to celý program daleko zjednodušilo a i co se týče dalších úprav by
>>> to bylo jednodužší a přehlednější. Ještě přiložím pár fotek jak to
>>> funguje. Jsem s tím spokojen a funguje to dle představ (principielně
>>> je to absolutně jednoduché na pochopení).
>>> Tak ještě dodělat krabičku (repráček, systém napájení, uspořádat
>>> tlačítka...) a mohu kdykoliv krát cokoliv. Akorát krabička bude trochu
>>> problém, protože jediné co ovládám z 3D programů (krabičku bych
>>> vytiskl) je OpenSCAD a v něm dělat něco složitějšího je pro mě docela
>>> problém...
>>>
>>> https://drive.google.com/drive/folders/1_QtetuT1s8H0czy2MEnWCwaaD7PAWNUF
>>> so 17. 11. 2018 v 21:51 odesílatel Jaroslav Buchta
>>> <jaroslav.buchta na hascomp.cz> napsal:
>>>>
>>>> Nevim, jestli jste si vsimli tohoto projektu https://littlevgl.com/
>>>>
>>>> ale opravdu zije a je neskutecne dokonaly, az tak, ze ho 
>>>> zasponzoruju...
>>>>
>>>> Sleduju to a pouzivam delsi dobu, ma opravdu optimalni koncepci
>>>> vykreslovani i na pomaleji komunikujici displeje, pocita s ruznymi
>>>> koncepcemi HW, IMHO vyjimecna zalezitost.