"("V\003g\007ll\002s \005 \001 \006")" - ez elég katyvasz, szerintem te sem tudod, mi akar lenni.
Helyette használhatnád az egyszerű, szép, szokásos lcd.write(1); parancsot, ahol a szám a karakter sorszámát jelenti...

[/code]

Tudom használni. A 16x2-esen jó is csak a 40x2-esen krix krax az á-betű

Ne az üres helyeket keresgéld, hanem nézz meg egy tutorialt, hogyan kell az egyéni karaktereket használni, mert látom, hogy nem tudod. Kiírásnál nem az á betűt írod ki, hanem csak a sorszámát! Á betűt nem is látsz sem a szövegben, sem a programodban (maximum ha te beleírod mint saját komment).

Ezt sejtettem de honnan tudom hol van üres hely? 40x2esnél próbáltam 0, 1, 2, 8 helyeket de mind krix krax ha á-t akarok írni. Most megnézem más betűvel

Mindkettőnél tudsz tölteni karaktereket a CGRAM-ba. Amelyik karakterkészletébe nincsen, oda töltsél.

Köszi. Akkor szerinted mondjak le az á betűről? Vagy valami hexadecimális kódot kell megadni?
Pont a 40x2-es be van építve még a számát sem tudom megnézni.

Azért van, mert több éle karakterkészlettel készülnek ezek a kütyük.
Link.

Van 2 db lcd-m az egyik ilyen 16x2-es a másik valami ilyesmi 40x2-es. Azt akartam , hogy magyarul írjanak de csak a 16x2-es tökéletes. A 40x2-is jó lenne de az á betű helyett krixkraxot ír a többi ékezetes betű ennél is jó. Miért van ez ?

Pár éve mértem ilyeneket, aztán találtam egy oldalt,amin sokféle processzor esetében megmérték, mekkora sebességkülönbség van a direkt port elérés, és a digitalwrite között. emlékeim szerint: a legnagyobb sebesség különbség ATMEL procik esetén (Arduino nano) volt méghozzá kb. 20x-os, Arduino DUE esetében mértem kb 10x-es sebesség különbséget, a legkisebb különbség pedig ESP8266 esetén volt (a pontos értékre sajna nem emlékszem).

A saját méréseim, amit írsz, és amit erről a neten találtam, nagyjából egybevágnak. A léptetőregiszteres (két vezetékes) megoldásnál kb. 1µs-os időállandót használok az adat/órajel "szétválasztásához", ezért szükség van rá, hogy ennél sokkal keskenyebb impulzust is ki tudjon adni az MCU. Ez azt jelenti, hogy a digitalWrite(), a néhány µs válaszideje miatt nem alkalmas a feladatra, közvetlen port írással viszont könnyedén megoldható. A keskeny impulzusok ellenére, még hosszú vezetékeket használva is üzembiztos, és jól működik ez a megoldás.

Az időnek akkor van (esetleg) jelentősége, ha nem megszakításosan kezeljük a kijelzőt, mert akkor nem mindegy mennyi processzoridőt vesz el. Bár ha úgy nézzük, akkor esetleg a megszakításban eltöltött idő sem közömbös.

A 3 vezetékes megoldás esetén nincs feltétlenül szükség ilyen gyors vezérlése, ez esetben a digitalWrite() használata "csak" annyi hátránnyal jár, hogy 10x lassúbb lesz. Nyilván van amikor ennyi belefér, és van amikor nem.

A digitalwrite annyira azért nem csigalassú. Sok része még fordítási időben lefordul (ha megnézed, csomó ifdef-fel van tele), néhány dolgot ellenőriz csak le, hogy PWM-e a láb, meg talán, hogy kimenet-e. Ez csak néhány órajel pluszban, annyira nem para szerintem. Le lehet mérni, mekkora frekvenciát tud egy
digitalwrite(3,HIGH); digitalwrite(3,LOW); magából kipréselni, meg egy direkt portírás mit tud. De gondolom ezt már mások megtették.
Bővebben: Link
Azt írja, 4-5us (3.4us-ot is találtam már) ideig jelenik meg a low és a high jel is a kimeneten. Tehát a periódusidő 8-10us, ami 100-125kHz-nek felel meg, 16MHz mellett.
Direct port access-szel is legalább 2 órajelig tart a port írása, szóval 16MHz mellett ez 2x0.0625us, vagyis a periódusidő: 0.125us, ez 8MHz lenne, nem tudom, hogy ez lehetséges-e... Timerrel gondolom megoldható, de sima portírással? Le kellene tesztelni... 1MHz tuti menne, mondjuk az is kb. 8-10x gyorsabb, mint a digitalwrite() fv. Mondjuk ekkora sebességnél már a megszakítások miatt lesznek hosszabb magas vagy alacsony részek, szóval megkérdőjelezhető a létjogosultsága az ilyen gyors portírásnak, mikor nem mindig garantálható ez a sebesség (a millis() megszakítása mindig fut!).

Én próbálgattam, hogy az LCD-t gyorsan frissítettem, a folyadékkristály nem tudja követni ezt a gyors változást! Vegül arra jutunk, hogy se nem a kommunikáció típusa, se nem az LCD meghajtója a lassú, hanem a folyadékkristály megjelenési ideje a korlátozó tényező.

Nem gondolnám, hogy lassítani rajta. A shift regiszter nagyon hasonló az i2c-hez, hiszen mind a kettő soros kommunikáció, órajellel, így szerintem a shift regiszteres meghajtás egy teljesen jó, olcsó és egyszerű alternatíva lehet erre. Én kifejezetten szeretem használni a shift regiszter amikor lábakat akarok megsprlórolni.

Van benne valami. A direkt meghajtáshoz, és az i2c-hez van arduino könyvtár, viszont a léptetőregiszteres megoldáshoz nincs, ezért meg kellett írni hozzá.
De ezek után le fogom mérni pontosan a sebességét, és közzéteszem itt. A végén esetleg kiderül, hogy még azzal lesz a leggyorsabb , (vagy az, hogy mégsem )

Igen, ez szerintem is így van. Aztán mivel karakteres LCD-n ritkán játszunk le arduinoval full hd filmeket és az RPG játékokhoz sem terjedt el igazán ez a megjelenítő, így szerintem nem okozhat gondot. Normál használat mellett tök mindegy, hogy arduino, direkt írás, vagy bármi, ahhoz mindig elég lesz a sebesség.

Kivéve ugye, ha az a 6 (vagy éppen 10) láb 3 különböző portra van bekötve... Bár akkor is meg lehet sokkal gyorsabbra írni. Valami olyasmit sejtek a háttérben, hogy mondjuk az arduino saját könyvtára is a digitalWrite() függvényt használja, ami ugyan processzorfüggetlen, és sokmindent lekezel, de cserébe lassú. Ez a megoldás esetleg futási időben ellenőriz sokmindent, míg a portok közvetlen írásánál ez elmarad, ezért sokkal gyorsabb lesz, de cserébe minden processszor esetén kicsit másképp kell megoldani.

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

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

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.

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

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.

2x16-os LCD.

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

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

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.

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.

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.

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.

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

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?

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