Igen, szinte végtelen a lehetőségek száma. Akkor zűrös csak a dolog, ha van valami olyasmi tevékenység, aminek hosszú a futási ideje és nehéz felbontani több rövidebb ideig tartó tevékenységre. Ilyen esetben 32 bites kontrollereken remekül használható a freertos nevű preemtív multitask rendszer. Abban lehet prioritásokat állítgatni, lehet az adott task működését időzíteni stb.

Ha szemre lassú lenne, akkor ott a programmal lenne gond, vagy nem ez a kijelző lenne alkalmas az adott feladatra.

Urak , mindenkinek köszönöm a válaszokat. (amúgy 40x2 Lcd-t hajtok, ami most kiderült egy kicsit lassabb a 16x2-esnél de szemmel talán nem lehet érezni a lassulást)

Ez gyakorlatilag majdnem egy időosztásos rendszer, hasonlóan működtek a nagyszámítógepek annó.

Egyébként még megszakítások nélkül is megoldható lenne a feladat, hogy várakozások nélkül legyen kezelve a kijelző. Szoktam olyan technikát alkalmazni programozáskor, amikor a program felépítése olyan, illetve arra törekszem, hogy a fő ciklus (loop) a lehető legnagyobb sebességgel fusson. Ezt úgy érem el, hogy minden részfeladat (függvény) megnézi pl. a millis() fügvénnyel, hogy mennyi ideje futott le utoljára és ha még "nem jött el az ideje" akkor azonnal kilép, akkor is azonnal kilép ha éppen nincs dolga (pl gombok kezelése, de nem nyomtak meg egy gombot sem). Így lehetnek olyan részek amik 1ms-onként fognak lefutni, míg más részek mondjuk csak 17ms-onként. Így amíg nem érem el a 100% prociterhelést addig minden feladat kb. időben lefut, és a nagyon gyors főciklus miatt egyfajta kooperatív multitasking-hoz hasonlító eredményt kapok - tehát látszólag sok dolgot egyszerre csinál a program. Persze ehhez a részfeladatokat is úgy kell megírni, hogy ne foglalják le egyfolytában és hosszú időre a processzort.
De erre nem mindig van szükség, mert van amikor egy program feladatai nagyjából sorba rendezhetők, a kevés kivétel meg mondjuk megszakításban lesz kezelve.

A forrasztóállomásom pl. 160ms-onként frissíti a kijelzőt. Ha ez 1ms-os karakterírással lenne kombinálva (tehát összesen 16ms-ig tartana a frissítés) az szerintem furán nézne ki - de lehet, hogy tévedek. Továbbá 160ms-onként belefér 1,6ms a kijelzőre, ez mindössze 1% processzoridő. Emiatt nem érdemes ebbe több energiát fektetni. Az elvégzendő feladatok mellett így is rengeteg "szabadideje" marad a processzornak, így egyszerűen nincs rá szükség, hogy megspóroljam azt az 1%-ot.

Az 50µs-os megszakítást egyébként úgy írtam, hogy az csak akkor lenne aktív amikor nem üres a puffer, és azért 50µs, mert addigra pont szabaddá válik a kijelző.

Egyébként értem, és elfogadom amit írsz, és hobbiból, vagy tanulás céljából esetleg le is lehetne programozni, lehetne tesztelni, stb... De erre tényleg nagyon ritkán lenne szükség.

Szerintem is időzítő megszakításból érdemes írni a kijelzőt, de felesleges hozzá a 40-50usec. Tökéletesen elegendő 1-2msec sűrűséggel (az 1msec az még mindig 30frame/sec sebességet biztosít egy 2x16 karakteres kijelzőn). Magát a kijelző tartalmat pedig egy karaktertömbben érdemes tartani. A kiírató függvények csak ebbe a tömbbe tennék bele a kiírandó tartalmat (hívhatjuk ezt frame buffernek). Így nagyon gyors lenne a szöveg kiírató eljárás, mert csak memória másolást kell csinálnia. Nagyon gyakran szoktak használni 1msec-es "rendszeridőt" a programokban, akár az ezt előállító megszakításba is beletehetjük a kijelző frissítést. Az is megoldható, hogy a kijelző frissítés csak a frame bufferbe történő írások után történjen meg, ezzel is lehet processzor időt spórolni. Villogó karakterek is előállíthatóak ezen a módon.

