Szia Watt
Van egy 8 bites RGB szabvány, a 332. Azaz 3 vörös 3 zöld és 2 kék.
Ezt használom nagyon sokszor én is.
Írtam rá egy konvertert, ha érdekel (PIC vagy AVR forrásba kódol)
Az LCD bekötéssel sokat tököltem, hogy korrekt képet adjon. Ha a felső biteket használod R7-5 G7-5 B7-6, és a többi bitet L-be húzod, akkor a fekete az szép lesz, de a fehér nem lesz telített, azaz inkább világosszürke, mert a max érték, ami átmegy az 11100000 11100000 11000000
Ha meg H-ba kötöd, akkor meg fekete nem lesz szép...
Ha az utolsó bitet (R5,G5,B6) kötöd a többire, akkor lesz fekete is szép, meg fehér is szép, de az átmenet lesz igen gáz.
De van ennél sokkal korrektebb.
Milyen LCD-t használsz?

Szia!
Igen, pont ilyesmire gondoltam, és pont ilyesmitől tartottam. Persze nem akkora gáz, mert nem képeket akarok megjeleníteni, csak alaprajzokat, stilizált épületrészeket, szöveget, stb. A fekete lehet, hogy fontosabb, mint a fehér.
A panel amit használni akarok az AT050TN33, csatoltam az adatlapját.
BUÉK mindenkinek!
Zsora, neked is köszi a segítséget!

Képek megjelenítésére se rossz.
Jobb mint gondolnád
Nekem is van ilyen kijelzőm, csatoltam

PS: vezérlő nélkül atmegával hajtottam meg

Igen, ilyen van a GPS-emben, gyönyörű képe van, de nem ezt akarom vele elérni. Grafikus otthonvezérlőt akarok érintőképernyővel. Esetleg egy háttérkép, de már az is zavaró lehet, illetve nem látszik ki, legfeljebb a menük alól. Meglátom, nem nagy kaland továbbgondolni, ha nem okoz erőforrásgondot, de nem ez a cél elsősorban. Be lesz építve a falba a bejáratnál...

Az ATmegával kapcsolatban, milyen frekivel hajtod és hány biten? Én egy CPLD-t akarok egy SRAM-al, amiben 3 kép fér el. A SRAM-ot tölögetem az igények szerint, majd váltok képet. Egy PIC32MX360F512L lenne a kommunikációban és egy Flash tartalmazná a kép és szöveg mindtákat.
Az első gondom a meghajtó nélküli közvetlen vezérlésben az vollt, hogy 10ns alatt kellene a jelnek élt váltania, a PIC32 csak 30ns körül tudná ezt. Egyébként is lassú, ha mást is akarok vele csinálni, én úgy láttam nem működne. Kényelmetlen is lenne. Nem tudom, az ATmega mennyire van leterhelve, és mit tudna még ellátni, ha képeket, touch panelt és egyéb feladatokat(gombok, soros kommunikáció) kéne még ellátnia?
(A panel eladó?, Ha igen, kérlek írd meg priviben az árát! Köszi!)

Watt használj SSD1963 as TFT vezérlőt. Nem kell folyamatosan frissítened a kijelzőt csak ha változik valami.
Akkor lesz időd mindenre.
Én már csináltam ezzel az ICvel vezérlőt.PL

Ez csak egy Atmega... 20 Mhz, az AtXmega 32Mhz-en fut, ott több idő van rá. De ez a kijelző lassú frissítésű, jóval az optimális dotclock alatt is megy.
A házvezérlés/security nem nagy prociigényű, elfér mellette az XMegában, de szerintem PIC32ben is
Ha SD kártya olvasás, majd kirakás 25fps-el megy, akkor interruptos UART meg egyéb grafikai ikonkezelés is menne szerintem. De akkor már inkább ARM vezérlést neki.
Én is hasolnó project előtt vagyok (home+sec), de 7" kijelzőt használok SSD-vel. Peppe szereti ezt az IC-t, én nem, de tényleg hasznos, ha már bent van.
Hány ilyen 5" kijelződ van? Pont ilyen GPS-eket forgalmazok.

Egy se, alkatrészként venném. Azt hittem neked van külön eladó.

Az adatlap szerint 9MHz az órajel, neked mennyivel megy a képen?

