ST7920 display grafikläge, hur??

[sodjan]

> Då krävs ju en avläsning av GDRam,

Eller att du har en kopia i minnet i processorn !
Då räcker det med att skriva till LCD'n.
Man kan ha en minnesarea, samt en bitmap med en bit
för varje 16-bitars område (som väl är det minsta skrivbara
området ?) som skrivrutinen använder för att avgöra vad som
behöver "refreshas". På så sätt kan du låta applikationen skriva
i bitmappen som den vill (och sätta biten för det aktuella området
i bitmap'em), sedan kan man uppdaterade själva LCD'n via en t.ex
en timer, det räcker normalt att göra det ett par gånger per sekund,
om det inte ska vara "rörlig" grafik.

Samtidigt så kräver det så klart en processor med tillräckligt med minne
för att hålla en kopia av bilden på LCD'n.

Men visst, även avläsning, modifiering och återskrivning *ska* ju fungera.

Jag tycker att man ska titta på det hela i ett lite större perspektiv.
Säg att du ska ändra fler än en pixel i samma 16-grupp. Det bli ganska
många läs/OR/skriv operationer där det igentligen vore tillräckligt med en
enda skrivoperation. Det är det jag menar med att det kan bli mer optimalt
att skriva till en intern minnesarea och sedan med ett lämpligt intervall så
uppdateras LCD'n. Fördelen är bl.a att du då får med alla ändringer till en
hel 16-grupp av pixlar med en enda operation.

Men du kommer alltså aldrig att cleara pixar ?
Jag skulle ha kaller det SetPixel() och ClearPixel() i stället för PaintPixel()...

> Jag försöker hålla mig till enkla saker för att minimera felkällorna,

Absolut ! Innan man känner sig säker på hur det fungerar, d.v.s under
tester, så är det ofta enklare att skriva inline "rakt på" kod utan att röra
till det med smarta subrutiner o.s.v. Mycket enklare att felsöka.

Det var lite för mycket kod på en gång för att vara intressant (för mig alltså ).

[Speedsoda]

>Eller att du har en kopia i minnet i processorn !

Ja... Det skulle ju kanske funka. Fast jag undrar hur mycket variabelminne en sån här pic har. Får blir sista utvägen.

Jag vet inte riktigt hur den slutgiltiga lösningen kommer bli faktiskt, men jag känner i alla fall att jag fan inte ska låta den här dumma displaydrivaren slå mig. Jag vill kunna läsa av minnet!



Jag hittade några fel jag hade gjort. När jag ställde in adressen till GDRam hade jag råkat skicka med x koordinaten istället för xkoordinaten/16(dvs, vilket x-"segment"), det var det som orsakade kaoset i skärmen.
Jag har försökt läsa av GDRam, och bara skriva ut det jag får från GDRam rakt tillbaks igen. Det borde ju, om det fungerar, göra så att bilden inte ändras alls. Det som däremot hände förut var att jag fick ut en randig bild. Av någon konstig anledning tyckte jag att streckkoden påminde om lysdioderna jag har satt på bussen mellan PICen och lcdn, hör och häpna, när jag tog bort lysdioderna försvann strecken! Vad fan!? De var inkopplade mellan bussen och jord, med ett 220 ohms motstånd per lysdiod. Det borde väl inte vara en för stor belastning för lcdns utgångar? När jag mäter spänningen på en utgång från lcdn med röd lysdiod(och 220 omhs motstånd) ligger den på 1.7v. Är inte det jättekonstigt? Annars 4.8v.
Nu får jag iaf enbart ettor tillbaks från GDRam verkar det som. Skärmen blir helt täckt, oavsett hur originalbilden såg ut.

[sodjan]

> Fast jag undrar hur mycket variabelminne en sån här pic har.

Sluta undra ! RTFM...

> ...göra så att bilden inte ändras alls.

Med reservation för att en del operationer automatiskt stegar adressen.
Skulle kunna ge en randig bild, kanske...

> ...Det borde väl inte vara en för stor belastning för lcdns utgångar?

Vadå "borde" ?? Sluta gissa och RTFM ! Speciellt "Voh1" (sid 38). Finns
ingen som helst anledning att spekulera kring sådant som är dokumenterat.
Notera att de garanterar utnivån vid en ström om max 0.1 mA.
220 ohm, en röd LED och 5V ger väl någonstans kring drygt 10 mA. Alltså
någonstans kring 100 gånger den specade strömmen.

> Är inte det jättekonstigt?

Nej.

[Speedsoda]

Jag har försökt, men jag fattar inte var den lägger variabler i minnet.
Program memory: 4096 Words Flash
Data Memory: 256 Bytes SRAM
Data Memory: 256 Bytes EEPROM

Det är minnet, men det säger mig inte så mycket, förutom kanske att 256 bytes är max, och det räcker i så fall inte långt. Jag litar fan inte på att jag tolkar det rätt, och googling gav ingenting. Nu slutade dessutom displayen ta emot instruktioner verkar det som. Fantastiskt. Fan vad bitter jag blir.

Jisses, 0.1mA? Herregud vad fånigt. Visste inte ens att man gjorde saker som drev så lite. Men visst, gissa är väl dåligt antar jag.

[sodjan]

Ja, utgångerna behöver ju igentligen inte "driva" något alls. De ska ju bara
överföra en logisk nivå mellan CMOS kretsar och där behövs i princip inga
strömmar alls, CMOS ingångar har väldigt hög impedans, 10-tals Mohm.

Sen så *kan* de sannolikt driva lite mer än just 0.1 mA, men det är den
gräns där värderna (nivåerna) för "hög" garanteras av tillverkaren.
D.v.s 0.8V under drivspänningen. Däremot är det kanske ingen bra ide
att lägga på LED's med 220 ohm. Dessutom (du jobbar väl inomhus ?)
hur har du kommit fram till att just 220 ohm skulle vara optimalt ?
Det lär räcka med ett betydligt högre värde, säg 4.7 kohm eller så,
för att fortfarande *se* om lysdioden är tänd eller släckt. Om det är
rellativt moderna och effektiva LED's så kanske även 10 kohm är OK.
Och då skulle du sannolikt inte ha några problem med nivåerna
på data-pinnarna.

Ett annat sätt är att koppla LED'sen via en extra buffert som då inte
belastar data-pinnarna alls.

Och nej, minnet ("RAM", "GPR") i en 16F690 räcker inte till för att göra
den LCD-kopia i minnet så som jag beskrev. Det går ju åt 128*64/8
bytes eller 1024 bytes. Tror ingen PIC16 klarar det, men flera PIC18 fixar
det. Spelar ingen roll, det *ska* ju gå att läsa/modifiera/skriva också.
Det var mest bara för att vidga vyerna lite med andra lösningar.

> ...Fan vad bitter jag blir.

Du verkar ha problem med inställningen till det hela. Det hjälper nog inte.