Az LCD kijelző, mint ahogy arról szó volt kb. 40...50µsec/karakter sebességgel írható. Mind az i2c, mind a léptetőregiszteres megoldás gyorsabb ennél, azaz sokkal rövidebb idő alatt ki tud írni egy karaktert, ezért ki kell várni, hogy a 40µs teljesen leteljen az újabb karakter kiírása előtt. Tehát mindegyik módszer esetén a kijelző korlátozza a sebességet, és semmi más.

Programozás szempontjából elképzelhető olyan megoldás ami pl. megszakításokkal kezeli a kijelzőt, várakozások nélkül. Ez némiképpen bonyolultabb, de megoldható. Megszakítást generálhatna a kijelző is amikor szabaddá válik, vagy elképzelhető timer megszakítással ami 50µsec időközönként lefut, mindaddig amíg van a pufferben kiírandó karakter, és minden alkalommal egy karaktert küld ki a kijelzőre.

Azonban a legáltalánosabb 2x16-os kijelző teleírható max. 1,6msec alatt, és egy nagyobb 4x20-as is max. 4msec alatt. Ennyi időt általában azért rá lehet szánni a legtöbb programban a kijelzőre. Tehát nem biztos, hogy érdemes bonyolítani a programot a várakozások miatt. De ha számít néhány msec idő is, akkor meg lehet oldani a kijelző kezelését pl. megszakításokkal.
Bár az ilyen projektek esetében sokszor már nem 2x16-os kijelzővel kell játszani...

A karakteres LCD kijelzők fő előnye manapság hogy egyszerű és olcsó. Vannak már sokkal szebb, és sokkal jobb kijelzők ennél, de drágábbak és/vagy nehezebb kezelni - ezért van létjogosultsága még ezeknek az alfanumerikus kijelzőknek.

Nagyságrendileg teljesen mindegy, hogy 4biten, 8biten, I2C-vel vagy shift regiszterrel hajtod, az LCD mindig lassú marad... Olyan, mintha azon gondolkodnál, hogy melyik cipőt hordjad, amikor beszállsz a trabiba, hogy Szegedről Budapestre gyorsabban odaérj...

Helló. Értem, hogy ez az lcd lassú de pl te szerinted az I2C soros port nem lassítja még jobban?

Azt meg kellene értened, hogy a karakteres LCD kijelző az egy atom lassú szerkezet! Olvasd el, hogyan kell meghajtani, mennyit kell várni, hogy az LCD az adatokat feldolgozza. Pl. egy teljes törlés 1.5ms, és ez nem gyorsítható. Vagy megvárod, vagy ellenőrzöd a busy flag-et, vagy visszatérsz fix idő múlva... Google: 1602 LCD pdf, első találatot olvasgasd kicsit.

Nem az LCD meghajtása lesz a gyors, hanem az a kérdés, hogy a mikrokontroller várakozik az LCD-re, amikor írja, vagy mellette csinál is valamit? Ezt pedig nem fogod sima könyvtárakkal megoldani, ehhez egy stabil, megszakításos LCD meghajtás kell, lehetőleg I2C vagy valami bufferes megoldással (shift regiszter pl.), hogy ne kelljen még az LCD bemenetire se várni.

Köszi. Most már jobban értem mint eddig. Csak még azt had kérdezzem meg, hogy ezzel a módszerrel ki lehet használni az LCD maximális gyorsaságát?

Mutatom a különbséget az STM32 és ESP8266 procira megírt verziók között:
Ez a rész a .h fájl elején van, és ez határozza meg, hogy melyik két lábon vezéreljük a kijelzőt. A program (v. ha úgy tetszik könyvtár) többi része ugyanaz mindkét proci esetében. Nagyjából bármelyik processzorra ezt a részt kell csak módosítani ill. átírni.

Nem jól érted. Ha úgy tetszik a weblapon az egy könyvtár (legfeljebb kicsit hanyagabbul készült, mint egy gyári). Be kell másolni a .h és a .cpp fájlt a projekt mappájába, és include-olni kell a .h fájlt a főprogramba. Ezután már lehet is használni, arduinoval kb. így:

Bonyolult?

