u8g 128x64 lcd rychlejší zápis

epzlin
Příspěvky: 37
Registrován: 17 črc 2019, 19:22
Reputation: 0

Re: u8g 128x64 lcd rychlejší zápis

Příspěvek od epzlin » 18 zář 2019, 07:55

commar píše:
12 zář 2019, 11:57
Já bych vyzkoušel hlavně jinou knihovnu, u8g mi přijde taková robustní, moc univerzální...

Díval jsem se na YT a tahle knihovna mi přijde docela svižná..
https://github.com/cbm80amiga/ST7920_SPI

Vzkoušejte...
Tak vyzkoušeno, jako demo vypadá skutečně rychlá. Ale chybí víc informací, dokumentace, fonty, takže momentálně nepoužitelná.

epzlin
Příspěvky: 37
Registrován: 17 črc 2019, 19:22
Reputation: 0

Re: u8g 128x64 lcd rychlejší zápis

Příspěvek od epzlin » 18 zář 2019, 08:05

gilhad píše:
12 zář 2019, 14:14
Jinak asi existujou i knihovny s jinym pristupem, takze by stalo za to pohledat nejakou, ktera ma jako zaklad zobrazovani jen malych oblasti na obrazovce a rucne si pohlidat, aby se ty oblasti neprekryvaly.
Opravdu takové knihovny jsou? Nic moc jsem nenašel. Hlavně jsem to pochopil tak, že v případě tohoto displeje se uloží celá stránka do paměti a následně odesílá. Zkoušel jsem ještě knihovnu u8g2, a žádné výrazné zlepšení nenastalo. Je tam i možnost fast módu, kdy na AT328 zabere skutečně dost paměti, myslím cca 75% (to problém není, můžu použít třeba AT2560 či jiné), ale stále to vykreslení trvá 80ms. Vykresluju 2 vodorovné dělící čáry, 2druhy fontu, a asi 6 proměnných.

Tak bych měl otázku - ta pomalost spočívá v tom samotném LCD, nebo pomalosti Arduina? Když použiju třeba BluePill či ESP, může to být rychlejší?
Další možností je, samozřejmě, použít jiný displej. Ale, co jsem pátral, tak s pomalostí vykreslování jsou problémy skoro všude. Nejhorší je to u displejů připojených přes I2C. Požadek je, větší grafický displej cca 2"-3", dobře čitelný i na slunci (což OLED moc nesplňuje).

Uživatelský avatar
gilhad
Příspěvky: 774
Registrován: 07 bře 2018, 11:22
Reputation: 0

Re: u8g 128x64 lcd rychlejší zápis

Příspěvek od gilhad » 18 zář 2019, 09:43

With I2C the SSD1306 does not support more than 100KHz. With the overhead (ACK), there might be some 90KHz for the pure bitrate. The display has 128x64 pixel, which are 8192 pixel. So you will get about 11 frames pre second maximum.
I2C je znacne omezeni rychlosti. Dalsi omezeni rychlosti je, pokud prekreslujes celou obrazovku, ackoli bys treba nemusel - pokud se ti povede srazit prekreslovanou plochu na 1/10, tak presouvas jen 1/10 dat a muze to byt vyrazne rychlejsi.

Dal ta data musis nejak generovat - a protoze neexistuje HW podpora pro vyrendrovani fontu, nebo cary, tak ti to zere dalsi vykon NAVIC.

Pokud se oprostis od Arduino abstrakce nad I2C, tak muze cast prace na prenosu delat HW a pritom ti muze bezet i nejaky tvuj SW, takze bys (aspon trochu) delal dve veci naraz = vyhoda z hlediska casu, slozitejsi SW (hlavne potreba vic znalosti)

Pokud se ti to nikde nekrizi, tak muzes ty cary nakreslit nezavisle na fontu a na obrazovce "zapomenout" staticke udaje tam taky vyrendrovat jednou ("Teplota", "Tlak" a tak) a prekreslovat jen ty oblasti s menicimi se cisly (pricemz jeste muzes detekovat, zda se ty cifry meni - a tim radove snizit velikost prenosu a canu vyrazne slozitejsiho programu (zejmena kvuli tomu, ze "bude vedet" spoustu veci navic - zejmena co delat nemusi - coz tam ale musis dodat ty, nikoli knihovna) dobre by bylo si nejak ten program profilovat, kolik casu ti tam co zabere a optimalizovat ty nejvetsi zrouty casu.

Ale nejspis to bude chtit analyzu toho, co vlastne dela - obecna knihovna ma tendenci prekreslovat celou obrazovku, nebo si celou obrazovku drzet v pameti a prekreslovat zmeny (coz znamena pred kazdym kreslenim projit celou obrazovku) - dobrou organizaci programu muzes dojit k tomu, ze prekraslujes jen mala okna a to jen kdyz se zmenila (je rychlejsi porovnat tlak predtim a potom, nez porovnat vyrendrovana cisla pro tlak predtim a potom, nez porovnat celou obrazovku nez prenest celou obrazovku - a jeste rychlejsi muze byt porovnat cifry v tom tlaku a prekreslovat treba jen jednotky, pokud se desitky nemeni).

Jenze to uz je hodne prace programatora a znalosti toho, co presne delas

epzlin
Příspěvky: 37
Registrován: 17 črc 2019, 19:22
Reputation: 0

Re: u8g 128x64 lcd rychlejší zápis

Příspěvek od epzlin » 18 zář 2019, 09:52

gilhad píše:
18 zář 2019, 09:43
na obrazovce "zapomenout" staticke udaje tam taky vyrendrovat jednou ("Teplota", "Tlak" a tak) a prekreslovat jen ty oblasti s menicimi se cisly
Tohle bych mohl skusit, ale jak na to?

Uživatelský avatar
pavel1tu
Příspěvky: 2054
Registrován: 26 říj 2017, 08:28
Reputation: 0
Bydliště: Trutnov
Kontaktovat uživatele:

Re: u8g 128x64 lcd rychlejší zápis

Příspěvek od pavel1tu » 18 zář 2019, 13:04

Lze dosáhnout rychlého zápisu, ale ne v grafickém režimu.

Já používám knihovnu U8x8 - má to své omezení, ale grafická knihovna mi chodila 500-850ms (vykreslení),
tahle kolem 100ms, prý snad i 70ms ale to nemohu potvrdit.

https://github.com/olikraus/u8g2/wiki
UNO, NANO, Mikro, PRO mini, DUE, ESP32S2, RPi PICO
Pavel1TU
"Správně napsaný kod lze číst jako knihu"

Uživatelský avatar
gilhad
Příspěvky: 774
Registrován: 07 bře 2018, 11:22
Reputation: 0

Re: u8g 128x64 lcd rychlejší zápis

Příspěvek od gilhad » 18 zář 2019, 14:22

epzlin píše:
18 zář 2019, 09:52
gilhad píše:
18 zář 2019, 09:43
na obrazovce "zapomenout" staticke udaje tam taky vyrendrovat jednou ("Teplota", "Tlak" a tak) a prekreslovat jen ty oblasti s menicimi se cisly
Tohle bych mohl skusit, ale jak na to?
Procist si datasheet toho grafickeho chipu, rucne si rozkreslit oblasti obrazovky a posilat tomu chipu pouze zmeny toho, co potrebujes vazne zmenit.

Nebo aspon najiot knihovnu, ktera umi prekreslovat nezavisle useky/okna na te obrazovce - coz je v podstate to, co bys psal.

Odpovědět

Kdo je online

Uživatelé prohlížející si toto fórum: Žádní registrovaní uživatelé a 2 hosti