Soovitage värviLCD-d

[felch]

Ühesõnaga, tahaksin oma skeemi LCD-d, mida saab istutada prose (nt. PIC) siinile, reso võiks olla 320*240 (või rohkem), värvisügavusest... piisaks isegi 7 värvist. Ilmselt on lähim number 4096. Võiks omada (või lihtsalt lisatav) kilega taustavalgustit.
Väga tore, kui omab puuteekraani (kilest piisab, dekodeerin ise).
Voolutarve võiks olla minimaalne võimalik, mõõdud: laius mitte üle 73 mm, pikkust võib olla rohkesti. Noh, ja oleks hea, kui ei maksaks palju...
Vastukäivad nõuded, tean küll.
Ühe sarnase leidsin Ronexist: http://www.ronex.ee/index.php?produc...&group_id=1702
Paraku on ta liiga lai, muidu enam-vähem (tiba kallis ehk).
Ahvatlev on ka Tevalo oma: http://www.tevalo.ee/cgi-bin/web_sto...artnr=615-7809 - odav, kuigi tiba pisike. Paraku on sisendiks videosignaal. Vaevalt et teda annaks ümber mudida?
Ehk on keegi millegi sarnase peale sattunud?
Tänks!

[digital]

Vs: Soovitage värviLCD-d

Niipalju kui mina neid olen näinud ja kasutanud, on kõik ikkagi LCD interfeisiga, st parallel RGB. Tavaliselt 5-5-5 või 5-6-5 bit liides + clock + sync'id. Videomälu on juba kontrolleris endas ja see skaneerib pidevalt pilti, displei enda sees on väga minimaalne digi-analoog muundi ja ridade/veergude loendurid+draiverid. Sobivaid ARM jms kontrollereid sisse ehitatud LCD interfeisiga on küllaga, enamasti on nad küll käsitsi väga kehvasti joodetava korpusega.
Vajadusel annaks juurde leiutada videoadapteri (või siis kohe rauas mingi spetsialiseeritud pildi generaatori) CPLD+SRAM või FPGA peal suhteliselt lihtsalt.

[felch]

Vs: Soovitage värviLCD-d

