Satt och dreglade över en PSP-display. Har ett PSP hemma och gillar den displayen skarpt, länge varit sugen på att bygga något kul med en sån.
Nu finns det alltså att få tag i, och det visar sig att den använder ett 24-bitars RGB-interface. Bygga en drivkrets för det är väl inte det svåraste problemet med det, det svåra är väl snarare att trycka in data att visa?
Om jag tänker mig t.ex. 24 fps video i 480x272 pixlar, 24 bitars färg... då får vi:
(480*272*3)/(1024^2) = 8.69 MB data per sekund. Frågan blir då var jag ska få all denna data ifrån...
Idealet vore väl att knåpa ihop en controller som man kan koppla in några olika typer av källor i (VGA, DVI, USB, komposit, rgb, svideo el. likn) och sedan ansluta till displayen.
Finns det färdiga lösningar för att få ordning på det här, typ VGA -> RGB-chip? Eller videocodecs som kan klämma ur sig RGB24?
Alla förslag på hur man interfacar den här displayen mot omvärlden på ett bra sätt är välkomna!
PSP-display
Tack icecap! Den kretsen ser trevlig ut om jag vill generera bilddata på en µC 
Micke_s: Jepp, det är enklare...
Nejdå, du har helt rätt... generera signalen är inget större problem. Vad jag funderar på är att bygga en egen displaymodul... men jag är tveksam kring vilken lösning man ska använda sig av för att skicka in själva bilddatan till nämnda modul. Säg att jag t.ex. vill bygga en extern skärm till datorn, blir det då enklast att smälla in en VGA-port på displaymodulen? Eller kan man rentav fixa en snygg lösning med USB eller dylikt?Korken skrev:Jag är ingen hejare på allt detta nu men en ARM/FPGA/annan kraftig µC borde väll kunna göra jobbet.
Eller har jag fel nu?
Det är ju en 40pins kontakt så det går nog att skicka ganska mycket data i varje klockning (märkte att man kan skicka 3 bytes/klock efter lite läsning).
Micke_s: Jepp, det är enklare...
Vad en del inte tänkar på är att det går åt en hel del minne till dessa bilder om man utgår ifrån att man väljer en lösning som scanner ett minne och skickar till displayen.
Det behövs 391680 bytes och det är en hel del minne, det betyder att en µC måste ha extra minne (vore ju inget fel att ha dubbelt, visa en och skriva på den andra). Jag tror att en FPGA är rätt grej, bygg in en DP-RAM i den och det rullar.
Det behövs 391680 bytes och det är en hel del minne, det betyder att en µC måste ha extra minne (vore ju inget fel att ha dubbelt, visa en och skriva på den andra). Jag tror att en FPGA är rätt grej, bygg in en DP-RAM i den och det rullar.
39160 bytes är ju inte så farligt.
Finns asbilliga minnen (tex dessa) som du kan trycka in antalet bilder för en billig peng, iaf i gämförelse mot vad displayen kostar.
Själv ska jag precis börja med ARM-familjen så det skulle va kul med en sådan display att ha och testa på.
Hmm, *kollar i plånboken* undra vem jag kan få och köpa den till mig.
//Emil
Edit: Kanske finns intresse för samköp på dessa? Jag vet att jag vill i alla fall.
Finns asbilliga minnen (tex dessa) som du kan trycka in antalet bilder för en billig peng, iaf i gämförelse mot vad displayen kostar.
Själv ska jag precis börja med ARM-familjen så det skulle va kul med en sådan display att ha och testa på.
Hmm, *kollar i plånboken* undra vem jag kan få och köpa den till mig.
//Emil
Edit: Kanske finns intresse för samköp på dessa? Jag vet att jag vill i alla fall.
Om man bara vill spara stillbilder nånstans så passar nog flashminnen. Men vill man ha rörliga bilder så får det nog vara ett vanligt (ram). Sen, om jag inte tar fel, så behöver väl skärmen ett yttre minne som bilden mellanlagras i, och en bildkrets som läser i det minnet hela tiden, och uppdaterar skärmen.
Jag tror inte att Korken menade att man ska läsa seriellt i den farten, utan det var nog att hämta en bild nån enstaka gång.
Jag tror inte att Korken menade att man ska läsa seriellt i den farten, utan det var nog att hämta en bild nån enstaka gång.
Korken: du glömde ett siffer! Samt bildgenereringsminnet.
Och i min värld är det totalt likgiltigt att hämta färdiga bilder, jag planerar på att skaffa ett QVGA med touch och en controllerkrets, dessa ska sedan monteras med en 16-bitars processor och sedan ska jag fixa lite mjukvara så att jag kan skicka kommandon av typen: "Rita en fyrkant, start X,Y, storlek x, y, 3D av/på, Uppe/Nere, ramfärg Z" osv.
Med den i handen har jag ett ganska skapligt kommandosystem till div. projekter, nu ska jag bara hitta tiden till det......
Och i min värld är det totalt likgiltigt att hämta färdiga bilder, jag planerar på att skaffa ett QVGA med touch och en controllerkrets, dessa ska sedan monteras med en 16-bitars processor och sedan ska jag fixa lite mjukvara så att jag kan skicka kommandon av typen: "Rita en fyrkant, start X,Y, storlek x, y, 3D av/på, Uppe/Nere, ramfärg Z" osv.
Med den i handen har jag ett ganska skapligt kommandosystem till div. projekter, nu ska jag bara hitta tiden till det......
Enligt databladet för displayen ha en clock signal på min 7.83MHz och max 9.26MHz. Clock signal används för att "cloka" in data, det gör att minsta data flöde blir 7.83M*3byte ~ 23.49MB/s (27MB/s rekommenderad) vilket är en aningen mer än 8.69MB/s
Så att använda en ARM7 kan bli lite tajt, Men med FPGA är saken ganska enkel eller blackfin, ARM9, AVR32...
Så att använda en ARM7 kan bli lite tajt, Men med FPGA är saken ganska enkel eller blackfin, ARM9, AVR32...
