Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen

Mit Waitstate hats nicht funktioniert, ohne funktionierts? Dann wars 
aber nicht das Layout. Da wärs ehr andersrum gelaufen ;)

Wahrscheinlicher ist, dass die Framerate zu hoch war. Mit Waitstate 
braucht der Interrupt deutlich länger. Du hast die 8-Graustufen-version 
in der eh schon mehr Zeit im Interrupt verbracht wird. Mit Waitstate 
hats dann halt nicht mehr gereicht.

Aber glückwunsch dass es jetzt läuft.

Sebastian

Dein Kommentar hat mich etwas verwirrt.
Wenn ich in param.h die (normalerweise nicht gewählte) Option Waitstate 
aktiviere, dann nehme ich in lcd.c doch die Version mit (1<<SRW10 im 
MCUCR). Damit schalte ich den Waitstate doch ein und nicht aus! Oder 
habe ich da etwas falsch verstanden?

Bruno

Achso! Bei dir funktionierts nur mit Waitstate? Ja, dann könnte es 
wirklich der Aufbau sein. Hatte deinen letzten Post falsch verstanden.

Eine Frage an die Experten!

Kann ich mit HTerm die Befehle und Daten in einem Textfile übertragen 
und wenn ja, wie?

Bruno

Hallo Helfender,

nun hat es endlich geklappt. Herzlichen Dank für den Tip!

Bruno

Ich bin es schon wieder! Ich habe mich zu früh gefreut!
Wenn ich Bilder übertrage, dann werden diese immer irgendwie geteilt, 
u.z. unabhängig davon ob ich mit HTerm oder mit einem Controller 
übertrage. Es ist auch egal, ob ich den Code von Benedikt mit 4 
Graustufen, oder den erweiterten von Sebastian nehme. Der Unterschied 
scheint nur zu sein, daß im Benedikt Code das Bild in der Mitte geteilt 
ist (siehe Anlage) und beim Sebastian Code links ca. 2/3 des Bildes 
erscheinen. Das ist aber mit Vorsicht zu betrachten, da sich das hin und 
wieder auch ändert.
Hat jemand eine Idee?

Bruno

Hallo Helfender,

dein Bild hat mir zwar nichts Neues gebracht, aber trotzdem bin ich 
dadurch auf die richtige Spur gekommen. Ich hatte bei meinen Bildern 
immer einen Clear-Befehl (12) an den Anfang gesetzt und das verträgt der 
Code offensichtlich nicht.

Dank und Gruß
Bruno

Hallo Helfender,

ich brauche nochmals Rat. Dein Beispiel war zwar nur mit 2 Farben, ich 
gehe aber davon aus, daß du dich auch mit der 4 und 8 Graustufen Version 
beschäftigt hast.
Ich habe Probleme mit dem xs Wert. Wenn ich ein Bild 320x240 übertrage, 
dann
habe ich im s/w Modus 320/8=40.
Im 4Grau Modus sind das dann 2*320/8, also 80 und im 8Grau Modus müßten 
es doch 3*320/8, also 120 sein. Das ergäbe 120*240=28800 Bytes für das 
gesamte Bild. Mein Problem ist, daß ich bei der Erzeugung eines 8Grau 
Bildes mit dem GrafikConverter hier aus dem Forum aber 38399 Bytes 
bekomme. Rein rechnerisch müßte ich dann ja 38399/240 ~ 160 Bytes mit xs 
übertragen. Ganz egal wie ich es aber anstelle, es kommt nur Müll.
Liegt es nun an der Einstellung des GrafikConverters oder an meiner 
Berechnung des xs.
Die 4Grau funktioniert übrigends problemlos.

Bruno

Hallo gasst und Helfender,

ich danke für die prompte Antwort.
Der Rambo ist angekommen (siehe Anlage). Ich habe ihn allerdings mit 
HTerm übertragen.
Wie ich aus euren Antworten entnehme, sind die 3bpp nur bei der Anzahl 
der Bytes zu berücksichtigen, Ich war bisher davon ausgegangen, daß im 
Befehl das xs auf 40, 80 bzw. 120 gesetzt werden muß. Da es bei mir aber 
mit der 4Grau trotzdem geklappt hat, muß mein GrafikConverter die Daten 
anders aufbereiten.
Könnt ihr mir euren Converter verraten?

Bruno

Ich melde mich noch einmal. Das mit dem GrafikConverter hat sich 
erübrigt. Ich habe die richtige Einstellung gefunden.

Bruno

Ich habe noch etwas rumgespielt und dabei folgendes festgestellt:
Wenn ich 4grau haben will, muß ich den xs Wert tatsächlich verdoppeln. 
Nur die Anzahl Bytes des Bildes funktioniert nicht. Man sieht dann immer 
nur das halbe Bild durchlaufen. Wenn ich 8grau haben will, darf ich den 
xs Wert hingegen nicht erhöhen.
Jetzt würde mich natürlich schon interessieren, ob es am GrafikConverter 
liegt, oder am Code.

Hallo Helfender,

genau so hatte ich dich verstanden! Aber das scheint nicht zu stimmen.
Für die 2grau und 8grau passt es, aber für die 4grau muß ich xs=80, 
ys=240 eingeben. Alles andere funktioniert nicht. Offensichtlich war das 
von Benedikt auch so vorgesehen, da er am 1.6.2009 die anliegende Datei 
ins Forum gestellt hat. Die Befehlszeile ist darin 0x10, 0xAA, 0x00, 
0x00, 0x3C, 0xF0, 0x01, d.h. er hat für ein 30 Byte breites Bild xs=60 
eingegeben.

> Ich hatte bei meinen Bildern
> immer einen Clear-Befehl (12) an den Anfang gesetzt und das verträgt der
> Code offensichtlich nicht.

Der sollte eigentlich keine Probleme machen. Wenn du allerding den 
Busy-pin nicht abfragst kann das leicht probleme machen. Clear brauch 
relativ lang zum ausführen. Wenn du jetzt blind daten sendest wird 
erstmal der Puffer vollgeschrieben. Danach gehn die Daten verloren bis 
Clear fertig ist. Könnte durchaus sein, dass das in etwas eine halbe 
Bildzeile ist. Als Resultat ist dann das gesamte Bild ein Stück nach 
links verschoben und das was links rausgeschoben wurde wird rechts 
angezeigt.

Zu deinem xs-problem kann ich dir nicht wirklich helfen. Was ich nach 
kurzem Überfliegen aus dem code gelesen habe ist, dass für 1bbp und 3bbp 
der maximalwert für xs 40 ist und für 2bbp 80. Sicher bin ich mir aber 
auch nicht. Erscheint irgendwie unlogisch. Ich weiß nur noch, dass mir 
der xs-wert auch ständig probleme gemacht hat als ich die 3ppb 
programmiert habe.

Sebastian

Herzlichen Dank für eure Antworten!

Ich habe das mit dem Busy Pin zwar schon gelesen, aber ich weiß nicht 
wie ich das realisieren kann. Eigentlich wäre es doch sinnvoll die 
Abfrage in den Übertragungscode einzubauen (bei mir scheitert das aber 
noch immer am C++), oder welche Möglichkeiten gibt es sonst noch? In der 
Zwischenzeit hatte ich selbst festgestellt, daß es funktioniert, wenn 
ich nach dem "Clear" ca 500 Leerbytes einfüge.
Das mit dem xs ist kein Problem mehr, da ich ja nun weiß was ich tun 
muß.

Gruß Bruno

Nachtrag:

Beim Übertragungscode meinte ich eigentlich Empfängercode. Wenn ich die 
Daten per µC sende läßt es sich sicher relativ einfach realisieren, da 
ich aber immer mit HTerm sprich vom PC sende, kenne ich keine Lösung.

Bruno

Ich weiß jetzt zwar nicht genau wo dein problem liegt, aber vielleicht 
hilft dir ja das CTS-Signal der RS232-schnittstelle.

Herzlichen Dank für den Tip!
HTerm hat ja tatsächlich ein CTS Kästchen zum Ankreuzen (Flow control), 
nur leider scheint es nicht zu funktionieren. Bei mir bleibt die 
Übertragung jedenfalls schon am Anfang hängen.
Trotzdem habe ich aber kein wirkliches Problem, da es ja einige 
Alternativen gibt.

Bruno

Du musst dann natürlich auch Physikalisch CTS der RS232 und Busy vom 
Controller verbinden. Ich weiß auch nicht, ob die beiden Signale von der 
Polarität zusammenpassen. Und bevor du sie einfach zusammenlötest denk 
auch mal über die Pegel nach, die drauf liegen.

http://de.wikipedia.org/wiki/EIA-232

Sebastian

Da du mir dieses Thema schon so nahe bringst, bleibt mir ja gar nichts 
anderes übrig, als mich etwas näher damit zu befassen.
Ich habe also angefangen mich mit der RS232 und dem busy pin zu 
beschäftigen und stoße natürlich wieder auf Fragen.
Als erstes habe ich die Spannung am PIN D2 gemessen und festgestellt, 
daß er auf high steht.  Nach der Erklärung von Benedikt, müßte ihn aber 
doch das Programm hochziehen, wenn der Puffer zu 3/4 gefüllt ist.
Schaue ich nun in den Ursprungscode von Benedikt, dann hat er in der 
"int main" PORTD=3 und DDRD=254 gesetzt. Danach wäre der Pin D2 ein 
Ausgang mit 0 Level. Dann dürfte er also nicht auf high stehen.
Schaue ich aber nun in die von Benedikt modifizierte, oder auch in deine 
8grau Version, dann wird PORTD=7 gesetzt. Damit ist D2 immer high. Wie 
paßt das zusammen???

Bruno

Mit HTerm geht es mir ähnlich.
Laut Beschreibung sollte die Übertragung gestoppt werden, wenn CTS high 
geht.
Die Spannung am CTS Pin ist auch normal 0. Nur funktioniert dann die 
Übertragung nicht. Wenn ich CTS high setze wird zwar übertragen, aber am 
Display kommt nur Datenmüll an?????
Hast du mit HTerm Erfahrung?

Bruno

Ne, leider überhaupt keine Erfahrung mit HTerm. Und auch allgmein so gut 
wie nichts an der PC-RS232 gemacht. Kann also kaum helfen. Bzw. halt nur 
dokumentattion lesen, aber das kannst du ja auch selbst machen. Der 
Busy-pin des Displaycontrollers verhält sich bei mir so wies in dem 
beigelegten pdf steht (also das aus der .zip). Gib nicht zu viel auf den 
wert, auf den Busy initialisiert wird. Es zählt nur, wie das ganze in 
der UART-lib behandelt wird.
Pass bei RS232 mit high/low auf. Ich hab irgendwas im Kopf, dass da 
logisch 1 = physikalisch low ist. Aber sicher bin ich mir da auch nicht.

Hallo,

hat jemand schon mal bei einem Mega162 mehr als einen Zeichensatz 
eingebaut ? Der Speicher sollte das ja zulassen, oder ? Da die beiden ja 
Pin-kompatibel sind, könnte man ja den 8515 schön damit ersetzen.


Das wäre für mich ne ziemliche Erleichterung, da ich (noch) nicht so 
viel Erfahrung mit C habe. Ich programmiere zwar schon ein paar Jahre, 
aber meist eben mit Bascom oder Delphi und nicht in C. (Ich arbeite 
grade dran :-) )

Gruß

Markus

Hi !

hat überhaupt schon jemand den ATMega 162 bei dem Projekt eingesetzt ?
Der 8515 ist im Moment leider nicht zu bekommen und ich müsste eins 
meiner Boards ersetzen ..


Gruß Markus

Die haben den 8515 als DIP (erlauben leider keinen direktlink):
http://www.csd-electronics.de
Reichelt hat ihn als PLCC:
http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=A363;GROUPID=2959;ARTICLE=47365;START=0;SORT=artnr;OFFSET=500;SID=312DLrCawQAR8AAFDRLwge20a5628acfd6c3563eb32d5f802a711
als TQFP:
http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=A363;GROUPID=2959;ARTICLE=50557;START=0;SORT=artnr;OFFSET=500;SID=312DLrCawQAR8AAFDRLwge20a5628acfd6c3563eb32d5f802a711
und hier gibts ihn nochmal als DIP (wieder kein direktlink):
http://www.segor.de

Bei mir kannst du auch einen als DIP (und ich glaube auch als TQFP) im 
tausch gegen einen 12er Metallbohrer haben. Und ein paar andere 
Versender haben ihn sicher auch auf lager ;)

Gruß, Sebastian

@Alex (Gast)

ich hab noch ein paar Platinen machen lassen, die sollten am 27.11
eintreffen

Wigbert

Hallo Wigbert,

wenn Du noch Platinen übrig hast, die Du nicht brauchst hätte ich auch 
Interesse.

Gruß Markus

Ich hatte das mal angekündigt, hat sich etwas verzögert.
Wie gesagt Platinen + NAN-YA Adapter werden geliefert.

Preise und Bauteile siehe

Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"

Wigbert

Hallo,

ich bin neu bei diesem Projekt. Ich habe fast den ganzen Tag damit 
verbracht, den Thread mit den vielen Links zu lesen und halbwegs zu 
verstehen. Ein wirklich tolles Projekt.

Nun würde ich ebenfalls gerne loslegen - doch Pollin hat all die schönen 
Displays mit CCFL Hintergrundbeleuchtung bis auf eine Ausnahme (Best.Nr. 
120 486) ausverkauft. Und dummerweise fehlt hier das Datenblatt.

