CS ja BLS

[murphy]

Selline proble et LCD vaja pista 24 biti ühendisega prose külge, AGA keegi tark tegelane arvas et võib pista SRAM-i jaoks vajalikud otsad(BLS2 BLS3) lcd otste alla. plaanis ka SDRAM aga see tatt aeglane seega mõtetu sinna pista grafkat. Varjant oleks kasutada 16 bitti ühendust aga kardan et see jääb prose ressuressi piirama ja siis pole enam vahet kas SDRAM või SRAM.
Prose on LPC2478 ja LCD http://www.sparkfun.com/commerce/pro...oducts_id=8335
Mälu on 2x K6X8016.
Mõte siis selline et tõmbaks mälude BS(byte select) otsad maha kuna lugemisel nad mõju nagunii ei avalda siis grafka kontrolleril poogen, kirjutaks ise aga softis kui long array-d, sisuliselt ei tohiks midagi paha juhtuda. Ehk on keski asjaga kokku puutunud.

[digital]

Vs: CS ja BLS

Kui just vaja mälu panna 32-bitisena külge, siis saab häda pärast hoida LCD'l kaks bitti kokku. Jaotad oma signaalid ümber nii, et kahe värvi kõige nooremad bitid lähevad kaduma ühendad vastavad signaalid eelviimastega kokku (7:8:7) või teed intensity kanaliga.(7:7:7:i) Edaspidi võtad igal pool arvesse, et manuaalis toodud red,green,blue nimetused ei vasta üksühele ja majandad ise oma pikslite bitte nii nagu õige on. Tõenäoliselt 24 biti pealt 22 biti peale kukkumineei jää nii väiksel paneelil silmaga näha, enamus paneele siiski selles suuruses veel 16-bitised. Kui materjal on korralikult ditheringuga õigele värvisügavusele viidud, ei ole erinevust eriti näha. Erinevusi on küll näha, kui suurel pinnal ilma ditheringuta gradienti näidata.
Kui oma koodi hoiad sisemises mälus/flashis, siis saab mälu bandwidth'i suht kerge vaevaga üle arvutada ja veenduda, et kas 16-bitisest mälust piisab või mitte. LCD datasheet annab RGB liidese lubatud takti vahemiku ning taimingud ja sealt edasi on juba lihtne ligikaudne tulemus saada. Sellele pane lisaks veel oma rakendusespetsiifiline ülekirjutamine.

SDRAM'i puhul arvesta kindlasti mälupankade vahetamise ajaga. Kunagi tegin FPGA'sse displei kontrollerit ja seal läks väga kitsaks, eriti just kui mingi teine protsess graafikat uuendab samal ajal kui seda laetakse ja sellest tulenevalt väga suurt pankade edasi-tagasi vahetamist juhtuma hakkab. Võib-olla tuleb sünkroniseerida pildi uuendamist LCDC fifo olekuga või pildi pimeda ajaga, et asi jõuaks kõik korraga ära teha.

[murphy]

Vs: CS ja BLS

No ma arvutasin et 32 bitti siiniga ja 1clk waitstate oleks 25% siini resursist läinud. poole väiksema siiniga juba pool prose ressurssi. Tõenäoliselt vähendan refreshrate niipalju kui annab ja jään SDRAM-i juurde. Lihtsalt nigel on panna 24 bitti paneel siis värvid maha kakkuda. kuigi 16 biti peale minnes see vist eriti tõesti midagi ei muudaks, mõtlen selle üle veel vähe. Teisalt mõtlesin ka just pankade vahelist hüppamist. Ma tahan koodi käima lasta SDRAM-ist mis tähendab et asi hakkab venima. sest DMA peab iga kord oma adre sisse laadima ja siis pärast prose enda oma uuesti. Mälus hoian 2 framebuffrit, ühte kirjutan teisega tegeleb DMA, kui valmis saan ühe lükatakse LCD teise peale ümber. Seega igat pidi nigel. Tee või Dev. board. Samas IAR lehel on skeem kus ka 24 bitti LCD ja SDRAM, tõsi LCD result poole väiksem.