Fórum témák
» Több friss téma |
Helló!
Sok vagy nem, ennyi az ára. Hidd el nem nyerek rajta, kérdezt meg MSC-BP-t. Én egyszerre 5öt vettem, mert ennyi a minimum. Én se foglalkozok BGA-val. És a lényeg. 15 Euró nem pénz egy nagyobb TFT-hez képes meg a rengeteg macerához amíg akármi mással életre kelted. Az FPGA se olcsó, és ez itt egy konyhakész cucc. Eladó nincs, mert már megvették a fölös példányokat (3), meg volt még egy komolytalan érdeklődő, vele meg már nem foglalkozom, kettőt meg magamnak tartok meg. Ha a rendeléshez segítség kell átküldöm az email- váltosomat. Egyébként 40-50$é is van megoldás, PICASO uVGA, de az csak 4-8 bites és gyenge.
Szia!
Csak most látom, hogy válaszoltál. Ne érts félre, nem is gondoltam hogy le akarsz engem húzni! Egyszerűen csak több, mint amire számítottam. Egyébként találtam egy másik vezérlőt is, csak ahhoz külön SDRAM kell, ill. az még kevésbé tűnik beszerezhetőnek. (Epson S1D13517) Én most írtam az MSCbp-nek, de valszeg más megoldás után kell hogy nézzek. Szerintem egy Atmel AVR32 (AT32UC3A3xx) egymaga is el tudja látni a feldolgozási és megjelenítési feladatot, mivel elég gyors (66MHz) és 16 bites külső busza van, amire elegendő méretű SRAM-ot, vagy SDRAM-ot tehetünk a grafika részére. Ráadásul az SRAM-on és SDRAM-on kívül még az SDHC és CF kártyákat is kezeli hardveresen. És ez így összesen csak 2-3 ezer forint.
Helló!
Nézz körül youtube-n. Nálam, nálunk sokkal nagyobb játékosok nem hiába használják a Solomon chip-eket, akár PIC32-vel is (80MHZ) A 800x480 kijelzőm pixel clock-ja 25MHz. Tehát 50HMz csak ahhoz kell hogy egy láb fel-le. És még sok minden más is van. Nem fogod ezt tudni belepaszírozni. Ha mégis akkor az a chip vért izzad és semmi mást nem tud csinálni mint egy memória területet szolgai módon kiír. Semmi kép számolás, matekolás, egyenes, kör, stb stb. Ok. ATMEL 2-3e Ft. Azaz 10 Euró. Ez meg 15 és akkor konyhakész. Nekem legalábbis mindjárt.
Szia!
A 80MHz-es PIC32 a MIPS M4000-es maggal nekem is elég szimpatikus, pláne hogy azt még assemblyben is frankó programozni. Csak az a baj vele hogy ott nincs külső hardveres perifériabusz vezérlő, ezért az SDRAM illesztése nem ajánlott, mert túl sok időt vesznek el a szoftveres memóriahozzáfárési ciklusok, pláne hogy még a frissítést is meg kell oldani. (Az SRAM még talán...) Én egyébként még egy olyan lehetőséget fontolgatok, hogy két vezérlőt használok közös SRAM/SDRAM-mal. Az egyik a számításokat végezné és az eredményt a memóriába pakolná, a másik pedig folyamatosan olvasná onnan, és megjelenítené. Természetesen időosztással menne a dolog, úgy hogy a két vezérlő minimálisan zavarja egymást. Viszont ha csak képek megjelenítése, ill. videók lejátszása a cél (pl. SD kártyáról), akkor egy vezérlő is bőven megteszi, és még talán külön grafikus memóriára sincs szükség, mert a belső 32...128k is elég lehet az adatfolyam feldolgozásához.
Helló!
Egyszerűen nem éri meg a nyüg meg a rengeteg programozás. Solomon SSD-t úgy kezeled mint memóriát, PIC-el a PMP-vel hardveresen csatlakozol rá, PIC24 és fölötte DMA-val megtámogatva, csak a memória túlfelén kijelző van amit beírsz az "meglátszik". Igy is elég sok a beállítás, minden TFT-hez kell az adatlapja nagyon pontosan. Elég sok a változó dolog benne, hogy ezt még a saját bizonytalan programmal is "tetézi" az ember, nos nem tudom... Én nem csinálnám.
Nem rossz.
De szerintem a figura raw módban olvassa a videófolyamot a kártyáról. Ha fájlrendszert is kell kezelni, ill a JPEG és MPEG kitömörítést is el kell végezni, akkor azért RAM is kell hozzá (viszont elég a belső is), meg processzoridő.
Azaz te?
 Akkor minden elismerésem! Azért elárulhatnád nagyvonalakban a technikát... Érdekelne az elv. (Feltéve ha nem szigorúan titkos...)