Az IC jó, a CPLD-t váltaná ki, de ahol én szoktam vásárolni 4 helyen nem találom...

5"-os az nincs olcsón. 4,3" 480x272 és 3,5" 320x240 van ami korrekt. A 7"-ost én is neten veszem.
Nem kell megcélozni a 9Mhz-t, alatta is jól megy. Persze nem mindegyik LCD szereti. De van amelyiket meg lehet lassan is hajtani és tartja a képet.
SSD-t meg tényleg nehéz beszerezni.
A kedvencem az FSA506, de az is ritka áru

Na jó, de mennyivel hajtod a képen?

Nekem 5"-os kéne, azt írd meg kérlek, melyik mennyi? Köszi!

Miért nem alkalmazol PIC24FJ-t integrált LCD vezérlővel? Ahhoz nem kell semmilyen külső cucc.
Ráadásul már pici is mutatta, hogy még spéci cucc sem kell. Én pl. PIC24HJ-t használok külső SRAM-mal, és így is megy a 16-bites színmélység 90Hz felett is. (Minél kisebb a frissítési frekvencia, annál több idő jut a hasznos műveletekre.)

Lehet, hogy nem egyről beszélünk. Ez egy TFT és 9MHz órajelt kíván és csomagokban kéri az oszlop és sor adatokat, pontos időzítésekkel. Két dolog az, hogy egy képet milyen sűrűn változtatok(pl. egy video képkockái, egy folyamatosan kiolvasott memóriából), és más, hogy milyen sűrűn frissítem a pixeleket. Ennek a TFT-nek a legkisebb frissítése 21Hz körül van, és már ehhez is 7MHz órajel kell. Persze még nem derült ki, mennyivel megy valójában minimum, mert az sokat változtatna a helyzeten, de egyelőre kénytelen vagyok az adatlapra támaszkodni, ha azt szeretném hogy biztosan működjön.
Ha az a feladat, hogy egy memóriból kipakoljam a pixeleket, és eközben a memória tartalmát az igényeknek megfelelően változtatni akarom, akkor a kiolvasások között be is kell tudnom írni! Na ez sem semmi feladat egy PIC-től mondjuk. Egy SD-ből kiolvasott adatokat simán sorba kitolni, sokkal egyszerűbb ennél...

Szerintem meg egyről beszélünk.
Én egy LG-Philips LB043WQ1 típusú TFT panelt hajtok meg, aminél a Pixel Clock 60Hz frissítés esetén 9MHz.
Az időzítési értékek nem annyira szigorúak, hogy ne lehetne ettől eltérni, ezt a doksi is mutatja. 15MHz ennél a max, én pedig olyan 13MHz-cel küldöm neki a pixeladatokat 40MHz-es procisebesség mellett.

Ha PIC24FJ-t használsz, akkor pedig minden maceráról le van a gondod.

Pl. az LB043WQ1 panelnél 25..30Hz frissítésnél már nagyobb háttérvilágítás esetén is alig érezhető a villódzás. A 40Hz pedig már teljesen nyugodt képet ad.

Közben átírod a képet tároló memória tartalmát a következő kép megjelenítéséhez az eseményektől függően? Gyanítom csak egy SD memóriából olvasgatod be és pakolod ki a kimenetekre az adatokat.

"Gyanítom csak egy SD memóriából olvasgatod be és pakolod ki a kimenetekre az adatokat."
De hiszen minden videóvezérlő ezt csinálja.
Az általam írt kockaforgatásnál pl. az LCD frissítés az 1/50 másodpercenként meghívott megszakítási rutinban futott le kb. 0,01s alatt. A gombok figyelése, az egyes rutinok és a rajzolás pedig a főprogramban ment. A frissítés teljesen független minden mástól, így akár egy külső TFT vezérlőt is alkalmazhatok, (és alkalmazok is, csak annak még nem ültettem be a paneljét.) amivel megduplázhatom a feldolgozási sebességet. Így a 24-bites megjelenítési módot (RGB888) már nem csak állóképek megjelenítésére használhatom, hanem számításigényes mozgóképekhez is.