Wer von euch hat besagtes Display vielleicht schon einmal eingesetzt 
oder kennt die Anschlussbelegung ?
Oder eine andere Bezugsquelle als Pollin für solche Displays mit CCFL?

Vielen Dank schon mal!

Gruß

Josef

Hat jemand das schon auf dem LCD TG322450 von Pollin zum laufen 
bekommen? :)

Liebste Grüße
Florian

Hallo.

Ja, geht problemlos, musst bloss eine Positive Kontrastspannung 
generieren.

CU
Bernd

Hi,
die GLCD_32K Platinen und auch die NANYA Adapterplatinen
sind jetzt vorrätig. Vielleicht gerade richtig zur kalten
Jahreszeit. Ich hab mal schnell von der Serie eine aufgebaut,
lief promt auf Anhieb. Einige Verbestellungen schreibe ich noch
mal an, ansonsten bitte eine Mail.

Wigbert

Hi @ all,

ich (bzw. mein Vater und ich) haben uns von Wigbert 2 Platinen besorgt.

Meine funktioniert auch schon wunderbar (mein Vater ist noch am 
Bestücken), VIELEN DANK AN WIGBERT UND BENEDIKT!


Aber ich komme mit der Grafik konvertierung und dem Bild Befehl nicht 
klar.

Wie das mit 1bpp läuft ist mir in der Theorie klar. Aber wie läuft das 
mit 2bpp (4 Graustufen) und 3bpp (8 Graustufen)?

Ich verstehe die (leider ziemlich knappe) Erklärung in dem .pdf nicht so 
wirklich.


Werden bei 2bpp immer 2 aufeinanderfolgende Bits zusammengefasst und 
stehen dann sozusagen 4 Pixel in einem Byte? Wie soll des bei 3bpp 
funktionieren? stehen dann 2,67 Pixel in einem Byte???????????

Wie konvertiere ich das Bild im Anhang (ist momentan mit 8bpp Farbtiefe 
aufgelöst) nach 2 oder 3bpp? 1bpp müsste ja Schwarz Weiß entsprechen 
(macht ja Paint).

Wie bekomme ich dann die Tabelle aus der Grafikdatei?


Ich selbt benutze Bascom AVR zum Programmieren.


Ich hoffe es kann mir jemand weiterhelfen, wie ich das (oder ein 
beliebiges Bild) auf das Display bringe.


Mfg Bimbo385

Richtig, bei 2 und 3 bpp werden immer 2 bzw. 3 aufeinanderfolgende bit 
zu einem Pixel zusammengefasst. Bei 3bpp müssen dann immer 3 Byte 
zusammen gesendet werden, damit Pixelgrenze und Bytegrenze wieder 
zusammenfallen. Also immer vielfache von 8 pixeln. Hier und an vielen 
anderen Stellen im Thread wurde das schonmal erklärt:
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"

Konvertieren kann mit dem hier ganz gut:
Beitrag "Grafikkonverter Tool für AVR/Mikrocontroller (BMP2C, BMP2ASM, BMP2BASCOM)"

Gruß, Sebastian

Total Geil!


Alles funktioniert wie es soll.

Danke dir Sebastian! und euch Allen!!!


@ Wigbert:

Ich möchte allen vorsichtshalber mitteilen, dass es bei FFC-Buchsen 
welche gibt, bei denen die Kontakte des Folienleiter zur Platine zeigen 
müssen (beim Reinstecken) (solche hat Wigbert) und, dass es FFC-Buchsen 
gibt, bei denen die Kontakte des Folienleiters nach oben (also von der 
Platine weg)
zeigen müssen (solche habe nämlich ich).

Somit hängt es von der verwendeten FFC-Buchse ab, wierum die kleine 
NANYA Adapterplatine (von Wigbert) auf die Hauptplatine von Wigbert 
gelötet werden muss.

Bie mir muss man, im Gegensatz zu Wigberts Fotos, die FFC-Buchse von 
oben sehen können.

Auf jeden Fall muss sich am Ende Die blaue Beschriftung des 
Folienleiters auf der Bestückungsseite der Hauptplatine befinden.





Außerdem möchte ich die Frage nach dem Inverter für die 
Hintergrundbeleuchtung nochmal aufwerfen. Ich habe noch so einen 
Schwarzen Kasten für 2x 30cm CCFL's (Casemodding). Kann ich den einfach 
verwenden?

Hat das schon mal jemand gemacht?




Mfg Bimbo385

PS: Die HEX-Datei im Anhang kann man mit HTerm senden und enthält den 
Befehl für die Bildausgabe!

@Bimbo 385 (bimbo385)

Danke für den Hinweis. Auf der Platine ist ein Pin, auf der die
Adapterplatine aufgesteckt wird, sicherheitshalber mit 1
gekennzeichnet.
Also schön aufpassen! Ich erweitere mal meinen beigelegten
Merkzettel, wenn meine FFC Buchsen nicht verwendet werden.
Die Adapterplatinen lassen sich ja problemlos drehen.


Wigbert

Hallo Wigbert Picht-dl1atw und Günter S.

Hat einer von euch noch Platinen abzugeben?

vielen Dank!

mfg
Andreas

@Andreas Pachler (Firma: No Company) (arsirc)

Ja, schick mir eine Mail

Wigbert

@neuer:

Ich hab mir deinen Code jetzt nicht genau angeschaut, aber dein Problem 
könnte schlicht darin liegen, dass du die Falsche Funktion aufrufst.
Für 8-Graustufen-bilder darfst du nicht mit lcd_writebyte schreiben 
sondern musst lcd_writebyteg8 nehmen. Beachte, dass lcd_writebyteg8 mehr 
Parameter verlangt.
Wenn du Die 8-Grastufen-daten mit der lcd_writebyte schreibst kommt 
jedenfalls nur müll im Speicher an ;)

Sebastian

Nachdem ich nur mutmaßen kann wo der Fehler ursprünglich ist erklär ichs 
mal bissl ausführlicher - sollst ja auch wissen, was du da tust ;)

Es gibt prinzipiell mal zwei Stellen, wo man die Graustufenzahl 
einstellen kann. Das erste ist bei den Parametern - hier stellt man ein, 
mit wie vielen Graustufen der Controller arbeitet. Dabei ändert sich 
primär die Organisation des RAMs. Stellt man hier 2 ein kann der 
Controller einfach nichts mit 4 oder 8 Graustufen anfangen. Umgekehrt 
kann aber ein 8-Graustufen-build natürlich auch 2 Graustufen anzeigen.
Die andere Ecke ist dann die Datenverarbeitung selbst. Also das, wo man 
am UART-interface zu den Bilddaten noch den Modus mitschicken muss. Über 
den Modus wählt man dann aus, ob die lcd_writebyte, die lcd_writebyteg 
oder die lcd_writebyteg8 verwendet werden soll. Die Routinen erwarten 
dann aber auch entsprechend Daten mit 2,4 bzw 8 Graustufen. Die Art, wie 
die Daten im RAM abgelegt werden regeln die Routinen dann intern. Du 
kannst also per Config auf 8 Graustufen flashen und mit der 
lcd_writebyteg ein 4-Graustufen-bild zeichnen.

Bei dir liegt der Fehler genau bei der Verwendung von lcd_writebyte*. Du 
musst -unabhängig davon was in den Parametern steht- für 
2-Graustufenbilder die lcd_writebyte, für 4-Graustufen die 
lcd_writebyteg und für 8-Graustufen die lcd_writebyteg8 nehmen. Die 
lcd_writebyteg8 erwartet dann aber auch 3 aufeinanderfolgende Datenbytes 
(und natürlich auch eine Vorlage mit 8 Graustufen) und nicht wie bei dir 
dreimal das selbe Byte.

Sebastian

Muss es zwingend möglich sein, beliebige Bildbreiten darzustellen (wenn 
ich deinen Algorithmus richtig interpretiere versuchst du das ja)?
Dann müsstest du nämlich an einem Rand Füll-pixel einfügen um in der 
Breite auf vielfache von 8 pixeln zu kommen. Das geht aber leichter, 
wenn du die Füllpixel gleich im Bild vorsiehst.
Wenn du mit der beschränkung leben kannst, dass die Bildbreite vielfache 
Werte von 8 hat, dann kannst du quasi den Algorithmus aus der main.c 
nehmen und einfach uart_getchar() durch pgm_read_byte(...) ersetzen. Das 
sollte eigentlich recht problemlos laufen.

Wenn du wirklich auf beliebige Breite ohne Füllpixel bestehst muss ich 
dich leider allein lassen. Das erfordert tiefere Eingriffe in die 
lcd_writebyteg8 für dich ich leider keine Zeit habe.

Sebastian

Hallo Leute

Wer könnte mir denn den Code soweit minimieren das ich den 
Displaycontroller nur noch im s/w Modus betreiben kann ohne jeglichen 
Schnick Schnack???

Ich möchte die Daten auch am liebsten parallel (8bit) in den Controller 
schaufeln um so schnell wie möglich ein Bild aufzubauen.

Ich sende momentan nur reine Bilddaten mit 666666 baud. Schriftarten 
werden bei mir in einem anderen Controller erzeugt.

Momentan hängt es bei mir an der Geschwindigkeit der Bildübertragung. 
Die scheint hier einige ms in Anspruch zu nehmen. Ich müsste das Bild 
(320x240) allerdings in weniger als 0,004 s aufgebaut haben.

Ist das Möglich?

Eigentlich bräuchte ich den Grafik-Controller nur als Bildspeicher der 
autark das Timing des Displays übernimmt..

Ich hab nicht soviel (sehr wenig Programiererfahrung) in "C". Ich hoffe, 
mir kann jenand helfen.


Grüße
Steffen

Hallo

@Benedikt

Vieleicht kann mir aber auch der Benedikt nochmal kurz beschreiben wie 
der Ablauf/Timing vom AVR zum Display abläuft. Dann versuch ich es mal 
selber in ASM zu programmieren.

Grüße
Steffen

Die minimal-version kann man sich sehr leicht selbst zusammenstellen 
indem man in den parametern nur die s/w-version auswählt. Die ganzen 
grafikfunktionen verlangsamen das programm wirklich nur unwesentlich. 
Wenn man Text sendet ists vollkommen irrelevant. Und bei den 
Grafikfunktionen ist die Render-Zeit der Grafik deutlich relevanter als 
das, was man sparen würde, wenn man ein Paar der Funktionen 
rausschmeißt.

Über die 4ms solltest du nochmal gut nachdenken. Wie groß ist denn die 
Reaktionszeit deines Panels? Die NANYA-displays, die hier massenhaft 
verwendet werden haben, glaub ich, gute 100ms. In dem Fall wären die 4ms 
vollkommen lächerlich.
Zumal das Display -wenn ich mich recht erinner- auch im sw-Modus mit 
wenigstens 70Hz betrieben wird. Du hast also eh schon bis zu 14ms Latenz 
bis die neuen daten überhaupt angezeigt werden.
Du kannst auch überlegen, das Bild erst zu puffern und dann den 
Bildbereich umzuschalten. In der SW-Version kann man ja bis zu 3 
Vollbilder im Speicher vorhalten. Die Latenz wird dadurch zwar nicht 
kleiner, aber man muss dem Bild nicht beim aufbau zuschaun.

Wenn das alles nichts hilf: Ich hab daheim ne Version, die Bilder mit 
2MBaud entgegen nimmt, ohne den Master dabei zu bremsen. In dem Fall ist 
dann sowohl die CPU als die UART voll ausgelastet (= ca.7fps) - ich weiß 
nicht, wie noch mehr gehn soll. Ist aber nur für 3bpp-bilder 
implementiert und nicht gut dokumentiert. Wenn du willst, kann ich das 
mal hier anhängen, aber anpassen auf SW kann ichs nicht: Leider zu wenig 
Zeit und gerade auch keine Hardware hier ums zu testen.

Parallele Datenübertragung hilft nur, wenn die CPU momentan unterfordert 
ist. Das ist sie aber -soweit ich mich erinner- in der Originalversion 
bei 666kbaud nicht. Nachteil an paralleler Datenübertragung ist, dass 
man entweder Bandbreite verliert, weil der Hardware-Buffer der UART 
während dem Anzeige-Interrupt nicht mehr genutz werden kann, oder einen 
Handshake braucht, den man in Software bedienen muss => CPU-zeit.
=> Parallele Datenübertragung bringt wenn überhaupt nur was, wenn man 
den Anzeigeinterrupt kräftig umbaut und wirklich nur SW anzeigen will. 
Aber auch da wär ich mir nicht sicher. Für 3bpp-bilder dürfte nicht mehr 
als ca. 7fps machbar sein.

Die Ansteuerung des Displays selbst kann man eigentlich ganz gut aus dem 
Datenblatte des Displays (Timingdiagramm) und der Interrupt-Routine des 
Controllers verstehen. Nachdem aber eh nur die High-level-Routinen in C 
geschrieben ist (Der Interrupt ist also in ASM) könntest du auch einfach 
Benedikts Interrupt übernehemen und nur den rest neu implementieren - 
wenn du das denn unbedingt willst.

Viele Grüße,
Sebastian

Hallo Sebastian