Persze a .h fájlban meg kell határozni hogy melyik lábakat használja az MCU-n, és erre nincs külön függvény, hanem bele kell írni a fájlba. Tehát valamennyire nem árt megérteni, hogy mit csinál. Az I/O lábak közvetlen elérése pedig processzorfüggő, ezt figyelembe kell venni. Az arduino digitalwrite() függvénye pl. nem processzorfüggő, cserébe sokkal lassúbb, bizonyos processzorokon annyira, hogy LCD meghajtó írásához alkalmatlan, ezért az I/O lábak közvetlen kezelését nem lehet elkerülni.
Persze megtehettem volna, hogy multiplatformos szoftvert csinálok, és sokféle processzorhoz megírom a kódnak ezt a részét, de ez nem azért készült. Azért készült mert nekem kellett, de közzétettem, mert úgy gondoltam, hogy mások számára is hasznos lehet. Eddig STM32-n (BluePill-en), ESP8266-on, és Arduino DUE-n használtam, illetve még ez elején a 3 vezetékes megoldást, arduino nano-val. De egy barátom sikeresen használta már PIC-en (csak minimális módosítás kellett, hogy a teljes kód leforduljon PIC-re).
A forrasztóállomásom is ilyen kijelző-meghajtást használ, és történetesen az apróban még nyák is fellelhető, akár külön csak a kijelzőhöz is.

Ha jól értem a te módszered is pofon egyszerű lenne ha lenne hozzá könyvtár. (Amúgy meg már régebben is olvastam a weboldaladat és az egyik led áramgenerátorodat meg is építettük ami nagyon jó és köszi a leírást hozzá)

A hardverfüggő része a szoftvernek gyakorlatilag egyszerűbb, mint sima 4 vagy 8 bites meghajtás esetén. Utóbbi esetben ugyanis bitenként kell a lábakat beállítani, a léptetőregiszter esetében viszont egy ciklus ki tudja léptetni a biteket.
Igaz, hogy a sima LCD meghajtás meg van írva az Arduino-ban (és néhány egyéb fejlesztőkörnyezetben is) ezért nem is látszik, hogy van megoldva, csak használni kell.
A magasabb szintű függvények (amik már nem bit, hanem bájt szintűek) pedig kb. ugyanolyanok, hiszen ezen a szinten már nincs különbség a kijelző vezérlésében.
Persze megint csak az a helyzet, hogy az egyik esetben csak használsz pl. egy init() függvényt, a másik esetben meg látszik is, hogy mit csinál az init() (azt amit a kijelző adatlapján is leírnak, hogy az inithez kell).
Eredetileg ESP8266-ra készült ez az egész, mert annak kevés I/O lába van, és érdemes takarékoskodni vele, de azóta sokféle MCU-val kipróbáltam. De természetesen nem kötelező használni, ez csak egy lehetőség, annak aki használni szeretné.

Köszönöm mindenkinek a válaszokat!

Egyelőre nem váltok i2c-re hiába foglal sok lábat a 4bites meghajtás.
Skori olvatam az írást a weboldaladon. Hosszan részletezed a technikáját és nagyra tartom a munkádat de a szoftveres része mintha elbonyolítaná az egészet.

Én sem akarom tuningolni, csak a standard időzítésre állítottam be a régi kijelzőt.

Viszont esetleg Kovidivi projektjében lehet értelme. Bár a kék-fehér kijelzőknél maga az LCD szegmensek nagyon lassan váltanak.

Sajnos azok a kijelzők amik nekem vannak, nem működnek 3V-ról. Nem a vezérlő része nem megy, hanem az LCD panelnek nem elég a 3V - tehát nem lehet a kontrasztot beállítani (5V táp esetén is közel maximumon van a poti).
Amúgy köszi a rajzot, megint tanultam valamit.
Ilyen karakteres kijelző tuningolásának már nem állnék neki. Ezeknek a legnagyobb előnye, hogy egyszerű és olcsó. De ha annál több kell, mint amit egy ilyen kijelző tud, akkor célszerűbbnek gondolom egy modernebb kijelző használatát. Abból a kis panelből amit használok a kijelző vezérlésére (74HCT595-el, pl. a forrasztóállomáshoz is), gyártattam egy maréknyit, ami az összes ilyen kijelzőmhöz elegendő lesz, és még maradni is fog belőle

A kínai I2C átalakítón PCF8574T van, ami egy 8 bites I2C IO expander. Mivel 8 sima IO kimenete van, ebből adódik is, hogy 4 bites módban lehet vele kezeli az LCD-t, a többi láb megy az RS, R/W, E és háttér ki/be kapcsolására.

Kapcsolási rajz

Ezzel ugyanúgy a 40...50µsec karakteridő érhető el.