Jah, paraku on nad tõesti ilma kontrollerita. Selline on mul tegelikult isegi olemas, tüübinimi: ACX704. Puuteekraan, taustavalgus ja puha. (http://www.alldatasheet.com/datashee...Y/ACX704.html). Vaatasin, et talle on vaja anda hulka erinevaid pingeid jms. sodi. Interfeis muidugi sama, nagu Digital kirjutas. Kontrollerit on tüütu aretada.
Ronexi omas on kõik ühes koos aga paraku natuke lai ja kallis.
Äkki teab keegi veel mõnda displeid?
Kas TV-sisendiga isendite skeemi annab muuta et saaks otse prose külge pookida?

[raivo]

Vs: Soovitage värviLCD-d

Ronexis pakutav on värviline LCD- see on visuaalselt märgatavalt kehvema pildiga kui TFT.
offtop, aga mu arust picile vm alla ARM7 prosele sellise resoga molu pookimine suht möttetu - graafika läheb kuhugi sinclair spectrumi klassi.
ise vaataksin selleks otstarbeks integreeritud lcd draiveriga proset ( Sharpil ja Cirrusel ARMid olemas, Digikeys saadaval).

[felch]

Vs: Soovitage värviLCD-d

Ma tahan LCDd kasutada põhiliselt spektri ja selle mingite erihuvi pakkuvate piirkondade kuvamiseks. Põhimõtteliselt saaks hakkama ka monokroomsega (nii töötas eelmine versioon) kuid värviline on ülevaatlikum. Samuti ehk, kui suudan MapWindow kaardiajuri porteerida, ka maakaarti. Seega ei pea graafikaomadused olema tingimata nii head, kui videopildi vaatamiseks.
Hakkan üha enam arvama, et kõike seekord ühe prose sisse ei mahuta ja võib-olla peaks tõesti ARM-i vms. jätma puhtalt pildi töötluseks. Analoogsignaaliga tegeleks siis dsPIC või sarnane DSP.
Kui nii, siis saaks isegi PIC ekraani LCD-interfeissiga hakkama.... Muidugi oleks mugav, kui leiaks ikkagi prose databussiga ekraani.

[KaruTEC]

Vs: Soovitage värviLCD-d

Mina olen mõelnud et võiks kasutada TFT "pildiraame" mis maksavad juba alla kilo. Interfeisi saab äkki USB abil teha. Ei ole väga süvenenud.

[andreie]

Vs: Soovitage värviLCD-d

(väga teemast välja)

Felch, ma ei saa mitte märkimata jätta, et

ühe prosega lahendusel on suured eeliseid multiprose ees, multiarhitektuuri ees veel rohkem:
1. kahte arenduskeskkonda on märksa keerulisem vallata-hallata kui ühte.
2. prosedevaheline suhtlus on ekstra ora tagumikus.
3. kaks ISP/JTAG programmaatorit on kõvasti kohmakam kui üks
4. kui muudatuste tegemiseks on vaja koodi uuendada mõlemas proses, siis läheb selleks mitte 2, vaid 2 kuubis = 8 korda rohkem aega.

Muide, kui impulsside tuvastamiseks kasutatavas algoritmis põhitsükkel ei ole skalaarkorrutis andmete- ja filtrikonstantide vektorist, ("MAC" - multiply and accumulate), siis ei pea ennast kitsendama DSP-dega.

[digital]

Vs: Soovitage värviLCD-d

Kui sa just ei pea renderdama korraga pilti ja sämplima uusi andmeid, siis pole kahel prosel küll mõtet. LCD pildi generaatorid on täielikult rauas tükid. Seadistad talle mingi mäluala framebufferiks ja lihtsalt joonistad oma arvutustulemused framebufrisse. Sealt juba edasi tehakse kõik rauas.
Cirruse armi olen kasutanud. Toimib aga ei ole kõige mugavam initsialiseerida, vajab kas ARMi JTAG'iga mingi initsialiseeriva loaderi laadimist, JTAG'i kaudu boundary scan'iga flashi progedes (sigaaeglane) või siis mingi välise lahendusega flashi kivi progemist. Pigem võtaks atmeli vms arm'i, millel on sisse ehitatud pisike ROM seriali või USB device kaudu ISP jaoks. Paned ainult jumperi peale, asi buudib sisemisest rom'ist ja saab vastava softiga arvutist asja ära progeda. Jumper maha, restart ja rokime. Progemiseks võib näiteks WinARM'i poole vaadata.

[raivo]

Vs: Soovitage värviLCD-d

Cirruse armi olen kasutanud. Toimib aga ei ole kõige mugavam initsialiseerida, vajab kas ARMi JTAG'iga mingi initsialiseeriva loaderi laadimist, JTAG'i kaudu boundary scan'iga flashi progedes (sigaaeglane) või siis mingi välise lahendusega flashi kivi progemist.

Millist täpsemalt ? kas ARM7 vöi 9 ? äkki saite ka Linuxi peal käima ?
(pakub väga huvi väike ökonoomne linuxi rakendus, eelistaks küll SH4 pealt aga sellele pole peale jaapanikeelse toe muud loota ).

[ledelectronics]

Vs: Soovitage värviLCD-d

Soovitaks Gameboy Advance, kuid reso kahjuks väiksem kui sinu speksis. Aga selle eest sigaodav ja 15-bitine värvisügavus + väike voolutarve.

Ebaselgeks jäi, kust tuleb pildiinfo - prose kaudu või analoogvideo?

[felch]

Vs: Soovitage värviLCD-d

Pilt tuleb prose kaudu - menüüd jms. Ehk ka maakaart, kui oskan seda teha.
Äkki viitad tollele Gameboy ekraanile? Ja kuskohast teda leida võiks?

[ledelectronics]

Vs: Soovitage värviLCD-d

Nagu vististi varemgi mainisin, ei ole ma GBA-d lahti kakkunud, et ekraani välja võtta. Ise kasutan konsooli ühes tükis, ekraanile manan pildi link-pordi kaudu. Resolutsioon 240x160. Mu seade:
http://farm1.static.flickr.com/155/3...82f2f1.jpg?v=0

GBA kohta asjalikku infot:
http://www.reinerziegler.de/GBA/gba.htm

GBA leiad eBayst.

Muide, pole näinud paremat päikesevalguse käes toimivat LCD ekraani kui seda on GBA-l. Vaata ja imesta:
http://www.dunehaven.com/images/gba_lcd.jpg

Kuna mainisid maakaarti, siis üks näide GBA rakendusest leiad siit:

http://www.msh-tools.com/GBA/gbagps.html

[digital]

Vs: Soovitage värviLCD-d

Millist täpsemalt ? kas ARM7 vöi 9 ? äkki saite ka Linuxi peal käima ?
(pakub väga huvi väike ökonoomne linuxi rakendus, eelistaks küll SH4 pealt aga sellele pole peale jaapanikeelse toe muud loota ).

EP93xx seeria peal on juba päris mitu aastat meil linuxiga asju tehtud. Kuid nagu öeldud, arendamise seisukohast on Atmeli AT91SAM9 seeria märksa kasutajasõbralikum. Ilma ARM'i multi-ice'ta on cirrust maast lahti päris raske saada (kuigi ka seda on tehtud, näiteks fpga peal boot nor flashi emuleerides)

[raivo]

Vs: Soovitage värviLCD-d

vaevalt et ka atmel probleemidevaba on, liialt on nad üle nurga laskma hakanud, errata listi ei peeta kuigi hoolikalt, datasheetid lähevad "preliminary" statusest otse "obsolete". vähemalt minul on piisavalt probleeme olnud atmega8 ja atmega128-ga,kusjuures ei häiri mitte niivörd viga ise ( partii M8 ei lase 8MHz sisemist klokki panna), kuivörd selle eitamine.
aga see selleks, kas EP93xx sisemist math-protsessorit linux kasutada oskab ?

[digital]

Vs: Soovitage värviLCD-d

kõigepealt vigade parandus... sharpi arm'il ei olnud sisemist rommi. cirruse omadel täiesti oli ja oskas serialist üles laadida; atmelil oskas nii serialist kui ka usb'ist end üles laadida.
kuna meil pole vaja läinud mingit tõsisemat matemaatikat ega floatingpointi, siis siiani ei ole uurinud math coprocessori kaasamist ja kasutasime softfloati.