>Über die 4ms solltest du nochmal gut nachdenken. Wie groß ist denn die
>Reaktionszeit deines Panels? Die NANYA-displays, die hier massenhaft
>verwendet werden haben, glaub ich, gute 100ms. In dem Fall wären die 4ms
>vollkommen lächerlich.
Ich hab gestern nochmal drüber nachgedacht und du hast völlig Recht! Das 
ist nur Wunschdenken. Außerdem, falls irgendein Display jemals so 
schnell sein sollte, könnte das Menschliche Auge es sowiso nicht einzeln 
folgen..

>Wenn das alles nichts hilf: Ich hab daheim ne Version, die Bilder mit
>2MBaud entgegen nimmt, ohne den Master dabei zu bremsen. In dem Fall ist
>dann sowohl die CPU als die UART voll ausgelastet (= ca.7fps) - ich weiß
>nicht, wie noch mehr gehn soll.
Die Version hattest du mir schon mal vorgeschlagen. Damals wusste ich 
noch nicht so genau wo mein Vorhaben mich hin führt. Wenn ich mit dem 
Display 10fps erreiche wär ich jedoch trotzdem froh. Soll auch alles NUR 
S/W werden. Und ich nutze wirklich nur Bilddaten. Ich hab sozusagen das 
komplette Bild schon im anderen Controller gespeichert und muss es nur 
noch so schnell wie möglich zum Display-Controller schreiben.

>Nachteil an paralleler Datenübertragung ist, dass
>man entweder Bandbreite verliert, weil der Hardware-Buffer der UART
>während dem Anzeige-Interrupt nicht mehr genutz werden kann, oder einen
>Handshake braucht, den man in Software bedienen muss => CPU-zeit.
Also wird hier der Hardwarebuffer der UART genutzt um mehr Zeit für den 
Anzeige-Interrupt zu haben? Ist denn das Timing zum Display so knapp 
bemessen?

>Du kannst auch überlegen, das Bild erst zu puffern und dann den
>Bildbereich umzuschalten. In der SW-Version kann man ja bis zu 3
>Vollbilder im Speicher vorhalten. Die Latenz wird dadurch zwar nicht
>kleiner, aber man muss dem Bild nicht beim aufbau zuschaun.

An genau so etwas hab ich auch gedacht. Zwei Bildspeicher die man nach 
jedem neu empfangenen Bild umschaltet. Soll heißen:
>Bildbereich1: Wird verwendet zum Refresh des Displays durch den Controller
>Bildbereich2: Wird verwendet zum Speichern der neuen Bilddaten
Wurden die neuen Bilddaten übermittelt dan wird umgeschaltet.
>Bildbereich2: Wird verwendet zum Refresh des Displays durch den Controller
>Bildbereich1: Wird verwendet zum Speichern der neuen Bilddaten
Also immer schön im Wechsel.
Ist dies möglich? Ist da mein Ansatz so schon ganz gut?

>Die Ansteuerung des Displays selbst kann man eigentlich ganz gut aus dem
>Datenblatte des Displays (Timingdiagramm) und der Interrupt-Routine des
>Controllers verstehen. Nachdem aber eh nur die High-level-Routinen in C
>geschrieben ist (Der Interrupt ist also in ASM) könntest du auch einfach
>Benedikts Interrupt übernehemen und nur den rest neu implementieren -
>wenn du das denn unbedingt willst.
Ich hab da schon mal durch den Code gesehen. Aber ich kam da wegen dem 
UART nicht mehr weiter. Denn der ist in C geschrieben. Den UART-FIFO hab 
ich da auch nicht mehr nachvollziehen können. Dann noch die ganzen 
Auswahlmöglichkeiten.. Da ist man schnell am Ende wenn man nicht 
wirklich C kann. Na dann werd ich mir am WE wohl mal den ASM Code 
anschauen.

Danke aber trotzdem für deine Hinweise und Hilfe Sebastian.

Grüße
Steffen

> Wenn ich mit dem
> Display 10fps erreiche wär ich jedoch trotzdem froh. Soll auch alles NUR
> S/W werden.

Dann sollten mit 2 Mbaud 20,8fps möglich sein, wenn man den 
Display-Interrupt aufteilt. In SW könnten dann mit parallelem Interface 
sogar noch mehr gehen, aber das wird auf jeden fall aufwändiges gebastel 
und du bräuchtest auch erstmal ein Display, das unter 50ms schaltzeit 
hat.

> Also wird hier der Hardwarebuffer der UART genutzt um mehr Zeit für den
> Anzeige-Interrupt zu haben? Ist denn das Timing zum Display so knapp
> bemessen?

Ja genau. Während dem Displayinterrupt landen die UART-daten erstmal im 
Hardwarepuffer. Der hat 2 oder 3 byte (weiß ich nicht mehr sicher). Ist 
er voll muss der Interrupt fertig sein, sonst gehen daten verloren. 
Darüber bestimmt sich auch die maximale Baudrate. Will man mehr Baudrate 
muss der Interrupt kürzer werden.

> An genau so etwas hab ich auch gedacht. Zwei Bildspeicher die man nach
> jedem neu empfangenen Bild umschaltet. Soll heißen:
>>Bildbereich1: Wird verwendet zum Refresh des Displays durch den Controller
>>Bildbereich2: Wird verwendet zum Speichern der neuen Bilddaten
> Wurden die neuen Bilddaten übermittelt dan wird umgeschaltet.
>>Bildbereich2: Wird verwendet zum Refresh des Displays durch den Controller
>>Bildbereich1: Wird verwendet zum Speichern der neuen Bilddaten
> Also immer schön im Wechsel.
> Ist dies möglich? Ist da mein Ansatz so schon ganz gut?

Genau so wars gemeint. In der aktuellen Version gibts auch schon die 
passenden befehle dafür. Man hat ein Virtuelles Bild das gut dreimal so 
breit ist, wie das was angezeigt werden kann. Mit einem Befehl kann man 
jetzt festlegen ab welcher Spalte angezeigt werden soll, mit einem 
anderen ab welcher Spalte geschrieben werden soll.

> Ich hab da schon mal durch den Code gesehen. Aber ich kam da wegen dem
> UART nicht mehr weiter. Denn der ist in C geschrieben. Den UART-FIFO hab
> ich da auch nicht mehr nachvollziehen können. Dann noch die ganzen
> Auswahlmöglichkeiten.. Da ist man schnell am Ende wenn man nicht
> wirklich C kann. Na dann werd ich mir am WE wohl mal den ASM Code
> anschauen.

Den UART-Code brauchst du nicht anschaun. Das ist eine fertige Library 
(von Peter Fleury glaub ich) die Benedikt recht rabiat umgebaut hat. Für 
so extremen Datendurchsatz (20fps SW) musst du den Software-FIFO sowieso 
rausschmeißen. der braucht zu viel Rechenleistung. Sorge lieber dafür, 
dass beim Bilder übertragen die Daten wenigstens so schnell verarbeitet 
werden, wie sie über die UART kommen. Dann kann der Master einfach so 
schnell senden wie's die Schnittstelle hergibt.
Wichtig ist aber, den Displayinterrupt zu verstehen und verstehen, wie 
die Daten im Speicher hinterlegt sind.

Viele Grüße,
Sebastian

Hallo Sebastian

So, ich hab mich mal rangewagt und so ziemlich viel Code 
rausgeschmissen. Die Übertragung bleibt seriell. Mit 1Mbaud funktioniert 
das ganze noch. Mit 2Mbaud kommen nur noch wilde Streifen, sieht eher 
aus wie rauschen.

Da ich ja sowieso nur reine Bilddaten zum DSP-Controller sende, hab ich 
auch die ganzen anderen Commands rausgeschmissen.
Ich sende jetzt nur noch 0x16, 0xAA, Data_0, Data_1,..,Data_9599. Also 
genau ein Bild der Größe 320x240 pixel.

In der asm routine wird FLM/Frame gesteuert. Der OCR1A (PD5) steuert 
LP/Load und ich denke mal RD steuert XSCL/CP und den 4aus8 MUX und wird 
aktiviert durch einen lesenden Zugriff auf den externen Speicher durch 
ld  Rd, X+.
Richtig so?


>>Was ich überhaupt nicht verstehe:
Wo wird CKDIS gesteuert? Hab ja die ganzen Routinen rausgeschmissen wo 
dies passierte..

Hast du in deiner 2Mbaud Version den UART umgebaut?

Im Anhang mal meine extrem geschrumpfte Version. Aber sie funktioniert!

Grüße Steffen

> So, ich hab mich mal rangewagt und so ziemlich viel Code
> rausgeschmissen. Die Übertragung bleibt seriell. Mit 1Mbaud funktioniert
> das ganze noch. Mit 2Mbaud kommen nur noch wilde Streifen, sieht eher
> aus wie rauschen.

Wenn du mal die Takte des Displayinterrupt zählst und überlegst, wie 
lang ein Byte mit UART braucht - dann noch den Hardwarepuffer bedenken - 
dann sollte klar werden warum ;) Eventuell musst du noch die Latenz des 
UART-interrupt bedenken.
Wenn du mehr willst als 1Mbaud wirst du den Displayinterrupt aufteilen 
müssen. Aber wahrscheinlich nutzt du die 1Mbaud momentan noch nicht mal 
voll. Der Software-FIFO braucht massig Rechenzeit und bremst die UART 
aus.
An deiner Stelle würde ich den Datenempfang per Polling in der 
ASM-Routine erledigen. Aus der brauchst du auch eigentlich garnicht mehr 
rausspringen. Die kann man zur Main-Loop befördern. Muss aber nicht 
sein. Auf die Weise solltest du dann auch Netto 1Mbaud/10fps schaffen. 
Wenn du den Displayinterrupt noch halbierst sollten auch 2Mbaud/20fps 
drin sein.

> In der asm routine wird FLM/Frame gesteuert. Der OCR1A (PD5) steuert
> LP/Load und ich denke mal RD steuert XSCL/CP und den 4aus8 MUX und wird
> aktiviert durch einen lesenden Zugriff auf den externen Speicher durch
> ld  Rd, X+.
> Richtig so?

Sollte stimmen.

>>>Was ich überhaupt nicht verstehe:
> Wo wird CKDIS gesteuert? Hab ja die ganzen Routinen rausgeschmissen wo
> dies passierte..

Was ist CKDIS?

> Hast du in deiner 2Mbaud Version den UART umgebaut?

Ja, der Software-Fifo bremst enorm. Mit dem sind 2Mbaud Netto nicht 
drin. Um 2Mbaud Brutto erstmal zu erreichen muss man aber den 
Displayinterrupt verkürzen.

Viele Grüße,
Sebastian

Danke für deine Hilfe Sebastian

Doch da tun sich gleich wieder Fragen auf:
>Ja, der Software-Fifo bremst enorm. Mit dem sind 2Mbaud Netto nicht
>drin.
Kannst du bitte mal deine 2Mbaud Version anhängen damit ich mal schauen 
kann wie du das gelöst hast?

>Um 2Mbaud Brutto erstmal zu erreichen muss man aber den
>Displayinterrupt verkürzen.
Welcher ist denn der Displayinterrupt?

1

.section .bss

2

XStart:    .ds.b  1

3

YCnt:    .ds.b  1

4

#define XSIZEV  XVSIZESW

5

.section .text

6

.global TIMER1_OVF_vect

7

TIMER1_OVF_vect:

8

  push r16

9

  in r16, _SFR_IO_ADDR(SREG)

10

  push r16

11

  push XL

12

  push XH

13

  push r18

14

  lds XL, viewstart

15

  lds XH, YCnt      // Zeilenadresse laden

16

  inc XH

17

  cbi _SFR_IO_ADDR(PORTD), FLM

18

  ld r16, X+        // 320 bits ausgeben

19

  ld r16, X+

20

  ld r16, X+

21

  ld r16, X+

22

  ld r16, X+

23

        ...

Etwa der hier?

Was genau bedeutet diese Schreibweise hier?

1

.global TIMER1_OVF_vect

>Was ist CKDIS?
Das hier:

1

// PortD

2

#define   CKDIS  3 //?????

3

#define   FLM  4

4

#define   LP  5

5

#define   WR  6

6

#define   RD  7

7

8

// PortE

9

#define   EnLCD  0

10

#define   ALE  1

11

#define   PWM1  2

>An deiner Stelle würde ich den Datenempfang per Polling in der
>ASM-Routine erledigen.
Wenn die ASM-Routine die selbe ist wie die oben erwähnte mit .global 
TIMER1_OVF_vect, dann wird die doch durch den Timer1 angesprungen, 
oder??
Also immer nur in einer bestimmten Zeit! Ich konnt das nicht simulieren, 
da der Simulator dort irgendwie überhaupt nicht reinspringen will. Hab 
versucht mir dort in der Simulation einen Brakepoint zu setzen. Das ging 
irgendwie nicht. Wie gesagt, zu "C" muss ich noch viel lernen..
Sonst hätt ich das alles schon komplett in ASM umgeschrieben. Kann man 
meiner Meinung nach viel besser simulieren!