Egyébként régi típusú kijelzőkön, amiken még nem fekete plecsnik az IC-k, A vezérlő lábáról lekövethető melyik a oszcillátor ellenállása. Például nemrég KS0066-nál cseréltem a gyárilag beépített 120 kOhm-ot az adatlap ajánlása szerinti értékre (3V: 75 kOhm vagy 5V: 91 kOhm), amivel a névleges 270 kHz-es órajel előáll. Enélkül sokkal lassabban működött. (Az újabb plecsnis kijelzőkön is ott lesz az RF 91kOhm)

Ha valaki nagyon gyors frissítést szeretne elvileg 400kHz-ig is el lehetne menni, de az az alkatrészek szórása miatt használják a névleges 270kHz-et.

Nekem az a tapasztalatom, hogy ezekre a karakteres LCD kijelzőkre kb 40...50µsec alatt lehet kiírni egy karaktert. Akár 4 bites, akár 8bites módban van, ebből a szempontból csak annyi a különbség, hogy 4bites módban, az E lábra két impulzus kell. Ha gyorsabban írjuk a kijelzőt akkor elhagy karaktereket. Az i2c buszt hiába gyorsítjuk, a kijelzőre akkor sem lehet gyorsabban írni. Ennek egyedül akkor lehet értelme, ha az i2c-t fogadó MCU puffereli az adatokat, tehát akár nagy sebességgel is fogadja, és tárolja addig amíg ki tudja írni a kijelzőre. Nem tudom hogy ezek a kínai átalakítók ilyenek-e.
A sima léptetőregiszteres megoldás amit használok, soros-párhuzamos konverzióra, kijelzőmeghajtóként, szintén sokkal gyorsabban kezelhető mint a kijelző, ott is be kellett állítani a szoftverben, hogy ne írja a kijelzőt 50µs/karakter sebességnél gyorsabban.

Az alap 8 bites mód sem figyeli a kijelző foglaltságát. Ott is időzítve van a kód, hogy kivárja, amíg az kiír. Mégpedig a 3.3 voltos LCD-k lassabb órajeléhez állítva.
A leggyorsabb mód az a 8 bites mód, ahol is a busy flag le van kérdezve. De az alap 8 bites alkalmazásnál írásra van kötve fixen az RW láb. Az I2C-nél nem ott van, ott az illesztő IC-re van kötve. Rá fogok nézni, hogy használja-e.

A 8 bites módot nem mértem sosem. Külföldi fórumokon olvasottak alapján ott is az I2C nyer, de csak 1-2 százalékkal. Meg nem mondom már, hogy hol olvastam.
Illetve az sem mindegy, hogy a kismillió könyvtár közül melyiket használjuk.

Azért lehet gyorsabb az i2c, mert az arduino lábanként állítja a kimenetet, 4 bites módban meg két csomagban megy ki az adat. Ha viszont rendesen írja az ember a portot egyben, akkor nem lehet gyorsabb.

Bővebben: Link

Nem akarok ezen vitázni. Írjál egy 5 soros Arduino-s programot rá. Írassál ki valamit és mérjed meg így, meg úgy az ehhez szükséges időt.

Valamikor régebben csináltam egy tesztet ezzel a kérdéssel kapcsolatban. Hagyományos kontra I2C LCD sebesség. A mérések eredményét az "Arduino" topikba fel is tettem.

Ha a mellékletben található I2C illesztőre gondolsz, akkor ez már csak fizikailag sem lehet gyorsabb, mint a PCF8574-es IC kihagyása és a kijelző direkt hajtása. Igaz, utóbbi esetben ha valóban gyors kijelzést szeretnél, érdemes nyolc bites üzemmódban használni a kijelzőt, a kontrolleren pedig direkt vezérelni a kimeneteket (az Arduino függvények/könyvtárak kihagyása szükséges hozzá, azok nagyon lassúak). Cserébe több láb lesz dedikáltan a kijelző részére fenntartva.

Ha jól tudom, akkor az LCD-ből ki lehet olvasni azt, hogy szabad, vagy foglalt. A hagyományos használat ezt nem teszi, inkább várakozik, hogy biztosan szabad legyen, amikor adatot küld. Az I2C úgy tudom használja ezt. Ha szabad, akkor küld neki adatot, ha van mit.
De egyszerűen kipróbálható egy sebesség teszt írásával és kipróbálásával. Én kipróbáltam.

Esetleg olvasd el ezt is, ugyan nem i2c, de LCD meghajtás 3 vagy csak 2 vezetékkel: Bővebben: Link