Grafisch lcd met PIC programmeren

[Verwijderd]

Dag,

ik wil een grafisch LCD programmeren met een microcontroller, maar ik zit met timing problemen... Nou weet ik dat sommige modules een driver erin hebben zodat ik niet de Hsync en de Vsync hoef te timen, want dat gaat niet zo makkelijk met een microcontroller imo.

Ik vroeg me af of ik bij deze display mijn RGB data via SPI kan versturen zodat ik niet met de timing vast kom te zitten..

Dit is de link van de display

De pic die ik wil gebruiken is 1tje die tot 64 MHz kan en is van de pic18 serie

Hulp is hierbij echt nodig!

[3xhaas]

Ik denk niet dat je pixel-data via SPI kunt verzenden.

De enige gespecificeerde registers die ik in de datasheet kan vinden staan op pag.10 en daar staat geen pixel informatie in.
Verder is de SPI data transmissie 9 of 24 bit, waarbij bij 9-bit transmissie het eerste bit voor adress of data wordt gebruikt. Met 9 bit transmissie kun je na het adres op te geven twee data bytes verzenden. Aangezien je 18 bit kleurinformatie wilt verzenden past dat niet in die 2 bytes.
Met 24 bit transmissie gaat hij pas vanaf bit 9 echt data verzenden en dan kom je ook weer op 16 bits uit.

Wat betreft de timing heb je het denk ik verkeerd begrepen.
Je kunt het aantal dummy cycli voordat hij data begint in te lezen instellen met HBP5-0(HSYNC) en VBP7-0(VSYNC) (pag.12), dus daar komt geen kritische timing aan te pas.

[edit]
Ow ja je zei dat je een 64MHz MCU gebruikt, echter pixel data kun je maximaal met 8MHz (typ=5MHz) inklokken en de SPI-bus gaat tot 20MHz. Dat houdt in dat ~60 beelden per seconden kunt halen.
(FPS=1/(336*244*(1/5E6))=60,98Hz)
Je hebt in ieder geval wel zat tijd over om je image data klaar te zetten met een 64MHz MCU

[ Voor 17% gewijzigd door 3xhaas op 03-12-2011 16:31 ]

[Verwijderd]

Oke dus stel je voor dat ik voor HBP5-0 een waarde kies, dus bv 11, volgens de table betekent dat 5 clock cycles wachten tot de eerste regel word gelezen.

Maar wat moet ik daarna met Hsync en Vsync doen? Gwn proberen goed te timen en met interrupts werken om geen tijd te verliezen?

De data er naar toe sturen lijkt mij geen probleem, enige wat mij dwars zit is eigenlijk de timing dus van de waarden... Ik had liever gehad dat ik via SPI de waarden er naar toe kon sturen. Kun je mij vertellen hoe ik dit aan moet pakken aub?

[Sprite_tm]

Ik heb je titel even ont-haast. Leuk dat het dringend is, maar qua snelheid van antwoorden maakt het niet echt uit of je het in de titel zet of niet.

Verder: Wat snap je precies niet? Voor zover ik het zo 123 zie staat alle info in de datasheet. Implementeren en gaan met die banaan, lijkt me toch? Stel iig wat gerichter vragen, we gaan namelijk niet een cursus-displays-aansturen geven hier.

[3xhaas]

Er komt niet echt timing aan te pas.

Voor de HSYNC (stel je gebruikt HBP5-0 = 11, = 5 cycli)
Nadat HSYNC laag wordt, moet je DOTCLK eerst 5 positieve flanken hebben gehad. Na die 5 positieve flanken gaat hij op elke positieve flank data inlezen die op de RGB-poorten staan.

Voor de VSYNC fungeert de HSYNC als zijn klok-signaal, dus (stel je gebruikt VBP7-0=11, =3 cycli) nadat VSYNC laag wordt zijn de eerste 3 negatieve flanken op HSYNC dummy cycli, waarna bij elke volgende negatieve HSYNC flank de data wordt ingelezen.

[Verwijderd]

Ik vraag ook niet om een cursus display aansturen. Ik dacht in het begin ook van zon probleem zal dat toch niet zijn, als ik een pic pak met een clock snelheid hoger dan 5MHz zou het eigenlijk al voldoende moeten zijn... Enige wat er moet gebeuren is dat er binnen een bepaalde tijd een ander kleurwaarde op de pin moet staan. Dat heeft dus met timing te maken of noem je dat geen timing? [hmm]