>Wenn du mal die Takte des Displayinterrupt zählst..
Das bekomm ich hin ;-)
>und überlegst, wie
>lang ein Byte mit UART braucht - dann noch den Hardwarepuffer bedenken -
Ist in "C" geschrieben.. = Bahnhof ganz groß für mich :(
Aber den Empfang bekomm ich auch in ASM hin. Ich sehe nur nicht, dank 
meiner magelnden C-Kentnisse, wo und wie der UART die ankommenden Daten 
speichert. Da ist ja immer noch der Empfangs-FIFO drin. => kein Plan 
hab!

Wäre echt nett mal deine Version kennen zu lernen.

Grüße Steffen

>>Um 2Mbaud Brutto erstmal zu erreichen muss man aber den
>>Displayinterrupt verkürzen.
> Welcher ist denn der Displayinterrupt?
> Etwa der hier?

ja, genau, den meinte ich. Teile ihn in zwei teile und ruf ihn doppelt 
so oft auf. Verkürzen (über Codeoptimierung) wirst du nicht viel können.

> Was genau bedeutet diese Schreibweise hier?
>

1

> .global TIMER1_OVF_vect

2

>

Ist die Sprungmarke für den Timer1 Overflow. Ist ne eigenheit von 
C/ASM-Mischprojekten, dass man diese Formulierung auch noch hinschreiben 
muss.


>>Was ist CKDIS?
> Das hier:

Sicher bin ich mir nicht, aber glaube das ist, um Daten aus dem RAM 
zurücklesen zu können, ohne, dass sie auf dem Display angezeigt werden. 
Am anfang der main wird der Pin initialisiert. Solange du das drinlässt 
kann dir der Pin eigentlich egal sein.

>>An deiner Stelle würde ich den Datenempfang per Polling in der
>>ASM-Routine erledigen.
> Wenn die ASM-Routine die selbe ist wie die oben erwähnte mit .global
> TIMER1_OVF_vect, dann wird die doch durch den Timer1 angesprungen,
> oder??

Nein, ich meinte die lcd_writebyte

> Ich sehe nur nicht, dank
> meiner magelnden C-Kentnisse, wo und wie der UART die ankommenden Daten
> speichert. Da ist ja immer noch der Empfangs-FIFO drin. => kein Plan
> hab!

einfach die ganze library (alle dateien, die irgendwie UART heißen) 
rausschmeißen. Und dann die uart_getchar() selbst implementieren (mit 
polling) oder gleich den gesamten UART-empfang in den ASM-teil 
verfrachten.

> Wäre echt nett mal deine Version kennen zu lernen.

Hab ich angehängt. Hoffe, du verstehst den code halbwegs. Ist für 8 
Grastufen und es ist noch ne Bankumschaltung mit dabei - hab etwas mehr 
RAM an meinem Controller.

Sebastian

Danke dir Sebastian für deine Hilfe. Den Code werde ich morgen mal 
durchforsten.

>Verkürzen (über Codeoptimierung) wirst du nicht viel können.
Ja, da hast du recht.. Das ist schon sehr kutz und knackig gehalten.

>ich meinte die lcd_writebyte
Was genau wird da eigentlich gemacht? Ist die zum speichern der 
empfangenen Daten da?
In der mainloop steht die ja drin. Aber WANN genau wird die aufgerufen?

..und noch was:
Wozu ist eigentlich der COMAND_TIMEOUT gut?

1

#define DOTIMEOUT()  ctimeout=COMMAND_TIMEOUT; while (!uart_data()) if (!ctimeout) goto mainloop

Grüße Steffen

Hallo an alle,

Betr.:  Display Wintek WD-H3224V von Pollin

Nachdem ich nun das Display im Textmodus mit der Schaltung von Benedikt 
zum laufen gebracht habe und den Touchscreen mit Bascom wunderbar 
abfrage habe ich mich an die Grafikvariante von Benedikt getraut aber 
hier gibt es nun bei mir ein Problem.
Wenn ich die Software von Benedikt in den Atmega 8515 lade erhalte ich 
ein sauberes Bild aber keine Graustufen (siehe Foto), lade ich die 
Software von Sebastian in den Atmega erhalte ich zwar 8 Graustufen aber 
das Bild wird im 1. Drittel noch mal dargestellt (siehe Foto). Eine 
Veränderung in den jeweiligen Programmen (Waistate, Framerate usw.) 
bringt keine Verbesserung, kann mir jemand weiterhelfen ???

mfg
Walter10

Das hier:
Marke Cypress Semiconductor Hersteller-Teilenummer CY62256LL-70PXC

Auszug aus dem Datenblatt:


  Address Bus Breite    15Bit
  Anzahl Bits per Word    8Bit
  Anzahl I/O Lines    8Bit
  Anzahl Ports    1
  Anzahl Worte    32K
  Data Rate Architecture    SDR
  Density    256KBit
  Maximum Betriebsstorm    50mA
  Maximum Betriebstemperatur    70°C
  Maximum Random Access Time    70ns
  Minimum Operating Temperatur    0°C
  Mounting    Durchsteckmontage
  Pin Count    28
  Product Height    4.95
  Product Length    37.59
  Product Width    13.97
  Supplier Package    MDIP
  Timing Typ     Asynchron
  Typische Versorgungsspannung    5V

Ja diesen Fehler hatte ich schon vorher, bei meinem Layout war eine 
Verbindung zwischen einer Adressleitung und dem Masse-Polygon was dazu 
geführt hat das die Anzeige unvollständig war also nur Bruchstücke 
angezeigt wurden und versetzt dargestellt wurde. Daraufhin hab ich alle 
Adressleitungen noch mal durch gemessen und überprüft, aber keinen 
Fehler mehr gefunden. Ich werde mir wohl noch mal einen neuen Atmel und 
Speicher besorgen vielleicht haben die etwas abbekommen, oder es gibt 
jemanden der diesen Fehler auch schon mal hatte und eine Lösung kennt.
mfg
walter10

@Walter Hammes

ich lehne mich mal ganz weit aus dem Fenster und behaupte bit 6 oder 7 
der Adressleitungen liegt fest auf einem Pegel :D
Ne, ernsthaft. Der Tip mit den Adressleitungen klingt plausibel, schau 
die mal an.
Aber was anderes: Verwende doch bitte die Version, die Benedikt im 
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" gepostet hat. Das ist 
die letzte offizielle version und enthält auch 8 Graustufen. Die älteren 
Versionen von Benedikt haben teilweise auch noch ein paar Bugs, die da 
nicht mehr enthalten sein sollten. Wenn du weniger Farbe willst 
konfiguriere es über die param.h.
Alles was ich danach noch gepostet hab ist mehr oder weniger 
experimentell. Bei mir läufts/lief es, mehr kann ich aber auch nicht 
garantieren.

@Steffen
Auch wenn du es mitlerweile selbst rausgefunden haben dürftest:

Die lcd_writebyte schreibt die Daten, die an sie übergeben werden, als 
Bilddaten in den RAM. Die Funktion ist also nicht sonderlich 
intelligent. In meiner letzten Version übernimmt die lcd_writebyteg8 
auch noch den Datenempfang selbst. Damit spart man sich das verlassen 
und wieder aufrufen der Funktion, was doch jedes mal einige Takte sind.

COMAND_TIMEOUT ist als Timeout beim Bilder übertragen gedacht. Wenn auf 
dem Weg ein Byte verloren geht würde der Displaycontroller ja erstmal 
ewig auf dieses Byte warten. Die Bild-routine würde erst beendet werden, 
wenn wieder ein neues Byte kommt. Wenn dieses neue Byte zu einen Befehl 
auslösen sollte funktioniert das nicht, weil es ja noch als letzte 
Bild-Byte angesehen wird.
Man kann aber auch einfach eine Hand voll Nullen nach jedem Bild senden, 
dann kann man auf den Timeout verzichten ;)

Sebastian

@Sebastian
@Steffen

Vielen Vielen Dank,

ich habe heute morgen einfach noch mal die kompletten Adressleitungen
vom Ram auf meinem Layout frei gekratzt und siehe da es funktioniert 
tadellos. Das nenne ich absoluten Fachverstand. Vielen Dank. Werde in 
Zukunft größeren Abstand zum Massepolygon lassen. Nun werde ich mal 
versuchen ein paar Kreise und Bilder auf dem Display anzuzeigen.

mfg
walter10

Hallo zusammen,
ich möchte das Projekt auch gerne realisieren, ich warte noch auf die 
Teile, von daher probiere ich schon mal alles zu verstehen.
Was ich nicht verstehe ist warum ad0 vom controller zwar am latch hängt, 
aber nicht weitergeführt wird, an den Speicher?
64K können adressiert werden wir haben aber nur 32K Speicher, da brauch 
man auch keine 16 adressleitungen.
Jedoch ist nicht gerade diese eigentlich notwendig? Ist es nicht das bit 
das angibt ob eine adresse gerade oder ungerade ist?
Oder war es vielleicht doch anders rum und bit0 gibt an ob wie die 
ersten 32K oder die nächsten 32K anschauen?

Jedenfalls ist es in anderen Beispielschaltungen anders die ich gesehen 
habe... Und auf eines von beiden kann man doch nicht verzichten...?

Z.B. Hier:
http://www.mikrocontroller.net/articles/Speicher#Anschluss_an_den_Mikrocontroller

Vielen dank für eure Antworten.

Grüße

Felix

@Peter:

willst du dein Display mit dem Z86 Clone ansteuern? Dann bist du im 
falschen thread. Wenn du das Display mit dem Controller hier aus dem 
Thread ansteuern willst, und diesen Controller dann mit deinem Z86 
Clone, dann passt der Thread. Fertige routinen dürfte es dazu kaum 
geben. Ich hab hier jedenfalls noch keine gesehen. Dein Display müsste 
sich prinzipiell mit Benedikts Controller ansteuern lassen, aber ich 
glaube, du müsstest den Code etwas anpassen.

@Felix:

Auch wenns mit sicherheit schonmal hier im Thread erklärt wurde: Das 
Display will die Daten 4-bit weise. Um die Speicher voll auszunutzen 
speichert Benedikt die daten aber 8-bit weise im Speicher. Um möglichst 
einfach nacheinander an die oberen und unteren 4 bit einer 
Speicheradresse zu kommen wird ad0 nicht zum speicher geführt. Dadurch 
zeigen immer 2 controller-interne Adressen auf die gleiche physikalische 
Speicherstelle. Bei jedem Lesevorgang wird dann noch der Multiplexer 
umgeschaltet und so zwischen den oberen und unteren vier bit ausgewählt.
Warum AD0 jetzt noch gelatcht wird, wird wohl Benedikts geheimnis 
bleiben. Für die Funktion der Schaltung ists egal. Man sollte allerdings 
den Eingang des Latches auf einen definierten pegel legen. Je nach 
layout kanns da durchaus das einfachste sein, ihn mit AD0 zu verbinden.

Viele Grüße, Sebastian

Hi bezüglich der Software kann ich dir auch nicht wirklich helfen das 
ist hier mittlerweile etwas durcheinander geraten.
Ich denke die Letzte von Benedikt sollte die sein die mit dem 
ursprünglichen Projekt am ehesten läuft. Wobei die anderen Softwaren 
sicher auch funktionieren sollten.

Bezüglich des Quarzes:
Es hat seine Gründe weshalb ein 16Mhz Quarz eingesetzt wurde. Da der 
Display Controller ja in Software geschrieben ist benötigt die ganze 
Schaltung erst einmal einen höheren Takt und das Display Timing 
brauchbar zu erzeugen. Ansonsten ist die gGfahr dass das Display stark 
flimmert relativ hoch.

ich hoffe dir soweit schon mal geholfen zu haben.
MfG
Kai

Hi,
das ist hier im Forum die wohl die aktuellste SW.
In der param.h lässt sich alles einstellen.
Die PDF sagt auch was über das Timing (und damit den Takt) des AVRs
aus.

Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"

Langzeiterfahrung habe ich sogar mit der Version 1.0


Man müsste den Beitrag wirklich mal etwas sortieren.

Wigbert

Schöne Feiertage.

