AVR/PIC 8-bit +Grafisk DOGXL 160x104px = möjligt?

[toffie]

Hej på er,
Här kommer min nästa fundering

Jag håller ju på med mitt larmsystem som fortfarande inte har tillräckligt mycket för att visas upp än..
Men jag har börjat fundera på vad för display jag ska ha.. Givetvis går det ju med en text display, men bara för skojs skull
så tänkte jag prova en grafisk variant för att se om det blir "snyggare" och kanske mer "lättanvänt" för den som ska använda det hela..

Givetvis kan man ju göra olika versioner i slutändan, men bara för att se om det är möjligt så undrar jag ifall någon har
använt sig av en grafisk Display On Glass (DOG) display tillsammans med AVR / PIC 8-bitars..

Har tittat på DOGXL160 som är en 160*104 pixels display och på dessa så står det att de har både SPI/I2C interface vilket
borde betyda att det är trivialt att sätta igång dessa med en AVR alt. PIC.. inte sant?

Men för att uppdatera displayen, vad kan man tänkas få för hastighet på det hela? Kan det bli tillräckligt flimmerfritt om
man inte uppdaterar varje pixel.. Säg att man kanske har ett par stora siffror uppe i ena hörnet, sen datum/tid nere i ena
hörnet och sedan bara lite annan text i de andra hörnen.. Det borde väl inte bli något flimmer på det?

Den display jag tittade på var denna på ELFA 75-514-22 .. Hade gärna sett att den var transflective, men enligt ELFA
så är den inte det, fast den är det i databladet hos http://www.lcd-module.com
http://www.lcd-module.com/eng/pdf/grafi ... 160-7e.pdf

Sen undrar jag även hur man "fäster" bakgrundsbelysning under dessa displayer, klistras de fast under-mot displayen
eller på kretskortet under displayen, kanske har de någon speciell fästanordning eller hur gör man?

När jag tittar på bilder på bakgrundsbelysningarna så verkar det som att man kanske sätter de på "pinnarna" under displayen och
pressar mot kretskortet, stämmer det?

[Micke_s]

Jo, det borde bli rätt så flimmerfritt, Dogm kan köra upp till 8Mhz spi.

Jag räknar på AVR:s spi.
Det är 160x104 pixlar = 16640, varje byte motsvarar 4 pixlar = 4096 byte för uppdatera hela displayen.
8Mhz spi = 0.125us/bit=> 4.096ms för uppdatera hela displayen, inte mycket tid.

Displayen borde inte vara något problem att få igång.

Jag tror bakgrundsbelysningen bara ligger bakom, inte säker där men har fått det intrycket.

Undvik i2c om du inte måste spara in 2 i/o:s, spi är mycket snabbare och enklare att komma igång med.

[toffie]

Ah okej, 4ms är ju en del, men långt ifrån synligt flimmer
Man får verkligen se till så att displayen bara uppdateras när man behöver det, till skillnad mot vanliga LCD displayer på
2x16, 4x20 osv.. De har jag fått intrycket att de är långt mycket snabbare, men det är väl förmodligen mycket lättare för
drivkretsarna bakpå att driva dem då det är färre pixlar plus att de är grupperade

Men tack för uträkningen och informationen Micke_s!

[sodjan]

Du blandar ihop saker och ting (och svaret du fick gjorde inte
mycket för att förhindra det). Displayen *i sig* är helt flimmerfri.
Den har sitt eget grafikminne och logik för scanningen av hela displayen.

Om du sedan bara tittar på *en* enstaka uppdatering så kommer den
sannolikt inte att synas, hela (t.ex) klockan kommer att uppdateras på en gång.

Det som kan uppstå om du skriver till vissa positioner med en väldigt jämn
uppdateringsfrekvens (som t.ex när man uppdaterar en "klocka" över en längre tid),
är att du kommer i otakt med displayens egen läsning från minnet och skrivning till
skärmen (interferens). Det uppstår långsamma "rullningar" eller liknande, den aktuella
effekten är svår att ange, det beror bl.a på hur skärmen skrivs. Ungefär som att filma
en TV med en filmkamera, det blir rullande linjer om inte kameran är synkad med/till TV'n.

På en del displayer har man tänkt på detta och tillhandahåller en extern "synk" signal
som kan användas av processorn för att enbart skriva till minnet under en period då
display-kontrollern inte samtidigt läser från minnet. Detta ger störningsfria skrivningar.
Den aktuella displayen saknar dock den möjligheten.

Men å andra sidan, om det gäller att uppdatera en klocka med sekundupplösning,
så är det *sannolikt* inga problem. Om man dessutom kan skriva koden till sin
processor så att uppdatteringen inte sker med en helt förutsägbar frekvens (alltså
alltid samma antal cykler mellan varje uppdatering) så är sannolikheten för att det
ska uppstå synliga störningar nog ganska liten.

> till skillnad mot vanliga LCD displayer på 2x16, 4x20 osv..

Nej, det är i princip ingen skillnad. Även en HD44780 LCD kan
uppvisa samma fenomen om man skriver med helt jämn frekvens.

> De har jag fått intrycket att de är långt mycket snabbare,

Vad är snabbare ? Uppdateringen av LCD skärmen eller interfacet ?
Scanningen av LCD'n är sannolikt ungefär samma. Interfacet är snabbare
på det sättet att man kör 8 bitar samtidigt, men å andra sidan kör man inte
med lika hög frekvens som I2C linjen till denna LCD. Svårt att jämföra.