Waar ik mij zorgen over maak is dat ik die timing niet red met een microcontroller [is mij verteld dat dat lastig gaat worden, kweet niet of dat klopt, of alleen bij een hogere aantal pixels?]

Nu hoop ik dat mijn 1e alinea klopt... Kun je dat voor mij bevestigen 3xhaas?

Dan heb ik nog wel een vraag, welke clock zou ik gebruiken voor Hsync...
Ik zou toch ook een oscillator kunnen pakken van 4 MHz en dat op de lcd aansluiten, maar ik denk dat het dan asynchroon gaat werken of kan ik dit synchroon maken met een reset of de den pin?

Het gaat namelijk niet werken wanneer ik de micro en de lcd met dezelfde frequentie aanstuur. Hoe raad je het mij aan om de Hsync te sturen??

Erg bedankt haas met je hulp tot nu toe

[3xhaas]

Het lijkt wel een beetje op een beginnerscursus "hoe stuur ik een lcd aan".

Anyway al je stuursignalen (pixeldata, DOTCLK, HSYNC en VSYNC) ga je uiteraard met je microcontroller maken.
Betreffende timing is is figuur 7.1 pixel clock timing leidend.
Je kloksignaal is/wordt laag
Eerst zet je pixel data op juiste poorten.
Dan creeer je een delay van tenminste 10ns(tDS).
Vervolgens maak je kloksignaal hoog. (tenminste 16ns nadat je klok laag geworden is(tCKL))
Vervolgens moet je kloksignaal tenminste 16ns hoog blijven, nadat deze hoog geworden is (dus niet nadat je zei dat hij hoog moest worden).
Hierna kun je klok weer laag maken en begint het verhaal weer opnieuw.
Je zult dus was delays moeten inbouwen.
En die timings zou ik een stukkie ruimer nemen, want je hele klokperiode moet toch tenminste 125ns duren.

Je hebt trouwens wel behoorlijk wat geheugen nodig als je al je data van te voren wilt opslaan, nl. 18bit*320*240=1382400bit=172800byte minimaal, maar waarschijnlijk is het makkelijker elke kleur in een 8bit container op te slaan, dus dan kom je op 3*8bit*320*240=230400byte.
Als je je data wilt verwerken tijdens het aansturen van LCD (bv. datacompressie o.i.d.) dan is die 64MHz erg welkom! Je code wordt dan uiteraard een stukje ingewikkelder en zul je met de interne timers van de microcontroller moeten gaan werken i.p.v. delays.

Anyway ik zou gewoon eens beginnen door de timing d.m.v. delays te doen.

[Sissors]

Ben niet erg into PICs, maar die 64MHz is toch niks sneller dan een standaard Atmel? Dacht iig dat PICs voor meer klokcycli per instructie nodig hebben.

[mux]

Yup, een 64MHz PIC zal ongeveer even snel zijn (of nèt iets langzamer) dan een 16MHz AVR. PIC heeft voor bijna alle instructies 4 of 5 clock cycles nodig, AVR 1.

[3xhaas]

Dat verschilt per instructie. Veruit de meeste instructies zijn 4 cycles, maar er zijn ook die slechts 1 of 2 cycles in beslag nemen. Verder kunnen de hardwarematige functies meestal op volle kloksnelheid werken.

[mux]

Alle basisinstructies kosten per definitie minstens 4 clock cycles, misschien ben je in de war met instruction cycles (1 instruction cycle is 4 clock cycles). Dat is inherent aan de implementatie van de instructieset in PIC. Sommige instructies kosten (soms) 2 instruction cycles, oftewel 8 clock cycles. Er zijn geen instructies die minder dan 4 clock cycles kosten. Google helpt bij dit soort uitspraken

Hardwarematige functionaliteit zoals PWM kan inderdaad wel (vaak) de klokfrequentie als basisfrequentie gebruiken. Zo is de processorkracht bijvoorbeeld geen bottleneck als je met 64MHz een SPI bus volledig wil utiliseren: een RAM fetch en SPI write kosten samen 2 instruction cycles, wat 8 clock cycles is, dus precies de hoeveelheid tijd die het duurt om die data uit te voeren. Helaas heb je dan dus helemaal geen cpu-tijd meer over voor andere dingen.