Nálad mit jelent az, hogy LCD frissítés? Konkrétan mit csinál ilyenkor a program 20msec-enként? A te LCD-dben nincs véletlenül memória és egyéb meghajtó áramkör? Azért értetlenkedek, mert egy mondjuk 40MIPS-es utasításvégrehajtás 10MHz-es folyamatos órajelet úgy tud előállítani, hogy gyakorlatilag nem marad másra ideje a lábak kapcsolgatása és ciklusba szervezés miatt. Esküszöm, valamit nagyon nem értek!

1 LCD frissítési ciklus az, amikor a TFT panelnek elküldjük a 480x272db színinformációt. (Plussz a szükséges szinkronizálási és üres ciklusokat.) Ez kb. 0,01s. A maradék 0,01s pedig a fő műveleteknek van fenntartva.
A színadatok a külső 16-bites SRAM-ban vannak, mert a TFT panel nem tartalmaz saját memóriát, és az MCU-ban sincs elegendő mennyiségű. Azért kell azt folyamatosan frissíteni, mert anélkül a kijelző kb. 1s alatt teljesen kifehéredik. Jelenleg az én cuccomban a PIC közvetlenül hajtja meg a TFT panelt, nincs semmilyen kiegészítő áramkör. (A 24 bites módhoz azért van egy plussz multiplexer.)
A 40MIPS sebességű PIC24HJ 20MHz-es jelet tud előállítani, és mivel a frissítési ciklusok 0,02s-onként jönnek (50Hz esetén) és kb. 0,01s hosszúak, gyakorlatilag olyan mintha a fő műveleteket egy 20MIPS-es proci végezné. (Tehát van elég idő.)

"SD memóriából"
Azt hiszem félreértettelek az előbb. Szerintem te SD kártyára gondoltál, én viszont SDRAM-ra.
Nem. Nem SD kártyáról jön az adat. (Még nincs kártyaolvasóm, de tervezem azt is képek és videók lejátszásához.) Bár SDRAM-ot sem használok, hanem DRAM-ot.

Na én itt akadok el. Miféle maradék idő ez? A TFT nem igényli, hogy folyamatosan nyomjad bele az adatokat? Én nem láttam az adatlapban olyat, hogy lehet szünet két kép között, főleg nem egy egész képnyi.

Nem igényli, ez benne a lényeg.
Igaz, nincs benne az adatlapban, viszont az elenkezője sincs benne. Bár ha belegondolsz; a függőleges és vízszintes üres intervallum is szünetnek számít, ami viszont szükségszerűen kell a vezérlőelektronikának..
Egyedül az a kritérium, hogy az MCLK max. mennyi lehet, ill. hogy minden pixelt egy adott idő alatt frissíteni kell.

Szép, én meg folyamatosan azon görcsölök, hogy hogy a fenébe van idő másra, ha állandóan nyomni kell belé az adatokat!

Ez mennyi idő is? Én ilyen adatot nem találok. Főleg nem 0,01..0,05sec időket.

Az is érdekelne, hogyan állítasz elő 20MHz-es ütemmel adatokat a kimenetre a 0,01sec-es kiérési ütemhez, főleg, miután nem is bír ekkora frekit a TFT(a tiéd igen?). Vagy még kisebb ütemmel működik végül is? Valami speciális adattovábbításra emlékszem a 24F-ektől de most nem tudom, hogy ezt képesek-e kinti adatforrásból is biztosítani...

"Ez mennyi idő is? Én ilyen adatot nem találok."
Én sem találtam fél évvel ezelőtt, amikor itt kérdezősködtem. Az adatlap nem tartalmazza a minimális értéket. Pusztán tapasztalat, hogy az adott LCD-nél mi az ami még elmegy.
Én is aggódtam először, mikor véletlenül 97Hz-en hajtottam meg a panelt, (az adatlap max. 70Hz-et ír)de nem lett semmi baja, korrektül ment azon a frekvencián is. Végülis nem léptem túl az MCLK max. értékét. (15MHz)
Először csak kb. 40Hz-es frissítést sikerült elérnem üresjáratban, de később optimalizáltam a kijelzőrutint, és a pixelenkénti 3 utasításciklus lehetővé tette a 97Hz elérését.