Átnéztem az SSD1963-as doksiját, de sajnos nagyon gyér. A kommunikációt nem igazán részletezi, inkább csak találgatni tudok hogy hogyan is működik pontosan.
A hozzáférés nem épp úgy történik, mint egy RAM-hoz, mert nem lehet címezni a tárterületet. Igazából a kommunikáció adatblokkok másolására van optimalizálva, nem pedig egyedi címek véletlen elérésre. Ez pl. vektorgrafikánál nem igazán előnyös. Egy pixel kirajzolásához előbb be kell állítani az oszlop és sor kezdő- (és vég-) címét (ez 5+5 buszciklus), majd elküldeni az íráskezdés utasítást (1 buszciklus), végül pedig elküldeni a 24 bites pixeladatot 2 részletben (2 buszciklus), mivel a mikrovezérlőnek csak 16 bites a busza (jó esetben). Ez 13 (esetleg csak 8) buszciklus, ciklusonként legalább 5 órajelciklusnyi idővel. Ez elég sok idő egyetlen pixel kirakásához. 32 bites mikroprocival (32 bites) RAM-ot címezve ez egyetlen buszciklus (kb. 4...6 órajelciklus procitól függően). Tehát egyelőre még gondolkodok, hogy megéri-e egy relatíve drága és nehezen beszerezhető vezérlőre támaszkodni, ami nem is biztos hogy kellően gyors az adott feladatra. Ja... az MSCbp-től is visszaírtak hogy 900db a rendelési alsó limit. Kösz, de inkább nem!
Szia
1, a pixeles képernyők nem vektorrajzra vannak kitalálva, hanem betük ikonok grafikai képének megjelenítésére. 2, ezt a protokolt használják szinte az összes sajátramos LCD vezérlőnél. (mobil LCD). Három fajta vezérlés van a grafikus LCD-knél. - memória címzés (adatbusz + databusz kivezetve, nagyobb LCD-t nem is lehetne vezérelni vele) itt legtöbbször 1 adat több pixel - memóriavezérlős, soros vagy 8/16 párhuzamos vezérlés. Ezeknél mind memoriaterület inicializálás után kell azt feltölteni (mint SSD). Igen 1 pixel kirakása nem gazdaságos (persze nem annyi órajel, mint amennyit számoltál), de a betük, ikonok kevesebb órajellel kerülnek ki mint cimzés/adat ciklusokkal Egy kisebb 8x8-as terület memoriacimzéssel 128órajel, területinicializálással: 5+5+1+64=75 - memoria nélküli LCD-k. Ezek a nagyobbak 3,5"-tól Ezeknek a TFT-knek nincs képtároló memoriájuk, csak sor memo. Neked kell minden pixelt kiküldened újra és újra minden frame-ben. Mint a csatolt videoban(#706667) Ez procizabáló... Ha ehhez teszed az SSD-t akkor kapod a 2. típust. Olyan lesz mint az összes memovezérlős LCD. Könnyen kezelhető. Persze vonal rajzolás nehézkes. De ha van saját memoriád (amihez nem kevés és gyors memo kell) akkor csinálhatsz vektoroptimalizált vezérlést is. Ha drágának találod, akkor vegyél Nokia kijelzőt, azon gyakorolhatsz. /Az SSD kellően gyors /Video: SD kártyát inicializál raw területre pozicionál LCD-t nem kell inicializálni, csak tólni neki az adatot.
Sziasztok!
Találtam két linket a nokia E51 LCD meghajtásáról. 240x320 16M szin. http://forum.sparkfun.com/viewtopic.php?f=14&t=20935 http://www.elektroda.pl/rtvforum/viewtopic.php?t=1344700&sid=e2fac4...350eea Van valakinek a témában több infója, minta programja? Üdv István
Üdv!
A memóriával nem rendelkező TFT kijelzőket szükséges bizonyos időközönként frissíteni, vagy újraírás hiányában megtartják állapotukat? (Tehát egy állóképet elég egyszer kirakni, majd megszüntethetjük a további hozzáféréseket?) Én egy LB043WQ1 panelt akarok meghajtani, aminek 24 bites RGB interfésze van. A videóval kapcsolatban: - Hogyan tárolod az SD kártyán a filmet (raw/FAT)? - Tömörítve van, vagy tömörítetlen (pl. MPEG)? - Az olvasás hardveres (busz/DMA), vagy szoftveres (port)? - LCD vezérlése: hány biten, milyen formátumban? "a pixeles képernyők nem vektorrajzra vannak kitalálva" Az alfanumerikus LCD-k mégannyira sem...
Én nem tudom hogy írhattak neked 900db-os alsó limitet... Én 5 darabot vettem, de ha gondlod az egész velük folytatott levelezést elküldhetem neked.
Ha SSD gyér, akkor ajánlom az FPGA-t. A működése pont eléggé részletezve van mert sikerült életre kelteni és a legalacsonyabb gépi szintű rutinoktól kezdve működik minden. Most már BMP-k ki vannak rajzolva, már a 2.0 panel készül hozzá ami már megy a kocsiba és sokkal kisebb mint az 1.0 Van egy mondás: ".@.r" melós a szerszámot hibáztatja. A net az elmúlt 4 hónapban hirtelen tele lett a 1963-al. Tehát annyira nem lehet rossz. 
Szia!
Én nem az SSD1963-ra mondtam, hogy gyér, hanem a doksijára. Persze biztosan ki tudnám tapasztalni a működését, de épp azért van a doksi hogy ne kelljen ezzel tökölni. Az oké hogy leírták az egyes parancsokat, meg hogy egy parancs/adat szerkezete hogy is néz ki a buszon, csak épp ezek konkrét használatát nem. Le tudnád nekem írni egy blokkmásolás pontos menetét? Csak a vezérlőnek kiadott parancsok és adatok sorrendje érdekelne. Köszi előre is!
Szia!
Én még csak a 2.0 verzió nyákján dolgozom, elvileg hétfőn adom le gyártásra. Ez lesz az amiről majd a cikk is készül, illetve ez lesz az amit majd árulni is fogunk, mint hardvert. Aztán tovább építve lehet belőle majd pl 7"-os kijelzővel digitális oszcilloszkóp, LA, és protokol analyser, stb stb, de ez a jövő zenéje lesz. A kollégám csinálja a programot, az 1.0 nyákon ő már végigszenvedte és kitapasztalta a beállításokat, tény hogy a 93 oldal dokumentációhoz tudnánk írni még vagy 50 oldalt hogy normális legyen. Konzultálok vele ma. Most akkor neked van SSD1963? Simi
Sziasztok!
Mit Zsimon fórum társam említette SSD1963 elég jó kis IC. Nem tudom miért fikázod le(Zsora). egyáltalán használtál valaha színes LCD-t.Mert én már egy párat használtam. Nokia, ILi9320,ILi9325,SSD1963 de az utóbbi adta a legnagyobb szabadságot. Akármilyen LCD rá rakhatok és csak 10 byte-ot kell átírnom a programban és már 4,3as helyett 7" LCD-t hajtok vele. Abban egyet értek Zsora, hogy az adatlapja elég gyér. De mégis sikerül életre kelteni szinte 0 ról. Itt van 2 kép hogy frankón működik az SSD. És az 1.0-ás panelról. Tudom nem sok mindent látni de a többit késöbb rakom fel. Most jön a karakter készlet és BMP kép kirajzolása SD-ről. Csak most vizsgáim vannak sajna. Kicsit le lassulok most. Peppe
Nincs, mert nem tudtam beszerezni. Jelenleg megfelelő alternatívákat keresek, és úgy néz ki hogy akad is. Az Atmel SAM9 szériája pl. kifejezetten jó kis cucc.
AT91SAM9RL64: - 240MHz ARM proci - SDRAM vezérlő - LCD vezérlő (max. 2048x2048/24bit TFT) - AC'97 vezérlő Az ára nagyon kedvező; 10€, ráadásul kapható is. A nagyobb modellek gyorsabbak és többet is tudnak, de azok dupla ennyibe kerülnek, vagy többe. Itt az "egyetlen" problémám a fejlesztőkörnyezettel van. Ezt a cuccot már komolyabb ketyerékbe szánták és ez itt meg is látszik...
Üdv!
Nem. Digitális RGB interfészes TFT panelt még nem használtam eddig. De egyszer el kell kezdeni. Valószínűleg először csak szoftveresen hajtom meg, hogy felmérjem a lehetőségeket, aztán jöhet a vezérlő.
Sziasztok!
Mivel egy korábbi kérdésemre még mindig nem kaptam választ, most újra felteszem: A memóriával nem rendelkező TFT kijelzőket szükséges bizonyos időközönként frissíteni, vagy újraírás hiányában megtartják állapotukat? (Tehát egy állóképet elég egyszer kirakni, majd szüneteltethetjük az RGB interfészen az adatfolyamot és órajelet?)
A nagyobb meretu memoriaval nem rendelkezo kijelzoket frame-enkent frissiteni kell. HSYNC+VSYNC.
Ezalatt mit értesz?
Én azt feltételezem hogy az LCD meghajtóáramkörének folyamatosan szüksége van a szubpixelinformációkra, ezért azokat el kell hogy tárolja valahogy. Talán kapacitív elven, vagy egyszerűen csak a folyadékkristály tehetetlenségét kihasználva valósulhat ez meg; így szükséges lehet a folyamatos frissítés. Ha viszont statikus elven az egész pixelmátrixot eltárolja, akkor nem. Valahol találok erről információt? A doksik sehol nem írnak minimális MCLK értéket...
Ird be a googlebe pl. hogy 480*rgb*272
Elso talalatok kozt mar vannak adatlapok. Felnezhetsz esetleg a Varitronix oldalara.
Továbbra sem találok technikai dokumentációt erről a dologról.
 Bár ettől függetlenül az LCD vezérlés mikéntje egyre jobban kezd körvonalazódni számomra. Most ott tartok, hogy az egyes komponensek (MCU, SRAM, LCD) megfelelő összekötésével akár 16-, vagy 8-bites mikrovezérlővel is korrektül megoldható a 24-bites LCD-vezérlés. Ha majd megleszek a cuccal, lehet hogy megosztom másokkal is az e téren szerzett tapasztalataimat.
