A kijelző frissítése ráér, már kb így is 1másodperc alá mentem, de így is befagy a dolog az i2c-k delay-e miatt...
Abban bízom, hogy talán a közvetlen bekötéssel, nincs, vagy csak minimális kétirányú kommunikáció van, amit nem is értek minek kell, a kijelző vegye az adatot, és jelenítse meg, amikor megkapja a biteket, tudom naiv vagyok...

"befagy a dolog az i2c-k delay-e miatt..." - ezek szerint neked teljesen mindegy, hogy hogyan hajtod meg az LCD-t, ha a programod hibás, pl. az I2C nincs rendesen lekezelve.
Én simán 4biten hajtom az LCD-t, és 50-100ms-ként lehet simán frissíteni (ilyenkor persze a szemnek zavaró a gyors változás, pl. gyorsan változó számot le se lehet olvasni rendesen). Én általában 200-500ms-ként frissítek egy értéket.

Amit szeretnék az, hogy ha kiküldök egy lcd.cleart() akkor ne álljon meg addig a programom, amig nem végez vele. Minden megoldás érdekel, ami kihúz ebből a gödörből, 3 hete nem haladok

Nekem kb 1 másodpercenként az első 3 karaktert van időm kiírni most. Ha e felé megyek, kicsúszok az audiobufferből

Ne használd ezt a függvényt. Nagyon lassú. Helyette ha egy értéket akarsz változtatni, aminek fix helye van, menj oda a kurzorral, írj ki néhány szóközt (amennyi helyiértéked van), menj vissza a megfelelő pozícióra, és írd ki a szóközök helyére az új értéket.
Ha profin írod meg, akkor ha 265 266-ra vált, csak az utolsó 5-öst kell átírnod 6-ra, még szóköz sem kell. Ez olyan gyors, hogy gyorsabb nem is lehet!

Már azt is megoldottam, hogy külön lcdbuffert csinálok egy tömbben, és csak a változást írom ki, ami tök király lehetne, de sajnos ez sem segített...

Ha csak kevés időd van az LCD meghajtására, akkor vágd 4 részre a kijelzőt, és részenként frissítsd, mondjuk 100ms-ként. A szemed észre sem fogja venni.
A törlés parancs tart a legtovább (meg a return home parancs), igazából a függvény amit használsz is "hibás", hiszen ha kiadod a törlés parancsot, nem kell várnod, amíg az kész van! A fv. pedig megvárja azt az 1.53ms-ot, és addig blokkol. Bolondbiztosra van megírva, hogy nehogy törlés után azonnal írni akarj az LCD-re, miközben az még szépen törölgeti magát, mert akkor nem fog megjelenni rajta amit szeretnél. Bele kell kicsit folynod, hogyan működik az LCD, milyen parancsokat kap, mennyi ideig tart, amíg ezeket végrehajtja. Google: lcd 1602 pdf.

Itt a forrása az lcd.clear függvénynek, még oda is írják, hogy ez sokáig tart

Köszi! Pont ezt szeretném! Hogy ne kelljen megvárnom, amíg elkészül. Cserébe én is betartom az írásidőt. A 4 rész nem rossz ötlet, még megfontolom, egyenlőre, lehet a program jellege miatt célszerűbb egy változásfigyelés, mivel egyszerre tutira csak egy paraméter változik...

Akkor az úton elindultál, már csak bele kell magad kicsit ásni, hogyan lenne a legjobb, mennyi időd van, ne legyen zavaró sem, stb.

Igen láttam, csak azt nem értettem, hogy miért kell ezt végigvárni...

Visszakanyarodva a legelső kérdésedre, miszerint 8bit-en gyorsabb lesz-e az LCD: - nem sokkal, mivel a 2ms-ot mindenféleképpen kivárja az lcd.clear függvényed, az adat küldése pedig sokkal gyorsabban végrehajtódik (ott is várakozás történik!).
Esetleg keress egy no delay lcd libraryt. Meg lehet oldalni interrupttal is, és akkor felszabadul a procid, sosem vár az LCD-re. Komplikáltabb megoldani, nem tudom, hogy megoldották-e már ezt a problémát: Bővebben: Link.

Ok, még egy kérdés: Tehát 4, vagy 8 bites módban gyorsabb leszek mint i2c-vel?

8bit dupla olyan gyors mint a 4bit, I2C szerintem ugyanolyan gyors (esetleg kicsit lassabb is!), mint a 8bit (mivel az I2C is utána 8biten hajtja az LCD-t).
Azt olvastam még, hogy ha egymás után több karaktert küldesz az lcd.print-tel, a print úgyis a write függvényt fogja meghívni karakterenként, ami azt fogja okozni, hogy blokkol, amíg az összes karakter át nem ért. A blokkolást ki tudod számolni, ez az LCD adatlapján szerepel. Ha egyszerre kevesebb karaktert küldesz, hamarabb felszabadul a proci, jut ideje másra.