Hey Wigbert.
Danke für Deinen Hinweis.
Ich habe jetzt die Firmware aus dem Link geladen, für die Verwendung mit 
einem 12MHz Quarz geändert
[ #define XTAL_CPU      12000000UL ]
und mal in den ersten Testbetrieb genommen.

Jetzt zeigt mir das angeschlossene Display [das Wintek wd-h3224v] nur 
ein schwarzes Bild an, jedoch kann ich kurz nach dem Einschalten 
Benedikts Testscreen einmal aufblitzen sehen, danach wird das Display 
komplett schwarz.

Jemand eine Idee, woran das liegen könnte ?

[ Die Kontrastspannung, die ich von einem MC34063 beziehe, beträgt +26V, 
kann's vielleicht daran liegen ? ]


Gruss,

Martin

Hallo Martin,

die +26V scheinen etwas zu hoch zu sein, sind bei meinen Display's 
zwischen 21,5 und 22V.
Versuch mal zu reduzieren.

Viel Erfolg

Ralf-Peter

Grelli,

erneut meinen Dank - nachdem ich die Kontrastspannung auf ca. 22V 
gedrosselt habe, ist jetzt ein Bildinhalt zu erkennen.

Leider ist dieser noch ein wenig zerschreddert ( nur bestimmte Teile - 
v.a. die Schrift und Teile des Rahmens in Benedikts Testbild, die 
Gradientenlinie wie auch einige der Quadrate sind o.k. ), aber durch 
Deinen Hinweis bin ich schon einen guten Schritt weiter gekommen.

Danke Dir !

Nachtrag:

Ich habe noch ein bisschen herumprobiert - dabei unter anderem auch mal 
die brown out detection [BODEN und BODLEVEL] des Mega8515 angeschaltet.

Siehe da - schon blieb das Display leer.

Also habe ich ein stärkeres Netzteil (1.5A max, anstelle des 350mA) 
ausprobiert - ohne Erfolg.

Kann es überdies sein, dass der "gestörte" Bildinhalt, wie ich ihn im 
vorherigen Post beschrieb, auch damit zusammen hängt ?

Hat jemand eine Idee ?

Hallo Martin,

 -   JEDE   -  Fehlersuche beginnt beim Netzteil !
Wie erzeugst Du die ca. +22V ?

Grelli

Ralf-Peter Grellmann schrieb:
> Wie erzeugst Du die ca. +22V ?

MC43063 mit Widerständen R1 = 1.5k und R2 = 20k.

Die aktuellste offizielle Version ist die, die Benedikt zuletzt gepostet 
hat. Der Link von Wigbert zeigt genau auf den richtigen Post.
Es gibt noch einige andere mehr oder weniger experimentelle Versionen 
für mehr Datendurchsatz oder um das Display hochkant zu verwenden. Die 
würde ich aber nur nehmen, wenn ich sicher weiß, dass meine Hardware 
läuft.

Zum Prozessortakt: Der ist aus sehr gutem Grund auf 16MHz. Der 
Controller muss zwar die Daten nicht erst aus dem RAM zurücklesen um die 
auf dem Display anzuzeigen, aber er gibt den Takt vor, mit dem die Daten 
vom RAM ins Display kommen. Da das in Software gemacht wird, braucht es 
auch einiges an Rechenzeit.

Deine Probleme KÖNNTEN vom zu geringen Takt kommen. Stell mal die 
Anzeigefrequenz auf 3/4 des aktuellen Wertes. Oder deaktiviere die 8 
Graustufen funktion. Oder beides. Oder steck versuchsweise einen 16MHz 
Quarz rein.
Wenn es läuft kannst du die Anzeigefrequenz auch wieder hochdrehen. 
Darunter leidet allerdings die Geschwindigkeit, mit der die Bilder 
aufgebaut werden. Also nicht höher stellen als nötig.

Viele Grüße,

Sebastian

Danke für den Hinweis, Sebastian.

Jedoch dürfte das alleine nicht die Sache mit den brown outs erklären, 
oder ?


Gruss,

Martin

Hallo Martin,
wie sieht eigentlich deine 5Volt Versorgung aus?
Hast du hier einen 5V Festspannungsregler mit entsprechenden 
Kondensatoren?
Der Prozessor sollte seinen obligatorischen 100nF direkt am VCC Pin 
haben.
Da gibts kein wenn und aber. Ich hatte hier bei nem Versuch auch gedacht 
die brauch ich zu testen nicht aber falsch gedacht!
Eventuell noch einen Pullup an Reset schaden tuts nicht. Verbessert auf 
jeden fall das EMV Verhalten.

MfG Kai

Hey Kai.

Die Spannungsquelle ist ein 7805.
Ja, so mehr ich hier lese, desto eher glaube ich, dass ich meinem Board 
noch ein paar Folienkondensatoren und eine Prise Pullups spendieren 
sollte.

Danke für den Hinweis !


Gruss,

Martin

Kleines Update:

An der Frequenz liegt's nicht - ich habe jetzt den 12MHz Quarz durch 
einen 16er ersetzt und auch die entsprechende Firmware [direkt das 
unveränderte "Original"] auf den µC übertragen - das zerschredderte Bild 
bleibt dennoch.

[Zur Erinnerung: Auf dem LCD wird im oberen Drittel der entsprechende 
Teil von Benedikts Testbild verzerrt dargestellt. In den beiden unteren 
Dritteln der Anzeige wiederholt sich dieser Teil.]

Ich habe mir auch nochmal die Musse gegönnt und die Spannungen an den 
VCC der verwendeten ICs nachgemessen [jeweils gegen den entsprechenden 
Massepin] - alle ICs liegen bei ca. 4.2 ~ 4.6 V, was laut den 
Datenblättern kein Problem darstellen dürfte.

[ Vielleicht mit Ausnahme des SRAMs ? Wie kann ich die Spannung dort auf 
einem höheren Level stabil halten ? Der 7805, welchen ich zur 
Spannungsversorgung verwende, spuckt ca. 4.8 V aus. ]


Hat noch jemand eine gute Idee, an welcher Ecke ich mit der Fehlersuche 
weiter machen könnte ?



Gruss,

Martin (a.k.a. der Nachbauer)

Schieß doch mal ein Foto vom Display. Das was angezeigt wird ist klar 
und (halbwegs) kontrastark zu erkennen?

Ist dein RAM groß genug? Hast du irgendwo Adressleitungen vertauscht 
und/oder miteinander verbunden? Gleiches für Datenleitungen? Welche 
Version des Schaltplans hast du verwendet? Die im ersten Posting des 
Threads enthält einen Fehler.

Ich muss aber zugeben, dass ich hier ziemlich im dunklen stocher ;)

Viele Grüße,
Sebastian

Hey Sebastian.

Der SRAM dürfte eine 50ns Variante sein.
Die Schaltpläne habe ich mir auch noch einmal genau angesehen und die 
Leitungen nochmals alle durchgemessen.
So weit kann ich keinen Fehler entdecken.

Anbei eine Aufnahme des angezeigten Bildinhaltes.
Ich hoffe, dass dieser Aufschluss über die mögliche Fehlerursache geben 
kann.


Gruss,

Martin

Hi,
ich hatte mal am Anfang sowas Ähnliches, da war am HC157
Pins vertauscht.

Anbei mal die Schaltung wie sie sein soll.

Wigbert

@Martin:

Da stimmt was an deiner Schaltung nicht ;)

Bei den Leitungen vom HC157 zum Display dürfte eine leitung keinen 
Kontakt haben oder Fest auf Ground gezogen sein (Brücke zur 
Nachbarleitung?)

Die Horizontalen Widerholungen sind etwas komisch, aber normal kommt 
sowas von Fehlern in den Adressleitungen.

Einfach nochmal alles durchschaun und nachmessen ;)

Sebastian

Jetzt erinnere ich mich , am Hc74 war ein Pin vertauscht.

Wigbert

Hallo Wigbert,
hey Sebastian.

Lieben Dank für Eure Hinweise und den Schaltplan.
Ich habe heute Abend alle Kontakte erneut durchgemessen und noch 
fehlende Abblockkondensatoren [je 100nF] vor alle ICs gesetzt.

[Sebastian: ich habe genau darauf geachtet, es ist (leider) keine 
Datenleitung auf Masse gezogen]

Leider stellte sich keine Veränderung am Ergebnis ein.

Vielleicht spielt es eine Rolle: Ich verwende das Wintek WD-H3224V 
Display von Pollin -- mittlerweile das zweite, um ggf. vorhandene 
Probleme auf Seiten des Displays auszuschliessen.

Ich werde Morgen erneut alle Verbindungen durchmessen, um ganz sicher zu 
gehen.


Gruss,

Martin

Heute habe ich mir die Zeit genommen, noch einmal in Ruhe alle Leitungen 
durchzumessen - es ist alles so, wie es sein sollte.

Darüber hinaus konnte ich jedoch eine interessante Beobachtung machen:
Bei einem probeweisen Einschalten der Schaltung gab es mit einem Mal 
erstmals ein einwandfreies Bild.

Natürlich habe ich diesen Zustand auf Reproduzierbarkeit testen wollen, 
jedoch zeigte sich schon beim erneuten Neu-Einschalten wieder die o.g. 
Störung.

Vielleicht könnt Ihr mit dieser Information etwas anfangen.


Gruss,

Martin

Hallo Leute

Ich brauche unbedingt ein EEPROM an dem Mega8515 um ein Bild 
(Startbildschirm) gleich nach der Initialisierung anzuzeigen. Ich habe 
mir dafür ein ATMEL25256A SPI EEPROM ausgesucht. Die Anschlüsse dafür 
wären ja noch frei.

Hab mir auch schon die Application-Note AVR107 (Interfacing AVR serial 
memories) herunter geladen.

Anschlussbelegung:
EEPROM SCK -> SCK  Mega8515
EEPROM SI  -> MOSI Mega8515
EEPROM DO  -> MISO Mega8515
EEPROM /CS -> /SS  Mega8515 -> /CS noch über einen 4k7 Widerstand gegen 
5V

Funktion:
Wenn der Display-Controller initialisiert wurde soll der Startbildschirm 
aus dem EEPROM geladen und sofort angezeigt werden. Danach wird der Uart 
frei gegeben.

Ich hab die Controllerversion auch schonmal so weit abgespeckt (fast 
alle Funktionen entfernt) da ich nur jeweils ein s/w Bild laden muss.

>>Hat schonmal jemand sowas gemacht?
>>Brauche da mal eure HILFE!!!

Ich komm mit "C" einfach nicht klar
Wo definier ich zum Beispiel die Ports für den SPI?

Hab mal die SPI-Treiber und meine Abgespeckte Version mit angehangen

Schau dir mal die lcd.c genauer an. Da wird (wenn ichs richtig im kopf 
hab) alles initialisiert. Da hängst du dann auch die SPI-Init rein.
In der lcd.c wird auch das aktuelle Startbild erzeugt. Diesen Code 
müsstest du dann einfach durch deinen eigenen ersetzen (also daten aus 
SPI laden und über die im pdf dokumentierten subroutinen ins RAM 
schreiben).
Du kannst auch überlegen, ob du dein Bild algorithmisch erzeugen kannst 
(also über rechtecke, kreise, linien, text,...). Dann könntest du dir 
eventuell das externe EEPROM sparen.


EDIT

Ich bin mir nicht sicher, welche Version du runtergeladen hast, aber von 
den experimentellen, die ich noch gepostet habe kann ich nur abraten, 
wenns mit den Programmierkenntnissen nicht sooo gut steht. Die bei dir 
eingestellten 2MBaud machen mich jedenfalls hellhörig. Mit der letzten 
offiziellen Version von Benedikt wird das nicht funktionieren und mit 
meinen experimentellen Versionen könnte sw probleme machen.
Nimm doch bitte diese Version. Die Sollte auf jeden Fall funktionieren:
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"


Viele Grüße,
Sebastian

Hallo Sebastian

Endlich eine Antwort. Huhu..

Meine Baudrate ist momentan bei 1Mbaud. Das funktioniert auch alles 
supi. Ich hab mich heute schon soweit durchgewurschtelt und all die 
SPI-Routinen zum Laufen gebracht.

Jetzt steh ich natürlich wieder auf dem Schlauch, was die Einbindung zum 
RAM angeht.

Hier mal ein kurzer Auszug aus der Funktion zum EEPROM lesen.

Funktion:

1

char GetCharArray(int address, int nb_of_bytes, char* destination);

und hier der code in der "main"

1

int main(void) __attribute__((OS_main));

2

int main(void)

3