Ez igen
De érdekes, hogy itt a többség már megcsinálta és utánna rakott fel képet, infót, nem pedig elöbb csak beszélt beszélt... De kíváncsi vagyok hogy el készül-e és hogy fogod megoldni. Van már LCD-d? Touch-al mi lesz? Grafikát hogy kezeled?
Persze hogy most még csak beszélek. Ez olyan érdekes?
Először csinálok ilyet, és elegendő technikai információt kell összeszednem, hogy aztán az elkészítés közben/végén ne legyen (túl nagy) pofáraesés. Végülis azt a verziót választottam, hogy az SRAM és az LCD egy buszon lesz (24bit), és erre kapcsolódik az MCU multiplexált busza (8bit). Az MCU byte-osan kezeli a memóriát, míg az SRAM és az LCD között 24bites kommunikáció megy az MCU irányításával - ha lehet, DMA támogatással. Az LCD már megvan régen (LG.Philips 480x272 TFT), és a vezérlőben is sikerült megállapodnom (ATxmega64). Csak még itt van ez a fránya kérdés, hogy hogyan is kell helyesen frissíteni az LCD-t. (szükséges-e folyamatosan?) Ez ugyanis erősen kihatással van a végleges hardverre és szoftverre. Esetleg ebben segíthetnél, mert te már csináltál ilyet, így biztosan van róla infód.
"szükséges-e folyamatosan?"
igen, 60FPS kellene neki ehhez 9MHz clock kell. (folyamatos adatküldés, különben LCD kialszik és villogni fog) De minimum az 5MHz "ATxmega64" Nem tudom hogy kapsz-e ilyet, mert nekem is csak XMega128 és XMega256 van.
Köszi szépen a választ!
Egyébként honnan van az infó? Tudsz valami elérhetőséget, ahonnan letölthetek erről doksikat? Az általam talált adatlapok ugyanis ilyen adatokról nem beszélnek, ezért nem voltam ezzel tisztában. (Ott csak a függőleges és vízszintes üres tartomány maximális és minimális értékét határozták meg, mert gondolom azokat a jeleket használják szinkronizálásra.) Az ATxmega64 helyett termászetesen használhatok 128kB-os MCU-t is, végülis árban sincs nagy eltérés. Eredetileg az AVR32-es szériát néztem ki a feladatra, de az AVR32 Studio-val meggyűlt a bajom, egyrészt mert a C nyelvvel nem vagyok jóban, másrészt túl komplikáltnak tűnik nekem a használata - ellentétben az AVR Studio 4-gyel.
Sziasztok!
MOst találtam rátok google segítségével. Van egy kis gondom SSD1963-mal, hátha valaki tud segíteni. Szóval van egy 320x240 RGB kijelzőm rajta SSD1963 kontroller a kíjelző típusa (RFC57). Képtelen vagyok inicializálni a kijelzőt. Nincs esetleg valakinek 320x240es kijlezőre helpje ezügyben, forráskód vagy valami? Neten eddig még nem találtam. A másik kijelzőn lévő FSA506 kontroller gond nélkül megy de ezzel küzdés van. Amúgy a forgalmazónál lévő adatlap szerint ezen a kijelzőn is FSA506nak kéne lennie, ezért is rendeltem, de mikor megjött meglepett. Előre is köszi.
Szia!
Sajnos nem tudok adni kijelző init kódot. Viszont én is küzdök egy kijelzővel. 640x480assal szivok már egy hete. Az adatlapban nincs normálisan leirva a vissza futás és stb. Van 480x272es LCDm ami frankón volt dokumentálva és megy is frankón. Szóval olyan LCD-t kell venni aminek ezek az adatok le vannak irva normálisan. Sajnos a vezérlő után kellene nézni. ami a kijelzőn van. Én is ezt tettem. Vagy küld vissza a forgalmazónak a kijelző. És kérj másikat ami jó vezérlős. Ui: hol vetted az SSD1963-at? Peppe |
Bejelentkezés
Hirdetés |