Waar het mij om ging is de opmerking dat je die 64MHz goed kon gebruiken voor het verwerken van de beelddata; dit gaat moeilijk worden, omdat je PIC al ontzettend druk is en van zichzelf een heel stuk langzamer per MHz dan andere architecturen. Als je een 320*240 kleurenscherm volledig wilt updaten, heb je 320*240*3*9 SPI clock cycles nodig, dat is meer dan 2M clock cycles. Die data kan niet uit intern RAM komen, want geen enkele PIC heeft genoeg geheugen voor zo'n grote beeldbuffer, dus je moet extern RAM gebruiken. Dat kost minstens 4 instruction cycles op een PIC met DMA per 8-bit fetch (op sommige PICs kun je 16 bits per transfer binnenhengelen in 2 instruction cycles). Stel dat je een soort van compressie of andere bewerkingen op je data wil doen, dan ben je echt veel meer dan 10 instruction cycles verder per byte beelddata. Alleen al als je een variabele uit geheugen wil halen, een operatie wilt uitvoeren en wilt MOVen ben je al 4 instruction cycles verder, plus de 6 die nodig zijn om een byte uit RAM te fetchen plus naar SPI te schrijven. Op deze manier zit je al gauw in de buurt van 1fps of minder refresh rate. Dus om nou echt te zeggen dat je veel ademruimte krijgt met een PIC op 64MHz: nah. Nouja, natuurlijk wel ja, maar deze toepassing is gewoon heel erg zwaar en zelfs met de beste wil op aarde moet je intelligent met je screen updates bezig zijn (geen full refreshes, maar hoogstens delen van het scherm bijvoorbeeld) om nuttige performance uit de toepassing te halen. En als je dan eerst nog moet beginnen om met delays communicatie met het scherm op te bouwen... tsja, dan gaat dit project nog héél lang duren.

[3xhaas]

mux schreef op zondag 04 december 2011 @ 11:43:
Alle basisinstructies kosten per definitie minstens 4 clock cycles, misschien ben je in de war met instruction cycles (1 instruction cycle is 4 clock cycles).