Valaha 100 éve csináltam karakteres Lcd driver-t, fel is van töltve a github-ra. Mondjuk pont arduinora nem készült el (és már nem is fog, hacsak valaki meg nem csinálja). Több működési mód közül is lehet választani, de ami közös mindegyikben az, hogy egy "frame buffer"-be kell belerakni a megjelenítendő szöveget. Beállítható olyan üzemmód is, hogy timer megszakításból a főprogramtól teljesen független módon, beállítható sebességgel (LCDFRAMEPERSEC) megszakításonként csak 1 karaktert kiírva (mert így nem kell várni a kijelzőre) folyamatosan söpri ki a frame buffer tartalmát a kijelzőre. Ez egy 8 bites PIC-en vagy AVR-en 20-30 frame/sec sebességet beállítva is mindössze 1% körüli processzoridőt emésztett fel. A driver extraként tud villogó karaktereket is megjeleníteni, saját karakterkészletet feltölteni, futás közben a karakterkészletet módosítani, meg még egy csomó egyebet.

Köszönöm a segítséget! Átgondolom a folytatás mikéntjét

Az is elképzelhető, hogy valami más gondod van, mert a 2ms kijelző törlés se olyan sok idő. Nem lehet, hogy az AVR-ed folyamatosan az interruptokat pörgeti, és semmi másra nem marad ideje? Ebben az esetben megértem, ha az LCD hibásan ír ki, hiszen ha túl sokáig tart a delay, hibásnak értelmezi az adatot.
Azt írtad, megírtad már, hogy egy tömbbe tárold az LCD-n szereplő karaktereket, és csak azokat frissíted, ami változik. Ha ez jól működne, nem lenne gondod. Ott ugyanis lcd.write-ot kell használod (1 karakter frissítése), ami ha lefutott, azonnal visszaadja a procinak a szálat. Jöhet az interrupt ha akar, ha lefutott, jön a következő karakter.

Igen én ezt vártam volna eleve a LiquidCrystal library-tól, de most már értem, hogy bolondbiztosra tervezték inkább...

"megszakításonként csak 1 karaktert kiírva" - ez tetszik!
Ami nekem hiányzik, az az ékezetes karakterek használata.
Megírtam már, de rettentően sok programsor.
Tehát ha van egy tömböm, amiben egy szöveg van, ékezetes karakterekkel, akkor az jelenjen is meg az LCD-n. Egyéni karakterekkel (az ö és ü pl. benne van az LCD-ben), automatikus egyéni karakter helyfoglalással (ha az á betű már szerepel az LCD memóriájában, akkor azt hívjuk meg ismét), stb.
Azzal is jó sokat elszórakoztam, hogy felismerjem, a tömbben ékezetes karakter a következő (ugye 2 byte-on tárolódik).
Egy ilyen könyvtárat korrektre, picire megírni hát nem kis feladat!

Nincs neki ideje, audiobuffert számol másodpercenként 44100szor

Első körben próbáld meg karakterenként frissíteni, ekkor blokkol a legrövidebb ideig. Akár az egész LCD-t is újraírhatod karakterenként, ha közbe jön az interrupt, gyorsan lefut, majd folytatódik az LCD frissítése. lcd.print-et használhatsz, de csak így: lcd.print('5'); Ezt is be lehet egy saját függvénybe szervezni, hogy ne legyen csúnya.

Ok még egy próbát teszek...

Nagyon szuper a könyvtárad! Szépen megírtad.

Úgy néz ki sikerült, most működik is a múltkori elképzelés. Elvileg az audiobuffer kiírásakor meghívom az lcdrefreesh függvényt a főprogramból, az csak akkor ír ki karaktert, ha tényleges változás volt jelezve a lcdchanged tömbben. A program más részein meg meghívom az lcdkiir függvényt, aminek most két kész szöveget adok át, ezt ő beírja a tömbbe, és jelzi, hogy változás volt, ahol nem ugyanaz a karakter. Az oszlop paraméterrel tudom eltolni a szöveget majd a későbbiekben stb...

A forrást nézve az az LCD meghajtására digitalWrite() függvényt használ. Ilyenkor jogos az a felvetés, hogy van-e spéci sebességű láb? Van. A digitalWrite() függvény mindig megnézi, hogy az adott láb timer láb-e, és ha az, akkor lekapcsolja (biztos ami biztos) alapon a timert erről a kimenetről. Tehát talán elérhetsz sebességnövekedést, ha a timer lábakat kihagyod a játékból. Illetve átírhatod a forrást úgy, hogy digitalWrite() helyett az adott láb regisztereit kungfuzza.

Jó reggelt Mindenkinek!
Egy kis segítséget szeretnék kérni. Egy egyszerű reflexidő mérő programját szeretném megalkotni. A működése egyszerű, egy LED bekapcsolásakor a millis() függvénnyel kiolvasom a számláló értékét, majd egy nyomógomb lenyomásakor ismét kiolvasom a számlálót. A két értéket kivonom egymásból, és a kapott érték a reflexidő. A problémám az, hogy a különbség mindig 0. Ha bármelyik változó helyére egy konkrét számot írok, működik, ha összeadom a változókat, működik. Valamiért a kivonás mindig 0-át ad vissza. A változók, az eredmény is, unsigned long típusú.
Miért nem működik a kivonás? Ebben szeretnék tanácsot kérni!

Program nélkül senki sem fogja tudni megmondani...

Valószínű a hidegfront végett. Kód?

Bocsi!

De hát ki sem vonod az ido_uj-ból az ido_oldot, ami ráadásul pont fordítva lett elnevezve...
Ezt meg a kivonás kiírás után kéne, hisz felülírja: ido_uj=millis(); (20. sor)