Így érthető, elárulod melyik az a 3 utasítás és hogyan sikerült a ciklusokat úgy szervezni, hogy ne vigyen el időt? Gondolom beolvasod a RAM-ból, majd kiteszed egy PORT-ra. Aztán növeled a címet, és kezded előről. Közben az órajelet is piszkálnod kell. Jelenleg el sem tudom képzelni, hogy fér ez bele...

Az az igazság, hogy elég egyedi architektúrát használok, ami teljesen saját fejlesztésű, és egyelőre nem publikus. (Még fejlesztés alatt áll.) Fő szempont volt a gyorsaság és a sokrétű felhasználás. (24-bites fényképek, filmek, vektorgrafika, játékok, egyéb)

Bár a kütyüm kifogástalanul működik, mégis neked én a PIC24FJ256DA210 mikrovezérlő használatát javaslom, mivel ahhoz csak egy olcsó SDRAM kell és kész. Semmi macera, a videómemóriát rendszerRAM-ként címezheted, a kijelzőt csak inicializálod és már nem is kell vele többet foglalkoznod. A támogatottsága is elég jó; van hozzá grafikus fejlesztőrendszer.

A három utasítás:

Köszönöm a válszt! Igazán nem akarlak faggatni, ha nem publikus, ezért csak hangosan gondolkodom. Ha ezt a három utasítást csak ciklusba kell szervezni, akkor az időben egy 40MIPS-es utasításvégrehajtásnál:
A három említett sor: 3*25ns
Ezt meg kell ismételni néhányszor, az egyik lehetőség a ciklus. kell ciklusszámláló, és kell egy elágazás, vizsgálat és egy ugrás. Ez saccra minimum 4*25ns, Ezután a DE jelet is viszgálni kell, azt már nem is számolom bele...
Amit számoltam csak 8*25ns, azaz 200nsec, azaz 5MHz... Tehát ez így nem működik, valami mást kellett kitalálnod.
Arra gondoltam, hogy miután van flash elég, ciklusba egész H sorokat, illetve DE cikludokat szerveztél, miután azok váltása között van idő. Tehát ha jól sejtem 480 ilyen 3-as csoport van gépiesen egymás után írva, majd utána DE=0 és várakozás, ciklus itt elfér stb.

Mégegyszer köszönöm a sok segítséget és ha hülyeséget írtam csak jelezd!

Jó a gondolatmeneted.
Ehhez a sebességre optimalizált rutinhoz társul a megfelelő hardver...

Gondolom a RAM folyamatosan engedélyezve van és olvasásra állítva, valamint ha DRAM, akkor a frissítésről is gondoskodni kell, bár ha olvasod folyamatosan és megfelelő címeken vannak az adatok, akkor a frissítés megtörténik magától(most nem emlékszem a RAS, vagy CAS címeken kell végigsöpörni... .

Valószínű nekem is menne a dolog, hogy rávezettél. Ennek ellenére most nagyon CPLD-re buktam rá, egyrészt ezt is el kell kezdeni, másrész sokkal kényelmesebben lehet majd a programot szervezni, nem utolsó sorban a CPLD nagyon gyors, nagyobb TFT-ket is célra tűztem és ha sikerül az alap huzalozást kialakítanom, könnyen lehet váltani a bitek és a felbontások között.

Mégegyszer köszi a segítséget és sok sikert a project-hez!

Sziasztok.

Azt szeretném kérdezni hogy van egy kijelzőm amin HX8347 vezérlő van. Az lenne a kérdésem hogy egy PIC24FJ256DA210 vel szeretnem meghajtani most raknek be 1 sram-ot amibe raknam a kepeket pl. és az rakná ki a kijelzőre ez igy müködhet elvileg? Vagy semmi értelme az sram-nak.


Köszi.

Szia
Az SRAMnak "semmi értelme".
Mert ugye ha bekapcsolod, akkor "üres" fel kellene tölteni... de honnan? Pl epromból?
Mert akkor abból is mehetne direktbe.
Ha sok képed van, akkor SD kártya a megoldás.
Vektor ábrázolást csinálsz, akkor elég a uC RAMja.
Ha matematikai ábrákat akarsz számolni (fraktál) akkor sok RAM kell, de erre használhatod a HX8347 memoriáját is, azaz írod és olvasod...
Akkor kellhet csak SRAM, ha pl kameraképet akarsz feldolgozni...