{  PORTA=255;

4

  PORTC=255;

5

  PORTD=7;

6

//  DDRB=255;

7

  DDRD=254;

8

  DDRE=255;

9

10

  init_spi_master();

11

12

    int start_address =  0;

13

    static char destArray[2*PAGE_SIZE * sizeof(char)];

14

    static char* dest = destArray;

15

16

  //Read a page

17

    while (GetCharArray(start_address, (PAGE_SIZE-1), dest) != TRANSFER_COMPLETED) {}

18

  //the page is available in the SRAM buffer pointed by dest

19

20

21

  lcd_init();            // LCD Controller initialisieren

22

  uart_init(UART_BAUD(UART_BAUD_RATE, XTAL_CPU),UART_BAUD_U2X(UART_BAUD_RATE, XTAL_CPU));

Ich würde das auch gern in der lcd.c einbinden. Und zwar da wo der RAM 
gelöscht wird.

1

void lcd_clear(void)

2

{  unsigned short i;

3

  for (i=0; i<(65536-DDRAM); i++)

4

    mem[i]=0;

5

}

Wie kann ich jetzt den Pointer auf das Array von den SPI-Daten gleich in 
den Display-RAM schreiben???

Ich glaub ich bin schon so na.. Aber ich bekomms einfach nicht hin!

Kanst du mir da noch helfen?

LG Steffen

Ach ja, mein Bild im EEPROM hat 320x240 Bit (40x240 Byte)

Ach und hier mal als Bild

Ich denke mal ich muss

1

unsigned char * const mem=(unsigned char * const)DDRAM;

nur igendwie mit dem Array

1

static char destArray[2*PAGE_SIZE * sizeof(char)];

2

static char* dest = destArray;

verbinden, oder??

"Einfach so" in den RAM schreiben funktioniert nicht, weil die Daten 
nicht linear im RAM abgelegt sind. Nimm die vorhandenen Subroutinen. Für 
dich also die lcd_writebyte. Der Aufruf davon ist im pdf aus dem 
projekt-zip dokumentiert.
In die lcd_clear würde ich das nicht hängen. Ist einfach unsauber. 
Schreib dir eine eigene Funktion, die die Daten aus dem EEPROM ausliest 
und dann mit lcd_writebyte in den RAM schreibt. Die rufst du dann da 
auf, wo auch aktuell das Startbild erzeugt wird.

Wenn du Benedikts Version verwendest läuft 1MBaud aber nur sauber, wenn 
du mit dem Master nicht so schnell senden kannst, wie es der Slave 
zulässt. Eigentlich ist nämlich der Displayinterrupt zu lang, sodass du 
Bytes verlieren würdest.

Noch ne andere Idee: Du steuerst das Display ja eh von außerhalb an. 
Wieso nicht einfach von dort das Startbild reinschieben? Dann sparst dus 
dir an einem fremden System zu basteln. Das aktuelle Startbild kann man 
ja rauskommentieren. Dann bleibt das Display schwarz, bis was an der 
UART kommt.

Sebastian

HAllo Sebastian

>"Einfach so" in den RAM schreiben funktioniert nicht, weil die Daten
>nicht linear im RAM abgelegt sind.
Das hab ich gestern auch noch gemerkt. :(

>Schreib dir eine eigene Funktion, die die Daten aus dem EEPROM ausliest
>und dann mit lcd_writebyte in den RAM schreibt. Die rufst du dann da
>auf, wo auch aktuell das Startbild erzeugt wird.
So hab ich es jetzt erst mal gelöst. Ich verwende nun die 
"lcd_writebyte(x,y,c)". Und es funktioniert erst mal soweit wie es 
aussieht. Allerdings etwas unschön. Ich hol mir jetzt momentan jedes 
einzelne Byte vom EEPROM und sende es gleich danach weiter über die 
"lcd_writebyte". Das heißt für jeden EEPROM Zugriff habe ich jetzt einen 
Head von 4 Byte für ein Nutz-Byte. Das ist eher subotimal. Wenn ich den 
EEPROM mit dem Bild gefüllt habe häng ich mal ein Bild an. (PonyProg 
funktioniert dafür leider doch nicht)

>Wenn du Benedikts Version verwendest läuft 1MBaud aber nur sauber, wenn
>du mit dem Master nicht so schnell senden kannst, wie es der Slave
>zulässt. Eigentlich ist nämlich der Displayinterrupt zu lang, sodass du
>Bytes verlieren würdest.
Ich weiß. Ich muss natürlich das Busy beim Senden abfragen. Und schon 
sind es effektiv keine 1Mbaud mehr. Aber es reicht mir so.

>Das aktuelle Startbild kann man ja rauskommentieren. Dann bleibt das >Display 
schwarz, bis was an der UART kommt.
Das hab ich schon gemacht. Ich habe ja bis jetzt keinen Startbildschirm 
mehr.

>Noch ne andere Idee: Du steuerst das Display ja eh von außerhalb an.
>Wieso nicht einfach von dort das Startbild reinschieben?
Das wär die einfachste Lösung. Aber der andere Controller hat einen 
Bootloader drauf der nach den Reset/Einschalten erstmal ca 5sec wartet 
bis er die Application startet. Deswegen möchte ich ja auch in dieser 
Zeit ein Startbild im Display anzeigen und kein schwarzen Bildschirm.

Hallo

So, ich hab es nun endlich hinbekommen. Der Startbildschirm läuft nun 
endlich direkt aus dem EEPROM der einfach an der ISP Buchse hängt.

Steffen

Hallo zusammen,
ich hab mal eine Frage an die Bild Spezialisten.
Mein Touchscreen von Pollin im 8 Graustufen Modus funktioniert 
wunderbar, ich kann Rechtecke, Kreise und Linien darstellen und das 
Touchpad abfragen  nur würde ich gerne mal ein Bild anzeigen ,aber hier 
komme ich zu keinem Erfolg, ich Programmiere in Bascom und steuere den 
8515 mit einem Atmega32 an. Die Anleitung in Bascom hier im Forum zur 
Anzeige des Hasen funktioniert einfach nicht bei mir. Wäre es möglich 
eventuell eine kleine Anleitung zu geben ? (z.B Bild mit Grafikkonverter 
umwandeln, welche Einstellung, Erzeugte Daten in Bascom einbinden und an 
8515 übergeben mit Hinwies zu den Graustufen und Pointervarialblen zu 
den Datenbanken)

Vielen Dank
walter10

Hallo Walter,

hast du dir den Thread (ab da, wo es die 8Graustufen-Version gibt) 
durchgelesen? Mit den Bildern hatten schon einige Probleme. Vielleicht 
findest du da was. Im Doku-pdf ist glaube ich ein kleiner Fehler drin 
beim Senden von 3bit Bildern. Um dir zu helfen wäre es hilfreich, wenn 
du mal postest, was du überhaupt an den Controller sendest, und was das 
Display dann macht. Ich kann dir aber nicht versprechen zu antworten. 
Bin grade im Urlaub.

Viele Grüße,
Sebastian

Hallo zusammen,
also ich hab jetzt soweit alles mögliche versucht und habe immer das 
Problem das die Bilder nach ca 3 mm von oben verschoben sind, egal wo 
ich sie auf dem Display hinsetzte. Ich hab mal ein Bild aus dem 
Grafikkonverter auf 208x144 Pixel verkleinert und im Floyd-Steinberg 
Verfahren umgewandelt und entsprechend für Bascom nachbereitet ergibt 
dann 3744 Bytes wie in der Anleitung und sende diese Daten zum Display. 
Auch wenn ich den Hasen aus dem Forum nehme und die Daten ausgebe sind 
die Füße von dem Hasen nach rechts verschoben, kann da eventuell ein 
Hardwarefehler vorliegen. Zur Kontrolle hab ich auch mal das 
Basicprogramm mit eingestellt.
mfg
walter10

Könnte gut am gewählten Quarz und der Baudrate liegen.
10,24MHz sind sehr ungewöhnlich.
10,24MHz und 57,6kBaud hat ne Fehlerrate von rund 1% da kann es sehr gut 
sein das der Empfänger hin und wieder mist empfängt und das bild dann so 
aussieht.

Versuch mal einen anderen Quarz am besten einen Baudraten Quarz wie z.B. 
14.7456 MHz oder auch 12MHz.

Tritt der Effekt immer an der selben Stelle oder immer an 
unterschiedlichen Stellen auf?

Also hab mir einen 14.7456 MHz Quarz besorgt und neu Compiliert aber der 
Fehler bleibt ca. die ersten paar Zeilen sind korrekt und dann macht das 
Bild einen Sprung  und wird verschoben und der rechte Teil wird links 
angelegt und das Gesamtbild wird nach rechts verschoben. Das Problem 
tritt immer auf egal wo ich das Bild auf dem Display platziere. PS. der 
10,24MHz Quarz war noch ungenutzt, den 14,7456 Mhz hab ich aus meinem 
AVR-Server mit Kamera ausbauen müssen.
mfg
walter10

mal die ganze Sub für mein "Karnickel"

Sub Bild
Local Count As Word
Local B As Byte
If Bild_bit = 1 Then                             'Flag, woher auch immer
 Printbin 16 ; 170 ; 30 ; 63 ; 8 ; 64 ; 0                   ' Bildplatz
  If Wahl = 0 Then Restore Hase :                           'Bildauswahl
  If Wahl = 1 Then Restore Schildkroete :
  If Wahl = 2 Then Restore Taste :
  For Count = 1 To 512                                      'hole Byte
  Read B
  Printbin B
 Next Count
Bild_bit = 0                                         'Flag auf 0 setzen
End If
End Sub

Ich hatte das mit Bitmap_Converter in C ausgegeben und für Bascom
umgeschrieben.

Vielleicht ist was Hilfreich.

Wigbert

Hab ich gemacht und so sieht das Ergebnis aus:


siehe Bild

walter10

Es funktioniert:
Aber ich mußte mir nochmal fast das ganze Forum durchlesen um den Fehler 
zu finden, es liegt nicht am Quarz. Und zwar der Beitrag von Bruno M hat 
mich auf die Lösung gebracht. Es ist ganz alleine der Clear 
Befehl(Printbin 12)  wenn der vorher gesendet wird, dann klappt es nicht 
mit den Bildern. Weiß jetzt nicht ob das nur an Bascom liegt aber 
irgendwie werd ich das jetzt hinbekommen, und mich nun mal mit den 
Graustufen beschäftigen.
Vielen Dank

walter10

Hallo Walter,

du handlest das Busy-signal nicht richtig. Wenn du das richtig machst, 
ists auch egal, welcher Befehl vorher kommt.
Sobald das Busy-signal anliegt darfst du nur noch eine Hand voll Bytes 
an den Displaycontroller schicken. Wie viele das sind sollte im Doku-pdf 
stehen. Wenn du das in den Sourcen anders konfiguriert hast musst du 
dich natürlich an deine Konfig halten.

Bei dir passiert momentan folgendes: Du Lässt das Display löschen und 
sendest gleich die ersten Bilddaten. Die kommen dann erstmal in den 
Puffer des Displaycontrollers. Der ist aber voll, bevor der lösch-befehl 
abgearbeitet ist - genau hier gehen dir Daten verloren. Dadurch entsteht 
der Versatz.

Viele Grüße,
Sebastian

Hallo,

Ich mir mal so überlegt, ob man mit einem ATmega1284P-PU (gibt es bei 
Pollin) nicht sogar den LCD-8Graustufen_Grafikcontroller implementieren 
könnte.

Der ATmega1284P-PU hat intern 16kByte RAM !!!

Damit könnte einiges an Hardware des LCD-8Graustufen_Grafikcontroller 
wegfallen und der Aufbau sich ähnlich einfach gestalten wie hier dieser 
LCD-Text_Controller.

Was meint ihr??

Um es kurz zu machen: Nein. ;)

Die 16kByte würden erstmal eh nur für S/W reichen. 4 Graustufen brauchen 
18,75kByte und 8 Graustufen brauchen 28,125kByte für je ein Vollbild.

Wenn man sich auf S/W beschränkt könnte es hinhaun, hab ich aber nicht 
durchgerechnet. Aber sobald du Graustufen willst wirds mindestens knapp, 
wenn nicht unmöglich (abgesehen vom Speichermangel). Benedikts Schaltung 
ist so gebaut, dass für einen Displayrefresh die Daten direkt vom RAM 
ins Display geladen werden. Der Controller gibt nur den Takt vor. 
Würdest du die Daten im internen RAM vorhalten, müsste die CPU erst den 
RAM auslesen und die Daten dann auf einem Port dem Display zur Verfügung 
stellen. Die Steuersignale des Displays kämen dann auch noch dazu. Das 
dauert definitiv länger, auch wenn die Zugriffszeit im internen Ram 
etwas kürzer ist. Du kaufst dir den geringeren Schaltungsaufwand also 
durch mehr CPU-Last, was die Framerate deutlich drücken dürfte.

Aber schau dir doch mal den LCD-Controller im Textmodus (da hast du ja 
unerhörterweise genau das gleiche gepostet) genauer an. Vielleicht 
kannst du den mit Hilfe des Mega1284 soweit aufbohren, dass er 
grafikfähig wird. Ich kenne die Software des Textcontrollers nicht 
genau, aber eigentlich müsste es (mit genug RAM) möglich sein, dem 
Grafik beizubringen.

Oder was viel Sinnvoller wäre: Nimm einen der vielen Displaycontroller 
die es gibt. Zum Beispiel von Epson. Das verringert den 
Schaltungsaufwand auch enorm und dürfte sogar eine deutlich höhere 
Leistung bringen als die Lösung hier.

Sebastian

Sebastian ... schrieb:
> Die 16kByte würden erstmal eh nur für S/W reichen. 4 Graustufen brauchen
> 18,75kByte und 8 Graustufen brauchen 28,125kByte für je ein Vollbild.

Ja, das hab ich wirklich nicht bedacht. Da hast du wohl recht Sebastian. 
Dann lohnt es sich wirklich nicht mit dem ATmega1284 rum zu 
experimentieren. Der kostet ja auch immerhin min. 7 Euronen.

Naja, war halt nur mal so eine Überlegung..

LG Steffen

>Hat noch wer ne unbestückte platine zum
>verkauf?

Ich, schick mir eine Mail.

Wigbert

Hi,

mal was neues von der GLCD-Front.

Ein SP14Q002 an Benedikts Graphikkarte. Zusätzlich muss nur
ein Poti die Spannung V0 einstellen.
Es ist etwas grösser wie das NANYA. Blauer Hintergrund.

Preis des Displays etwa 9 Euro+Versand.

Eine Adapterplatine ist auch schon geroutet.

Ich mach noch ein paar SW Tests und könnte mir dann eine
Sammelbestellung vorstellen.

Vielleicht noch was für Weihnachten.

Wigbert

Hey Wigbert.

Würden bei der Sammelbestellung auch wieder Platinen mit aufgegeben ?
Oder hast Du ggf. noch eine rumliegen ?

Hallo,

ich habe heute noch mal die Display-Platine an die RS232 Schnittstelle
gehangen.

Mal zur Ansicht, ein halb invertiertes Display bei Spannungswerte
VEE, V0 laut DBL. Man kann mit dem Display sicher keine Wunder
erwarten, aber ein kostengünstiges Spielzeug.

@Martin Schröer

ich hatte an ein Bausatz mit folgendem Umfang gedacht:
Graphikkartenplatine; Adapterplatine für GLCD; FFC Buchse;
S-Ram;alle SMD; Speicherspule; und das GLCD.

Schönes Wochenende.

Wigbert

Hallo Wigbert

Wenn man sich schon so konsequent mit den GLCD's wie du beschäftigst, 
warum integrierst du nicht auch gleich den Inverter für die 
Hintergrundbeleuchtung mit in das Layout?

@Steffen H.

na ja, sooo viel mach ich auch wieder nicht.

Ein Inverter nachbauen lohnt sich wohl preislich kaum.
Ich wollte Benedikts GRAKA nicht sterben lassen, nur weil es
keine NAN-YAs mehr gibt und such immer nach Ersatzdisplays.
Wobei, für Hinweise bin ich immer offen. Ich hatte schon mal
in Erwägung gezogen ein Inverter aufzustecken. Die
Spannungsversorgung(5V) ist ja schon auf dem Board vorgesehen.

Wigbert

Hier mal ein Vorschlag für einen Inverter. Diese Schaltung funktioniert 
so bei meinen Displays schon seit Langem.

Den CCFL Trafo bekommt man leider nur bei DigiKey, Mouser oder auch 
Farnell.

Gruß Steffen

>Den CCFL Trafo bekommt man leider nur bei DigiKey, Mouser oder auch
>Farnell.

Eigentlich kommt wohl nur Digikey in Frage. Ca 4-5 Euro
für den Trafo.
Steffen hast Du mal auch Langzeittests gemacht? Bei zu
hohen Strom leiden sicher die CCFL-Röhren.

Wigbert

Diese Schaltung wurde schon ausgiebig getestet und wird in medtec 
Produkten so verbaut.

Bei mir selber läuft das ganze schon länger als 2Jahre ohne die CCFL 
Röhre zerstört zu haben.

Hi,
der Adapter-Prototyp des SP14Q002 läuft anstandslos auf mein Board.
Ich denke, anfang des neuen Jahres werde ich einige machen lassen.

Ansonsten: Siehe Testbild

Wigbert

Moin allerseits,
Ich habe mal wieder ein tolles e-Bucht Angebot genutzt und mir 2 Epson 
EG-4801-ER gekauft...
Nun zu meiner Frage, das Display hat eine Auflösung von 512*128 Pixel, 
bekomme ich den Controller soweit "aufgebohrt"?

Das Datenblatt ist übrigens hier:

http://www.knjn.com/files/512%20x%20128%20Graphic%20LCD%20Display%20-%20EG4801.pdf

MfG

Sollte recht problemlos gehen.
Die Ansteuerung des Displays scheint auf den ersten blick sehr ähnlich 
zu den hier verwendeten zu sein, also wenig oder keine anpassungen an 
der Hardware nötig. Die Software muss natürlich an die neue Auflösung 
angepasst werden. Wenn die S/W reicht geht das relativ einfach. Bei 4 
Graustufen bin ich mir jetzt ohne nachschaun nicht sicher, aber sollte 
auch ohne weiteres machbar sein. 8 Graustufen sind an sich auch kein 
Problem, allerdings musst du dann die Daten im RAM anders anordnen. Das 
sollte prinzipiell ganz gut machbar sein, aber man muss sich halt schon 
etwas tiefer in die Software einarbeiten und muss auch alle low-level 
Schreib-Routinen anpassen.
Grund dafür ist, dass die 512 Pixel bei 3bpp nicht mehr "nebeneinander" 
in den RAM passen. Momentan liegt eine Displayzeile immer so, dass sich 
die höchsten 8 Adressbits innerhalb der Zeile nicht ändern. Das wäre mit 
512 Pixeln in einer Zeile nicht mehr gegeben.

Viele Grüße,
Sebastian

Hallo.

Das klingt gut. Mir würden im Prinzip auch schon 2 Graustufen genügen.
Dann werde ich mal eine Platine Fräsen und etwas ausprobieren. Könnte 
mir jemand mit der Softwareänderung helfen? Meine Kentnisse beschränken 
sich leider nur auf BASCOM. Was die Anpassung für mich etwas kompliziert 
macht. Jedoch habe ich den AVR-GCC Installiert und sollte in der lage 
sein änderungen vorzunehmen...

MfG und Danke

Klar, wenn du Fragen hast dann stell sie einfach. Für den Anfang 
solltest du halt den vorhanden Code zumindest halbwegs verstehen, sonst 
wirds reine Glückssache.
Der wichtigste teil für dich dürfte der Display-interrupt sein. Der ist 
in Assembler geschrieben. Ist aber auch kein größeres problem. Die 
Befehle sind alle in der Hilfe vom Studio erklärt. Darin müsstest du in 
Jeder zeile einige Pixel mehr ausgeben als das jetzt der fall ist und 
dafür nur 128 Zeilen durchlaufen lassen bevor das Bild beendet wird.
In der param.h gibts auch parameter, die die Displaygröße angeben. Die 
solltest du auch ändern, weil sie für einige berechnungen hergenommen 
werden.
Wenn ich mich nicht irre musst du die Schreibroutinen nicht weiter 
anpassen. Für den Gültigen Bereich sollten die auf die Displaygröße aus 
der param.h zurückgreifen. Sicher bin ich mir aber nicht. müsste auch 
erst wieder in den code schaun.


Viel Erfolg bei deinem Vorhaben!
Sebastian

Hallo.
Ich habe gerade angefangen mein Layout an die Gegebenheiten anzupassen, 
da fiel mir auf, dass das Display mehr Anschlüsse hat, als der 
Graphikcontroller...

Ich habe bis jetzt

Contr.-- Display

D3    --- D3
.         .
.         .
D1    --- D1
XSCL  --- XSCL
LP    --- LP
ON/OFF--- YDIS

Übrig ist bis jetzt am Controller : "M_AC" und "FLM_Frame"
Am Display ist noch : "FR" , "YSCL" und "DIN" frei.

Wie ist dies anzuschließen, bzw. der Controller anzupassen?

MfG

Erstmal sorry, dass ich mir so lange Zeit gelassen habe. War viel zu 
tun...

@Denis
Hat sich das Problem mitlerweile gelöst, oder soll ich mir das nochmal 
anschaun? Aus dem Stand weiß ich jetzt auch nicht, was mit den übrigen 
leitungen anzufangen ist.

@Ronny
Prinzipiell sollte das Display gehen. Problem ist aber, dass du kein 
Datenblatt dazu hast. Dir fehlt also die Anschlussbelegung. Auch die 
höhe der Kontrastspannung kannst du so eigentlich nur raten.
Schau dir doch mal das Wintek hier an:
http://www.pollin.de/shop/dt/Mzk0OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LCD_Modul_WINTEK_WD_H3224V.html
Dazu gibts auch ne Anschlussbelegung und in Benedikts anderem 
320*240-GLCD-Thread gibts auch genug erfahrungen mit dem Display sowie 
eine Umbauanleitung auf weiße Hintergrundbeleuchtung.

@Heinz
Wenn sich das Problem noch nicht gelöst hat, dann schieß doch mal ein 
Bild deines Displays. Oft erkennt man daran schon ungefähr, was schief 
läuft. Dann muss ich mich nicht erst durch deine Quellen arbeiten ;)