> ...då det är färre pixlar...

Så väldigt stor skillnad är det inte. En 4x20 LCD har väl ca 120-130 x 40-50 pixlar.

[jesse]

Man lägger bakgrundsbelysningen under, den har hål som passar i displayens ben - man trär bara i benen i hålen och sedan lödar fast displayen på kretskortet. Sedan sitter den fast. Men för att belysningen ska få sin ström så måste dessa anslutningar lödas till motsvarande ben på displayen.

Det borde bli flimmerfritt eftersom inga pixlar ändras annat än de du vill ändra.
dvs. alla "orörda" tecken förblir orörda - inga streck eller annat kan förekomma där. Endast där pixlar släcks och sedan omedelbart tänds igen uppstår risken. Det kan man försöka undvika med mjukvara.

Så du kan i praktiken uppdatera mycket långsamt och ändå inte uppleva flimmer (däremot kommer då inte alla tecken att uppdateras samtidigt, utan ett och ett, beroende på hur snabbt du kör. SPI-interfacet går snabbt... jag har kört 625 kbit/sek med en meter kabel utan problem. (fast jag kör 156 kbit/sek normalt).

[toffie]

sodjan
Tack sodjan! Jag måste erkänna när jag läser ditt inlägg att.. "Det där vet jag ju"..
Jag tänkte verkligen inte på det däremot, va dumt, när jag läser det så förstår jag ju att det jag frågade var helt irrelevant..

För när jag får fram "rullningarna" så är det ju för att jag uppdaterar displayerna alldeles för snabbt..

jesse
Tack för din input! Jag vet ju att du använt en bland annat i din PIC Voltmeter som du hade till EF tävlingen förra året.
Det med "däremot kommer då inte alla tecken att uppdateras samtidigt, utan ett och ett, beroende på hur snabbt du kör."
är det jag skriver om under, fast jag skrev det innan jag läste ditt inlägg med efter sodjan's


I slutändan.. Jag tror jag vet vad jag egentligen skulle ha frågat..
Uppdateringen av displayen, kan det bli "släpningar" / "ghosting" för att mcu är för långsam? Men det gäller ju inte dessa
displayer som har inbyggd intelligens..

Jag tänker nog på riktiga LCD displayer, typ TFT eller så, där mcu måste vara
den "intelligenta styrningen"... Det stämmer väl?

Och nej, jag vet att ex. AVR inte är så duktig på att styra en riktig TFT
Jag tänkte däremot på ARM processorer som däremot klarar att styra dem

[sodjan]

> Så du kan i praktiken uppdatera mycket långsamt och ändå inte uppleva flimmer

Risken för interferens mellan skrivningen och scanningen av skärmen
är större ju snabbare man kör. Och risken ökar också, som sagt, ju
mer förutsägbar skrivningsfrekvensen är.

Sen kan man få ett slags "flimmer" som faktiskt som inte har något med
interferens att göra, d.v.s om man t.ex uppdaterar något med en frekvens
som upplevs "störande". Men det är ju inte unikt för just en LCD.

[sodjan]

> Jag tänker nog på riktiga LCD displayer, typ TFT eller så, där mcu måste vara
> den "intelligenta styrningen"... Det stämmer väl?

Nja, det beror ju lite på hur koden är skriven. Sannolikt (om själva LCD-kontrollern är
inbyggd i MCU'n) så är det lättera att "synka" mellan skrivningarna och skaningen
av displayen för att undvika störningar. I princip är det ingen skillnad, men i praktiken
finns det sannolikt fler sätt att undvika störningarna. Ungefär som de LCD-kontrollers
som har en separat synk-signal för störningsfria skrivningar.

Och problemet är alltså när man får interferens mellan skrivningarna och skaningen.
Det betyder oftast att frekvenserna för skrivningen respektive skanningen måste gå
*nästan* jämt upp. Alltså vara nästan samma eller nästan en multipel av den andra.

[jesse]

jesse
Tack för din input! Jag vet ju att du använt en bland annat i din PIC Voltmeter som du hade till EF tävlingen förra året.

det var nån annan som hade gjort det... jag har varken byggt med PIC eller varit med i tävlingen. Däremot har jag byggt saker med DOGM både text- och grafiska displayer. Med AVR.

Och nej, jag vet att ex. AVR inte är så duktig på att styra en riktig TFT

eller..? Atmega88 + VGA (Linus Åkessons 'Craft')

[toffie]

jesse
Hmm.. du ser, mitt minne sviktar redan
Ja det kanske var någon annan som gjort den voltmetern haha

Jo, jag vet att det går, men o andra sidan så är inte upplösningen den högsta och det går ju inte göra precis vad som
helst heller. Exempelvis så ser du hur det hackar med vissa av animationerna för att ATmegan inte "klarar av" hastigheten av
uppdateringarna.

Jag har sett de där förut, har till och med sparat ner alla hans videos som gäller det där, för den grafiken..
Det är ren kärlek för mig

För många är det väl tidigare system, men för mig är det där Amiga600HD som var min första dator.

sodjan
Du verkar kunna en hel del om displayer Mycket intressant information, "man lär sig något nytt varje dag"
Det känns ju helt klart som att det finns mer att veta om displayer av olika slag än vad man trott när man "lekt" med
de 2x16, 4x20 osv som man har hemma

Visst, det har man väl haft i bakhuvudet ändå, men inte som man tänker på.

Har du jobbat mycket med displayer eller är det bara ett intresse?