Ik had een soort blackout idd (je moet ookk geen reacties schrijven om 3 uur 's ochtends), anyway de meeste instructies kosten 1 instruction cycle, terwijl sommige ook 2, 3 of enkele nog meer kosten.

Wat betreft het benodigde geheugen heb je uiteraard gelijk, vandaar dat ik daar al op gewezen heb.

mux schreef op zondag 04 december 2011 @ 11:43:
Als je een 320*240 kleurenscherm volledig wilt updaten, heb je 320*240*3*9 SPI clock cycles nodig, dat is meer dan 2M clock cycles.

Verder heb jij het over het beeldscherm updaten via SPI en ik kon dat nou juist niet terugvinden in de datasheet. Daarna heb je het weer over delays om het scherm op te bouwen, wat niet ook echt strookt met SPI communicatie voor het opbouwen van het scherm. Kon jij wel terugvinden hoe je scherm kunt opbouwen via SPI of doelde je puur op het fetchen uit extern geheugen via SPI?

mux schreef op zondag 04 december 2011 @ 11:43:
Die data kan niet uit intern RAM komen, want geen enkele PIC heeft genoeg geheugen voor zo'n grote beeldbuffer, dus je moet extern RAM gebruiken.

Het is trouwens ook mogelijk data in het flash geheugen op te slaan/naartoe te schrijven al neemt dat meer tijd in beslag dan via het RAM. Ook is het niet verstandig als je dat vaak doet, vanwege het maximale aantal schrijf-cycli. Maar stel je stopt een achtergrond-plaatje daarin dat moet mogelijk zijn. Ik kon echter geen 8 bits PIC's vinden die meer dan 128kbyte flash hebben, dus je bent wel gebonden aan een 16/32bit dan.

Ik probeerde Blackjack erop te wijzen dat een 5MHz PIC niet handig was, vandaar dat ik zei dat 64MHz welkom is, maar inderdaad het is niet zaligmakend.

Ten slotte nog een PIC32 als movie player. (youtube)

[mux]

Ohja, whoops. Je kon juist géén pixeldata via SPI verzenden. Meeste grafische displays hebben idd SPi alleen voor text mode. Nouja, het rekensommetje geldt in principe voor alle seriele peripherals die je zou gebruiken.

Het ligt eraan wat je wil doen. Puur een achtergrondplaatje bouwen (evt. gecomprimeerd in flash) kan prima met een 8-bitter, en dan vervolgens alleen tekst erop displayen. Als je echt meer wilt doen, ook op grafisch gebied, zou ik richting de MIPS/ARM cores gaan - PIC32, AVR32/UC3, STM32, LPC2000, dat soort spul.

[DaWaN]

Wat wel een leuk schermpje is om te beginnen is het Nokia 6100 LCD.
Dit LCD heeft een ingebouwde framebuffer en die is via SPI te beschrijven.
Omdat het display een ingebouwde buffer hebt zul je niets te maken hebben met de timing van het display zelf.
Je hebt van dat LCD ook complete modules waar de backlight inverter en SMD connector al op zit zodat je het LCD makkelijk met 2,54mm pinheaders kan aansluiten.

Zoiets dus:
http://www.ebay.nl/itm/No...2561bff10b#ht_1545wt_1164
http://www.sparkfun.com/products/8600

[Verwijderd]

Echt erg bedankt voor jullie input.
Ik wou het al op die manier doen, maar mensen zeiden dat mijn timing niet zou kloppen met een micro en dat ik een CLPD moest gaan gebruiken... is wel makkelijker imo maarja

Ik ga deze micro PIC18F26K20 gebruiken: http://www.microchip.com/...es.aspx?dDocName=en026332
Het is een pic18 micro. Ik zei meer dan 5MHz, omdt deze dat wel kan en dan kan ik in de tussentijd nog andere berekeningen uitvoeren als ik dat nodig vind

Deze kan tot 64 MHz met de interne PLL op ±3 volt. Voor het geheugen wou ik een flash memory van 1MB kopen en ff aankijken hoe ik hier data vanuit ga lezen, zodat er altijd 1 plaatje erop staat en dat de lcd van daaruit zijn data krijgt, en ik wil het idd maken zoals jij het zegt dat ik de pixels verander die ik moet veranderen...

Ik snap niet echt waarom je dit zegt: 18bit*320*240=1382400bit=172800byte minimaal, maar waarschijnlijk is het makkelijker elke kleur in een 8bit container op te slaan, dus dan kom je op 3*8bit*320*240=230400byte.

Ik krijg hier toch alleen maar meer bytes van?;o
En ik bespaar me toch een paar pinnen als ik 3*6 bits stuur ipv 3*8 bits?

Ja DaWan, die modules zien er fijn uit! Maar ik zie dat farnell dat niet echt verkoopt... Daar moet je je eigen buffer maken, zou wel kunnen kijken of ik gwn zon module kan kopen, maar die vind je niet op farnell of digikey toch?

[3xhaas]

Verwijderd schreef op zondag 04 december 2011 @ 17:23:
Ik snap niet echt waarom je dit zegt: 18bit*320*240=1382400bit=172800byte minimaal, maar waarschijnlijk is het makkelijker elke kleur in een 8bit container op te slaan, dus dan kom je op 3*8bit*320*240=230400byte.

Ik krijg hier toch alleen maar meer bytes van?;o
En ik bespaar me toch een paar pinnen als ik 3*6 bits stuur ipv 3*8 bits?

Standaard container zijn 8, 16 of 32 bit groot.
Stel je wilt een 18bit pixel in een container opslaan dan heb je een 32bit container nodig.
Stel je wilt 1 6bit subpixel(rood, groen of blauw) in een container opslaan dan kom je per pixel op 3*8bit=24 bit neer. Kortom je hebt minder geheugen nodig.
Nog mooier is natuurlijk als je pixeldata gewoon doorloopt, zodat je geen overhead hebt. Maar dat is lastiger te programmeren.
Wat betreft het aantal pinnen maakt dat niet uit er kunnen maximaal 18bits aangestuurd worden. Wat je eventueel wel kunt doen is minder pixels gebruiken bv. 15 ipv 18bit dan past een pixel in een 16bit container. Je stuurt dan alleen de 5MSB per kleur aan.

[Verwijderd]

Stel je wilt een 18bit pixel in een container opslaan dan heb je een 32bit container nodig.

Waarom heb je een 32bit container nodig voor 18bits?

De rest snap ik wel xD
Ja, ik zou idd ook gwn de LSB weg kunnen laten dat valt toch het minst op als je dat verandert.

Wel nog 1 vraag, stel je voor dat ik een 24v adapter gebruik, en de lcd heeft 3.3v nodig met bv 100mA,
kan ik dan gwn (24-3.3)/100mA = 207 Ohm neer zetten?

Adapter is 24V want ik heb 19V nodig voor backlight vd lcd

[3xhaas]

Verwijderd schreef op zondag 04 december 2011 @ 18:11:
Stel je wilt een 18bit pixel in een container opslaan dan heb je een 32bit container nodig.

Waarom heb je een 32bit container nodig voor 18bits?

Omdat het niet in een 16bit container past...
Je kunt wel eerste bits pakken van het volgende adres etc, maar als ik zo je ervaring beoordeel is die nog niet erg hoog en zou ik zo simpel mogelijk beginnen. Werkt ook motiverender als je dingen al werkend hebt.

Verwijderd schreef op zondag 04 december 2011 @ 18:11:
Wel nog 1 vraag, stel je voor dat ik een 24v adapter gebruik, en de lcd heeft 3.3v nodig met bv 100mA,
kan ik dan gwn (24-3.3)/100mA = 207 Ohm neer zetten?

Nee, dat kan niet. Gebruik een (low) dropout regulator of een pieper.

[Verwijderd]

Ik vind het nog wel beetje vaag hoor, want het zijn gwn IO pinnen die je hoog of laag zet. Waarom kan je niet gwn 18 pinnen instellen, waarom moet het in 8bit containers... [betekent container nog iets specifieks?]

Dus bv: PORTA [8bits]
PORTB [8bits]
PORTC[2bits]

Is het omdat je code dan niet overzichtelijk word? Of hoe moet ik dat zien? Want anders kan ik bv gwn doen zoals je zei, 15 bits naar toe sturen, dan hou ik et bv alleen op PORTA en PORTB

[3xhaas]

Waar wil je data vandaan halen om die poorten hoog of laag te maken?

[ Voor 6% gewijzigd door 3xhaas op 05-12-2011 07:18 ]

[Verwijderd]

Nou, ik ga ten eerst objecten aanmaken die de groottes van de iconen op het beeld bevatten.
Vervolgens laat ik dus mijn eerste pagina zien en met een knop , later touchscreen, kun je door naar een tweede/derde pagina..

De data zal waarschijnlijk opgeslagen worden in mijn externe flash memory

Ik kan de pinnen toch wel afzonderlijk hoog/laag maken? Ik hoef toch niet in bytes te werken [als het niet anders kan], vandaar dat ik je 8 - 16 - 32 bit container niet helemaal begrijp...

[ Voor 24% gewijzigd door Verwijderd op 05-12-2011 09:31 ]

[3xhaas]

Verwijderd schreef op maandag 05 december 2011 @ 09:25:
Nou, ik ga ten eerst objecten aanmaken die de groottes van de iconen op het beeld bevatten.
Vervolgens laat ik dus mijn eerste pagina zien en met een knop , later touchscreen, kun je door naar een tweede/derde pagina..

De data zal waarschijnlijk opgeslagen worden in mijn externe flash memory

Ik kan de pinnen toch wel afzonderlijk hoog/laag maken? Ik hoef toch niet in bytes te werken [als het niet anders kan], vandaar dat ik je 8 - 16 - 32 bit container niet helemaal begrijp...

Je zult de image/pixeldata toch ergens moeten opslaan of dat nu in de microcontroller of extern geheugen is. En per pixel heb je standaard 18bits nodig. Als je per (sub)pixel een adres wilt gebruiken (omdat dat makkelijker) werkt zul je dat hoe dan ook ergens in een 8/16/32-bit container moeten opslaan of dat nu in de microcontroller of extern geheugen is. Als je slechts een paar kleuren wat text wilt laten zien kun je natuurlijk slim omgaan met de ruimte die je nodig hebt en dezelfde (sub)pixeldata gebruiken voor de achtergrond. Maar ook die data moet je ergens opslaan als is het maar een keer.
Ik krijg steeds meer het idee dat dit je eerste microcontroller project is, dus ik zeg het nog maar een keer. Zorg eerst dat je de communicatie met je LCD werkend krijgt en bv. het LCD met een bepaalde kleur kunt vullen en werk vanaf daar verder dan begrijp je misschien beter wat ik bedoel.

[Verwijderd]

Oke dank je voor je uitleg
Het is niet mijn eerste en waarschijnlijk ook niet mijn laatste project.

Ik ga de display en de componenten bestellen. Ik zal het via deze forum mijn voortgang laten weten

[Verwijderd]

Weet je trouwens ook of er een geschikt controller hier voor bestaat? Ik kan zo geen goede controller vinden...