Viele Grüße,
Sebastian

Aber nur, wenn du mich duzt ;)

Das schaut stark danach aus, dass du den Befehl zum Bild anzeigen nicht 
sendest. Ein kurzer Blick in den Code scheint das zu bestätigen.
Sollte ich die entsprechenden Befehle im Code übersehen haben, dann 
prüfe bitte nochmal, ob du das Kommando wirklich richtig ans LCD 
schickst. Wie's geht weißt du ja, sonst würds ja in ASM nicht laufen.
Wenn es dann immernoch nicht geht hängt das Display vermutlich noch in 
einem anderen Befehl. Dann geht entweder im Displaycontroller beim 
starten was schief, oder du hast vor dem Bild-senden ein Kommando in 
deinem Code, dem du nicht alle Parameter mitgibst. Als work-around hilft 
in beiden Fällen, vor dem Bild-Kommando einige nullen (zehn oder so) zu 
Senden. Das ist aber keine endgültige Lösung!

Viele Grüße,

Sebastian

Ah, jetzt hab ich auch die stelle gefunden, wo du den Befehl sendest.

uart_putc(16 );
uart_putc(0xAA);
uart_putc(0 );
uart_putc(0 );
uart_putc(0 );
uart_putc(30 );
uart_putc(240 );
uart_putc(0 );

da ist eine null zu viel zwischen 0xAA und 30. Richtig gehts so

uart_putc(16 );
uart_putc(0xAA);
uart_putc(0 );
uart_putc(0 );
uart_putc(30 );
uart_putc(240 );
uart_putc(0 );

In deiner version wird die Breite des bildes als 0 interpretiert. => Der 
Bildbefehl beendet sich gleich wieder und die restlichen Bilddaten 
werden als Text interpretiert.

Sebastian

Funktioniert denn normales text schreiben richtig, oder kommt da auch 
schon nur mist an?
Wenn nicht: Läuft der Controller wirklich auf dem vorgesehenen Takt? Ist 
die Taktfrequenz im Code/im Projekt richtig angegeben? Am besten prüfen 
indem man mit warteschleife pins toggelt. Ist die Baudrate richtig 
angeben? Sendet er auch wirklich mit der baudrate? Am besten mit 
Oszi/Logicanalyzer nachmessen.

Ansonsten würd ich die LoadBitmap_P mal hardcoded aufbauen. Also die 
Parameter ignorieren und die Schleifengrenzen fest in den code 
schreiben. Keine Sonderfälle mehr behandeln. Einfach nur stur auf 
speziell dieses eine Bild trimmen. Schließt schonmal wieder ein paar 
mögliche Fehlerquellen aus.

Das schaut erstmal nicht falsch aus. Hab mal etwas in die Datenblätter 
reingeschaut. An sich sollten die Treiber sich mit dem Controller hier 
vertragen und die Verbindungen schaun auch passend aus.
Dispoff ist auf dem panel verdrahtet? Das müsste sonst halt auch noch 
versorgt werden.
GND, VCC sollten ja klar sein. Die Spannung an VEE passt? Was ist V0?

Wenn dein Display aber wirklich nur 160*128 Pixel hat, musst du auf 
jeden Fall die Software umbauen! Ich bin mir jetzt auch nicht sicher, ob 
es reicht, in der param.h die auflösung anzupassen. Glaube du musst auch 
im code selbst (anzeigeinterrupt) änderungen machen.


Viele Grüße,

Sebastian

Dann kann ich, mit den vorhandenen Informationen, leider auch nicht 
helfen.

Wenn du hilfe willst wäre der angepasste Quellcode hilfreich. Außerdem 
eine genauere Beschreibung was genau das Display macht oder nicht macht.
Auch die Haredware könnte duraus noch fehlerhaft sein. Hier gabs schon 
einige, die schon 3 mal alles kontrolliert hatten. Am Ende lags dann 
doch an der Hardware. Zur Sicherheit hier gleich noch der Hinweis: Der 
Schaltplan aus den ersten ein oder zwei Versionen ist fehlerhaft.

Viele Grüße,

Sebastian

Für alle, die diesen (oder mechanisch baugleiche) 
"Standard-billig-inverter" für Ihre Display-CCFL verwenden und auch noch 
keinen passenden Stecker auf Hochspannungsseite gefunden haben:

http://www.conrad.de/ce/de/product/720398/INVERTER-FUeR-KALT-KATHODEN-LAMPE-150-MM/SHOP_AREA_17393&promotionareaSearchDetail=005#

Bei PC Hub gibts 10 stück für 4,39$ versandkostenfrei.

http://www.pchub.com/uph/laptop/841-67833-18868/UPH-Connector-Connector-Wafer-DIP.html

Sind exakt die verbauten Stecker, passen also optimal.
Hab dort schon ein paar mal bestellt, lief immer problemlos. Allerdings 
dauerts grob einen Monat bis die Teile hier sind.

Gruß,
Sebastian

Hallo.

Nein, mein Problem hat sich noch nicht gelöst. Ich habe auch die letzte 
Woche keine Zeit zum recherchieren gehabt, meine Arbeit hat mich doch 
sehr gefordert...
ich bin am Überlegen, ob ich XSCL und YSCL miteinander verbinden 
soll/kann.
Für Hilfe mit diesem Display wäre ich froh.

MfG Denis

Hallo Denis,

sorry, dass ich zur Zeit immer so lange brauche. Ist halt grad 
Prüfungszeit....

Hab mir das Datenblatt deines Displays grade etwas genauer angeschaut 
und gemerkt, dass das Ding als 1024*64 organisiert ist. Ist erstmal kein 
problem, aber die Software muss man entsprechend anpassen. Das werden 
schon tiefere Eingriffe...


Zu den Verbindungen:

FR (Display) muss an M/AC (Controller)

XECL (Display) müsste man noch extra erzeugen. Das muss alle 64 Pixel 
einmal kurz high geschaltet werden. Sollte ganz gut in Software machbar 
sein, aber muss man halt machen.
DIN (Display) müsste an FLM_Frame (Controller) gehören.
YSCL kann man eventuell mit an LP hängen, aber sicher bin ich mir da 
nicht.

Unterm Strich scheint mir das display deutlich nerviger zu sein, als ich 
erst dachte ;)

Sebastian

Hallo,

ich beobachte diesen Thread schon seit langem, und genauso lange wollte 
ich diesen bzw. einen seiner "Geschwister-Controller" hier im Forum 
nachbauen.

Da ich wohl nicht dazu kommen werde verkauf ich nun meine LC-Displays 
mit Touchpanel. Vielleicht kann sie ja jemand von euch ehernvoll in 
Betrieb nehmen.

Hab sie im Markt eingestellt 
(Beitrag "Verschenke/Verkaufe Touch LC-Displays, Textoolsockel, div. USB und Audio IC´s").

Philipp


@Moderator: ich hoffe diese "Werbung" ist erlaubt, sonst bitte löschen.

Hi,

hat noch jemand eine Platine zu diesem Projekt liegen?

Gruß
Malte

>Malte Pöggel (maltep87)

Du hast Post.

Wigbert

Hallo Wigbert,

ich hätte auch noch Interesse an zwei Platine.
Gibt es noch welche?

Gruß
Jens

@Jens H. (devil65)

Du hast Post.

Wigbert

Hallo zusammen,

