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á)

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.

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.

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?

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.

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

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...

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.

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.

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.

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.

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

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)

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

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.

Csak még azt had kérdezzem meg , hogy ha I2C mellett van egy DS3231 RTC sda/scl-en akkor úgy se lassú?

Nem lesz lassabb tőle. Az i2c-nek jóval nagyobb az áteresztő képessége, mint amit az LCD tud sebességben. Bármit kötsz elé/mellé nem fogja érdemben lassítani. Amúgy mit szeretnél készíteni, amihez nagy sebességre van szükséged?

Közvetlen párhuzamos vezérlésnél nem lassabb.

Csináltam egy tesztet. 10-szer egymás után teleírtam mindkét sort az LCD-n. Törlés nem volt, csak felülírás.
4 biten: 74 millisec.
I2C alap sebességen: 244 millisec.
I2C 800000-es sebességen: 66 millisec.
Arduinós könyvtárakkal, Nanót használva.
Persze házilag lehet gyorsabb dolgokat írni, de most itt nem az lett mérve.

A 66-74ms az azért nem is olyan rossz. Másodpercenkent az 130-150 teljes kép, de egyik se tűnik nagyon rossznak.
Persze, mindig lehet mindenen javítani, meg jobban írni, csak nem biztos, hogy érdemes. Alapból az arduino se optimális, de mivel ritkán fejleszt benne az ember kritikus dolgokat, így sokkal jobb és könnyebben lehet vele haladni, mintha assemblyt tolna natívan, ha az kell, akkor meg még mindig ott a lehetősége.

Ezek a függvénykönyvtárak működnek az LCD-vel a 32 MHz-es LGT csippel is. Ha kell a gyorsaság, akkor azokkal a csippekkel ezek az idők feleződnek.

Nem a chip a lassú, hanem a szoftver van úgy megírva. Kb. 2...4ms alatt tele lehet írni a kijelzőt, de ha minden fügvényhívást stb.. beleveszek akkor sem kellene még 10ms sem.
Persze ha az idők a 10db írásra vonatkoznak (ez számomra nem volt egyértelmű) akkor annyira nem vészes, kivéve az i2c 244ms-ot, mert az még 10 teleírás esetén is sok.

Az idők 10 egymás utáni írásra vonatkoznak. Gyakorlatilag 20 sor írása.

Végülis annyira nem rossz, de nem is jó.
Nem írtad milyen kijelző, de átszámolva µs/karakter-ra ez jön ki a 66ms-ból:
2x16-os kijelző: 206µs/karakter
4x20-as kijelző: 82µs/karakter

2x16-os LCD.

Eleve azért hibás a mérés, mert a kimenetek vezérlése (az LCD direkt hajtása) Arduino könytárakkal a csiga sebességéhez igazodnak.

Akkor a használt Arduinós könyvtár ezek szerint elég lassú.

Az alap kérdés az volt, hogy Arduinóval melyik a gyorsabb. A 4 bites, vagy az I2C.
Igen, csiga lassú az Arduinós könyvtár, mert még 32 MHz-en sem téveszt az LCD ezekkel a könyvtárakkal.

Igen, mert ugye eljátszani minden karakternél, hogy:
Melyik lábon van a D0? 7. Az a láb legyen 1, vagy 0.
Melyik lábon van a D1? 8. Az a láb legyen 1, vagy 0.
...4 biten 6, 8 biten 10 lábra
kicsit több idő, mint egy, PORTB = 0x31

Nem azért lassú. Az i2c sebessége nem a processzor órajelétől fog függeni, és vélhetőleg a direkt meghajtásé sem. Tehát nem a processzor sebessége miatt lassú vagy sem.
Egyébként egyik módszer sem téveszt, sem 16MHz-es processzorral, sem 80MHz-essel, amíg nem lépi túl az említett 50µs/karakter sebességet. Ez a sebesség a programba épített időzítésektől függ, és nem a processzor órajelétől.

A léptetőregiszteres megoldás esetében pl. az arduino delayMicroseconds() függvényét használtam, ami bár nem túl pontos, de azért jól használható.