gibts eine Zusammenfassung vom Projekt? ist doch sehr unübersichtlich.

Eine Wiki Seite konnte ich nicht finden. Oder sind die Sourcen aus dem 
Eröffnungspost gar noch aktuell?

Gruß

Die Sourcen aus dem eröffnungspost sind definitiv nicht mehr aktuell. 
Das findet man aber schon nach einer Hand voll Beiträge raus. ;)

Die aktuelle Version gibts hier
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"

Die hat dann auch 8 Graustufen und einen leicht korrigierten Schaltplan.
Später im Thread kommen noch ein paar andere Versionen, aber die sind 
als experimentell anzusehen und sind nur in ausnahmen empfehlenswert.

Eine Zusammenfassung gibts leider nicht. Jedenfalls kenne ich keine.

Sebastian

Ich finde es eigentlich auch schade, das ein gewisser
Überblick fehlt. Die Grafikkarten werden nach wie vor
gerne genommen. Auch hätte ich einige Adapterboarde
schon in der Schublade.

Leider fehlt mir im Moment die Zeit, eine aktuelle
Zusammenfassung zu erstellen.

Wigbert

Ja, mir gehts da ähnlich. Keine Zeit. Ein Wiki-Artikel wäre echt schön. 
Zumindest gibts ja das pdf-file in den zip-ordnern. Das fasst ja das 
wichtigste schon zusammen.
Habe in der letzten Version von Benedikt ja auch noch einige Änderungen 
vorgenommen, die ich ja auch schon veröffentlicht habe. Aber das ist 
halt so inkonsequent, dass mans nicht empfehlen kann. Das wollte ich 
eigentlich auch noch alles vernünftig implementieren. Aber halt wie 
immer zu wenig zeit.

Mal schaun, vielleicht schaffen wir ja mit vereinten kräften zumindest 
einen wiki-artikel ;)

Sebastian

Ich hab jetzt mal im Wiki einen Artikel zu dem Controller angefangen. 
Aktuell besteht er nur aus einer Kurzbeschreibung sowie einer 
Linksammlung zu den verschiedenen Versionen mit Changelog. Zu einer 
ausführlichen Beschreibung hatte ich bisher noch keine Lust. Vielleicht 
findet sich ja dafür auch noch jemand ;)

Was vielleicht auch noch sinn macht: Alle bekannten Pinbelegungen 
(Display <-> Controller) dokumentieren.

Fürs erste gibts hier mal den Link zum Artikel

http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen


Vielleicht könnte ja ein Mod den Artikel im ersten Beitrag hier im 
Thread verlinken? Benedikt ist hier leider nicht mehr aktiv (hab ihn 
jedenfalls lang nicht mehr gesehen), kann das also nicht selbst machen.

Sebastian

Vielen Dank!

werde natürlich auch meinen betrag dazu leisten wenn ich die Geschichte 
mal aufbaue. Das kann natürlich auch noch ein wenig dauern. Aber ein 
Anfang ist ja schonmal da :-) Da kann man auf jeden Fall mit arbeiten!

Gruß

@Sebastian ... (zahlenfreak)

kann ich jetzt Hardware ohne weiteres was zufügen?

Wigbert

Du meinst in dem Wiki-artikel? Na klar! Ich kenne mich ohnehin besser 
mit dem Softwareteil aus. Werde also auch im Artikel vor allem was zur 
Software schreiben. Aber auch alle, die was zur Software zu sagen haben 
sind immer gerne gesehen. Ich wollte mit der aktuellen Form nur mal 
einen Anfang schaffen.

Sebastian

kannst Du im Inhaltsverzeichnis ein "Hardware" Punkt setzen,
den ich dann bearbeiten kann.
Ich komme da irgendwie nicht ran.

Wigbert

Achso! Hab ich gemacht.

Neue Inhaltspunkte kannst du setzen, indem du, wenn der Artikel offen 
ist, links im Bereich "Dieser Artikel" auf "Bearbeiten" gehst. Dann hast 
du den ganzen Artikel im Editor und kannst auch neue Überschriften 
erstellen.

Sebastian

Achja,

Danke!

Noch eine Frage: Wir gehen teilweise mit fremden Eigentum um.
Ich denke, ich sollte Benedikt informieren, was wir vor haben.
Wenn er nicht schon mitliest.

Wigbert

Ja, über das Thema hab ich auch schon nachgedacht. Wäre wohl sinnvoll, 
Benedikt zumindest noch als Urheber auf der Wiki-Seite zu nennen.
Ich denke aber, solange der Artikel nur eine Zusammenfassung des 
Threads/Linksammlung auf Beiträge darstellt ist das (rechtlich) 
unkritisch. Der Artikel darf halt nicht so ausschaun, als hätten wir den 
Controller entwickelt.

Wenn du Kontakt zu ihm hast wäre es sicher nicht verkehrt, ihn darauf 
aufmerksam zu machen. Ich hab leider seit 2 Jahren nichts mehr von ihm 
gelesen.

Sebastian

So

ich hab auch etwas dazugetan.

Benedikt wird sicherheitshalber benachrichtigt.

Kann man den Link nicht sichtbar oben anhängen?

Oder wir machen jedesmal ein Anhang bei unserer
Unterschrift

Wigbert
http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen

Ich habe die Schaltung nachgebaut, beim Display aber ein Problem: es 
sind Streifen drauf! (siehe Anhang)

Display ist das Wintek WD-H3224V, als SRAM ist nen Cypress CY7C199D 
verbaut.

Durchgemessen hab ich schon alles, konnte aber noch nichts finden, was 
den Fehler begründen könnte. Verbindungen kommen alle am Display an.

Hat wer ne Idee, woran das liegen könnte und wie man das Problem lösen 
könnte?

Die Ansteuerung scheint soweit eigentlich zu passen, sonst wäre das 
eigentliche Bild nicht so ungestört. Nur beim M/AC signal könnte ich mir 
vorstellen, dass was schief läuft. Hoffe du hast den Schaltplan nicht 
aus dem Eröffnungspost genommen, da ist nämlich genau in der Ecke ein 
Fehler drin.

Ändern sich die schlieren, wenn sich der Bildinhalt ändert?


@Wigbert
Den link zum Artikel in jedem Beitrag mitzuposten ist sicher nicht 
schlecht. Auf Dauer wärs aber geschickter, wenn ein Moderator oder 
Benedikt selbst den Link im Eröffnungspost reineditiert.

Sebastian
http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen

Sebastian ... schrieb:
> Die Ansteuerung scheint soweit eigentlich zu passen, sonst wäre das
> eigentliche Bild nicht so ungestört. Nur beim M/AC signal könnte ich mir
> vorstellen, dass was schief läuft. Hoffe du hast den Schaltplan nicht
> aus dem Eröffnungspost genommen, da ist nämlich genau in der Ecke ein
> Fehler drin.

Dochdoch, genau den hab ich verwendet. Sehe ich das richtig, dass der 
Fehler cder ist, dass der eine FF statt auf LP Load auf FLM Frame liegt?



> Ändern sich die schlieren, wenn sich der Bildinhalt ändert?

Hab ich noch nicht getestet, erst mal wollte ich die Schaltung zum 
laufen bringen, bevor ich anfange, da was drauf zu schreiben.

Ich hab da jetzt mal die Verbindung LP Load an den CLK vom FF getrennt 
und den CLK stattdessen auf FLM Frame gelegt. Schon läufts.

Es sind drei Fehler:

M/AC und FLM/FRAME sind falsch benannt (heißen in der falschen Version 
FLM/AC und M/FRAME), könnte also sein, dass du die falsch angeschlossen 
hast.

Der 74HC157 muss an den Ausgang Q des einen 74HC74 Gatters, nicht an 
Q_nicht, wie im ersten plan gezeichnet.

Außerdem wird das andere Gatter des 74HC74 nicht von LP/Load gespeist 
sondern von FLM/FRAME.

Wenn ich mir das so anschau, kannst du eigentlich nicht nach dem ersten 
Schaltplan gebaut haben, sonst wäre noch mehr verkehrt. Entweder hast du 
also doch einen neueren Plan genommen, oder beim nachbaun einen "fehler" 
gemacht.

Prüf die ecke auf Jeden Fall nochmal durch. Denke dass der Fehler da 
irgendwo liegt.


Die Frage, ob die Fehler sich mit dem Bildinhalt ändern hab ich gestellt 
weil, wenns sich ändert, ists wahrscheinlich deine Hardware. Wenns sich 
nicht ändert ist ehr das Display hinüber.

Sebastian
http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen

Sebastian ... schrieb:
> M/AC und FLM/FRAME sind falsch benannt (heißen in der falschen Version
> FLM/AC und M/FRAME), könnte also sein, dass du die falsch angeschlossen
> hast.

In unserem Schaltplan heißen die wirklich FLM AC und M FRAME - da das 
Datenblatt des Displays die Pins aber nur als FLM und M angibt, wird das 
wohl keinen Einfluss gehabt haben.


> Der 74HC157 muss an den Ausgang Q des einen 74HC74 Gatters, nicht an
> Q_nicht, wie im ersten plan gezeichnet.

Faszinierenderweise ist bei uns im Schaltplan der $A$/B-Pin auch an Q 
und nicht an Qnicht angeschlossen. Also schon richtig angeschlossen.


> Außerdem wird das andere Gatter des 74HC74 nicht von LP/Load gespeist
> sondern von FLM/FRAME.

Genau das war der Fehler. Nach dem Auftrennen der Leiterbahn auf der LP 
und einbringen eines Drahtes auf FLM ist das Display streifenfrei.


> Wenn ich mir das so anschau, kannst du eigentlich nicht nach dem ersten
> Schaltplan gebaut haben, sonst wäre noch mehr verkehrt. Entweder hast du
> also doch einen neueren Plan genommen, oder beim nachbaun einen "fehler"
> gemacht.

Welchen Plan ich da genau genommen haben, kann ich da jetzt auch nimmer 
sagen. Aber wird wahrscheinlich wirklich der erste gewesen sein und ich 
habe aus versehen den einen FF "falsch" - und somit richtig - 
angeschlossen.


> Prüf die ecke auf Jeden Fall nochmal durch. Denke dass der Fehler da
> irgendwo liegt.

Jetzt läufts ja zum Glück. Auch wenn die Graustufen nicht ganz so 
intensiv rüberkommen, ists immerhin nutzbar.

Nur die Kontrastregelung ist unter den Tisch gefallen - ich brauche für 
das Display nämlich +24V und hab entsprechend einen einfachen 
Stepup-Wandler eingebracht, der arbeitet wunderbar, so lange ich über 
nen Poti einen Teil der Kontrastspannung auf den CINV-Pin führe, aber 
wenn ich wie im Schaltplan beschrieben das PWM-Signal mit reinmixe, geht 
das ding auf 5V runter. aber das ist ja denk ich mal nicht so wichtig.

Wie werden die Zeichen denn dargestellt? Am Besten ein Foto + 
Beschreibung, was du erwarten würdest.

Viele Grüße,

Sebastian

Ehrlich gesagt hab ich immernoch nicht genau in deinen Code geschaut 
(einfach keine Zeit...), aber kanns sein, dass du den Code, der den Text 
zeichnet, nicht angepasst hast? Das müssten eigentlich größere 
Code-änderungen sein. Jedenfalls, wenn man Text mit einer Breite 
ungleich 8 pixel anzeigen will. Würde jedenfalls zu deinem Fehlerbild 
passen.

Sebastian

Hi,

bin ebenfalls daran diesen Controller nachzubauen. Leider bekomme ich 
noch nicht einmal ein Bild aufs Display. Nutze die LP von Wigbert und 
ein GLCD Wintek wd-h3224.
Nun bin ich mir nicht sicher, ob meine Fuse vom ATmega stimmen (siehe 
Anhang mit PonyProg). Weiter bin ich mir nicht sicher, ob das Datenblatt 
von pollin zu dem Display stimmt.

Könnte mir jemand dabei mal helfen....

Danke & Gruß MAT

@MAT

die Fuses schauen eigentlich gut aus. Hast du das Display richtig 
angeschlossen? Keine Kurzschlüsse am Displayanschluss? Liegen alle 
Spannungen richtig an? Kontrastspannung?


@Julian

Soweit ich das gesehen habe, hast du wirklich nichts am Code geändert. 
So kann das nicht funktionieren. Ehrlich gesagt wurnderts mich gerade, 
dass es überhaupt mit anderen Fonts läuft.
Das Problem ist, dass der Code ziemlich auf 8 Pixel breite Buchstaben 
ausgelegt ist. Da sind tiefgreifendere Änderungen nötig, wenn du einen 
breiteren Font verwenden willst. Am einfachsten wäre wohl noch ein 16 
Pixel breiter, aber auch hier sind definitiv Anpassungen am Code nötig.
Das ist alles machbar und von der Rechenleistung her kein Problem (auch 
andere Größen als 16Px), aber man muss eben den Code (lcd_writechar in 
der lcdcon.S) entsprechend ändern.

Viele Grüße,
Sebastian

Hallo an alle.

Ich habe eben in einem anderen thread beim stöbern ein FARB LCD

http://www.reichelt.de/LCD-Module-Touch-Grafik/TFT-DIS-3-5/3//index.html?ACTION=3&GROUPID=3011&ARTICLE=101746&SHOW=1&START=0&OFFSET=500&;

gefunden.

Kann man das mit einem ähnlichen Controller wie diesem hier realisieren?

MfG