Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus

Bei mir gehts langsam weiter.

Die Routinen zur Bildschirmverwaltung sind doch aufwendiger als ich 
dachte.
Benediktfs Funktionen sind jetzt alle gekapselt, Koordinatensystem nach 
unten links verlegt worden. Endloser Textscroll nach oben durch funzt 
auch schon.

Benutze derzeit 2 x 800 Zeichen Puffer (Heimspiel Arm7: 54kb Ram 
intern), die verglichen werden, es werden nur die Zeichen übertragen die 
sich auch verändert haben. Leider ist da kein Mixed Mode Text/Grafik 
mehr möglich und die sprintf Befehle sind nicht mehr so einfach wie 
printf, wo alles hintereinander geschrieben wird. Man muss vorher wissen 
welche Position angefahren werden soll. Wenn ich wüsste, wie ich den 
String Terminator 0 bei sprintf abschalten könnte wäre es einfacher, den 
muss ich später filtern. Dafür aber minimalster Datenverkehr zum 
Display.

Meinem Rechenknecht zufolge haben wir morgen den längsten Tag des 
Jahres, fast keine Veränderungen mehr die letzten Tage.

Frage mich nur, wie man die 512kb Flash vollkriegen soll, sind nicht mal 
12kb und schon 6000 Zeilen, Flieskomma, sin, cos, tan, alles mit 
eingelinkt. ARM rulez :-)

Gewöhnungsbedürftig:

1

sprintf(GD_CharBuf[6],"Sonnen AG  : %02u.%02u Uhr",Sonne_AUF_UNTER.SAG_Std,Sonne_AUF_UNTER.SAG_Min);

2

3

sprintf(GD_CharBuf[14],"SU  -2    -1    (0)   +1    +2    +2");

4

    line = 0;

5

    for (i=-2;i<4;i++) {

6

    CalcSonnenAufgang(&Zeit, &Sonne_AUF_UNTER,(int32_t)tage+i);

7

    sprintf(&GD_CharBuf[15][line+3],"%02u.%02u",Sonne_AUF_UNTER.SUG_Std,Sonne_AUF_UNTER.SUG_Min);

8

        line += 6;

9

    }

Hallo Benedigt,

ich bin über einen Modellbauportal auf diesen Displaycontroller mit Mega 
8 oder Mega 168 gestoßen. 40x20 Zeichen wäre ideal um Parameter vom 
Mikrocopter / Quadrokopter auslesen zu können ohne einen Notebook 
mitschleppen zu müssen.
Gibt es eine Variante wo man mit 4 Dipschaltern verschiedene Baudraten 
einstellen kann, so von 2400 bis 57600, (bei 1,8,2,N)  als fertiges 
Hexfile. Wäre sehr hilfrein und universeller verwendbar

Hardware würde ich schon hinbekommen, Software reichts gerade mal zum 
flashen und ein bisserl Basic

mfg
helle

Bisher existiert dieses Feature noch nicht, aber ich kann es bei 
Gelegenheit mal einbauen.

Hallo Benedigt,

ich habe heute Abend angefangen dein Schaltung nachzubauen
dabei sind ein paar Fragen/Unklarkeiten aufgetaucht bezüglich der 
Belegung des LCD-Display NAN YA von Pollin

Ich hab mal lt Datenblatt die Anschlüße rausgsucht, unklar ist:
Mega8 Pin 18,  Funktion M  AC  dazu gibts am LCD keine Funktion ? was 
tun?

Atmega  LCD    Pin
23      D0     7
24      D1     8
25      D2     9
26      D3     10

14      PCLK   3
16      LP     2
17      FLM    1
18      M  AC  ???diesen Anschluß gibts nicht am LCD!,Funktion???
19      OnOFF  11


Versorgung
     5V  VDD   4
     GND VSS   5
        VLCD   6   -24V

lt Plan:
        R6     1 Ohm ??kann das sein  1 Ohm??

12V Inverter von Conrad ist ok, geht bis 5V runter, werde mit 7-8V 
fahren

Könntest Du  bitte die offenen Punkte kurz abklären
Ansosnten habe ich das Dink fertig verdrahtet und möchte es morgen Abend 
testen.

Danke für deine Hilfe

mfg
helle

Helmut Renz schrieb:

> Ich hab mal lt Datenblatt die Anschlüße rausgsucht, unklar ist:
> Mega8 Pin 18,  Funktion M  AC  dazu gibts am LCD keine Funktion ? was
> tun?

Offen lassen.
Dieses LCD erzeugt sich dieses Signal intern selbst.

> lt Plan:
>         R6     1 Ohm ??kann das sein  1 Ohm??

Ja, der dient zur Strommessung.

Hallo,

Hoppal das geht aber schnell, dachte nicht dass du online bist.
Ich kam gerade aus dem Keller und hab das Dink zusammengelötet,
Lochraster natürlich, und dachte schreib mal auf was dir aufgefallen 
ist.

Danke für die Mühe!!

Ach Ja ,
kann ich zum Test den Spannungswandler für -22V auch ohne Last betreiben
oder muss ich einen Lastwiderstand ranhängen ?

Am Display-Datenblatt  sind noch 2 Widerstände R1, R2, ein PotiVr und 
ein PNP Transitor angegeben, denke ist für den Kontrast, gibt dazu 
Werte?
BC327 sollte gehen?

Eigentlich hab ich 2 Display bei Pollin bestellt, aber eins ist defekt.
Wurde alles in einer großen Schachtel ohne Polstermateial geliefert,
Glas gebrochen, was auch sonst! Bekomm aber Ersatz
Das andere scheint ok zu sein, drum will ich ja schnell testen falls es 
doch einen Macken hat.

mfg
helle

Helmut Renz schrieb:
> kann ich zum Test den Spannungswandler für -22V auch ohne Last betreiben

Ja.

> Am Display-Datenblatt  sind noch 2 Widerstände R1, R2, ein PotiVr und
> ein PNP Transitor angegeben, denke ist für den Kontrast, gibt dazu
> Werte?
> BC327 sollte gehen?

Dieser Teil ist überflüssig, denn die Einstellung ist per Software, oder 
über R5 möglich, den man teilweise durch ein Poti ersetzen kann (z.B. 
33k Widerstand + 22k Poti).

Hier die neue Version für den mega8:
Die Baudrate ist nun zwischen 1200 und 57600Baud über 3 Pins 
einstellbar.
Die Baudrate wird nur beim Einschalten eingelesen und beim 
Begrüßungsbild angezeigt.
Zusätzlich ist nun auch die Invertierung einzelner Zeilen möglich.

Hallo Benedigt,

Display läuft auf Anhieb, Danke!
Vorab allerdings alles getestet, anderes Kabel angelötet
umverdrahtet auf den Kontrast-Trimmer R5 = 33k + 22kPoti,
Baudrate Dipschalter ergänzt und etwas Umfeld dazu, Spannungsregler, 
LED, Verpolungsschutzdiode (Schutz vor mir selber!)

Tip:
Test des Spannungswandlers ohne gesteckten Prozessor machen,
dabei aber Pin 15 des Atmega 8 -Sockels auf Masse legen , auf keine Fall 
offen lassen, sonst wird der MC34063 sehr heiß und erzeugt -48 bis 
-63V!,
Dann VLC mit dem Kontrast-Trimmer auf ca -16 bis -18V einstellen

Da ich den AQV 257 nicht auftreiben konnte verwende ich einen 
pingleichen LH 1540,  Als fertigen Inverter den von Conrad

Fahre jetzt mit ca 10-12V und ca 300mA
(spätere Versorgung aus 3-Zellen Lipoly Flugakku des Tricopters
mit 3 Draht Verbindung 11,1V Masse und RX )

5V Spannungsregler muß ich nochmal tauschen gegen einen Lowdrop-Typen

Auf dem Bild ist alles zu sehen, kompletter Aufbau ist freiverdrahtet 
auf Lochraster

Jetzt noch alles in ein Gehäuse einbauen und ab damit an den Tricopter
zur Software-Parametrierung auf dem Flugplatz

Das nächte Display werde ich mit einem fertigen 4-Draht DC-DC 
Spannungswandler 5V auf 24V aufbauen

mfg
helle

@ Benedikt

Befehl 9;12 bzw 9;48 schaltet die Schriftarten um.

Nun wollte ich zwei Zeilen Gross, eine Zeile klein (invers)ganz unten
darstellen. Scheint nicht zu gehen?

Wigbert

Bisher ist das Umschalten nur global möglich. Rein theoretisch sollte es 
auch zeilenweise gehen, ich glaube da gab es aber irgendeine 
Schwierigkeit, daher habe ich dies noch nicht gemacht. Das muss ich mir 
bei Gelegenheit nochmal anschauen.

Ist nicht ganz so wichtig,

die Hintergrundbeleuchtung, gibt es da Erfahrungswerte der Lebensdauer,
sonst würde ich die CCFL-Röhre Nachts abschalten.

Das ganze sollte u.a.als DCF-Uhr 24 Stunden am Tag laufen.

Wigbert

Typisch sind rund 20kh. Das Datenblatt sagt mindestens 10kh. Das wären 
etwa 1-2 Jahre. Wenn man die Beleuchtung etwas dimmt, dann sollten aber 
auch 50kh drin sein.

Eine niedrigere Betriebsspannung für den Inverter ist kein Problem, die 
Ausgangsspannung und somit der Strom reduzieren sich dann entsprechend.
Per PWM kann man diese nicht direkt ansteuern, dazu müsste man die 
Schaltung etwas verändern: Es gibt 1-2 Widerstände die Basisstrom für 
die Transistoren im Inverter liefern. Diese müssen dauerhaft versorgt 
werden. In der Zuleitung von der Betriebsspannung zum Trafo im Inverter 
liegt eine Spule. Hier könnte man einen Transistor und eine Diode nach 
Minus davor einbauen. Dadurch hätte man einen Abwärtswandler gebaut.

Hallo zusammen und vielen Dank an Benedikt und das Forum für
dieses tolle Projekt!!!

Ich habe die Mega8-Software "as is" auf ein Pollin-Touch-Display
Best: 120 483  Optrex F-51154NF-FW-AA losgelassen und es hat auf
Anhieb funktioniert!

Da die Auflösung bei meinem Display nicht 320x240 sondern wahrscheinlich
480x200 ist, bleibt rechts ein Teil frei. Unten kommt es auch nicht ganz
korrekt aus, ich habe 16,5 Zeilen an kleinem Text.
Nach V24-Texteingabe bis zum Screen-Wrap sieht es so aus, als wenn unten
3,5 Zeilen fehlen. Aber das macht nix. Es funktioniert!

Optimaler Kontrast stellt sich hier bei etwa -25V ein. Das angehängte
Foto ist ziemlich miserabel. Das Display arbeitet aber völlig 
flimmerfrei
und trotz Freiverdrahtung ohne Pixelfehler.

Ich mach noch ein zusätzliches Post für das Pinout.

Danke,
Stefan

Hier noch das Pinout. Ich habe einfach ein 2x6 Pinhead auf die Test-Pads
aufgelötet. Wenn man das leicht versetzt macht, klappt das ohne zus.
Verrenkungen und den vorhandenen exotischen Connector kann man ausser
Acht lassen.

Noch ein wichtiger Hinweis:
Das vermeintliche M-Signal(TP12) hatte ich vorsichtshalber mit 1k
angeschlossen. Aber am Display ändert sich auch nach Sekunden nichts,
wenn ich M trenne. Von dem Display kommt dann von TP12 ein schwaches
sinusoides Signal mit 200kHz. Also gut möglich, dass das Display
"M" selbst herstellt und TP12 nicht beschaltet werden braucht.

Nochmals Danke,
Stefan

Stefan K. schrieb:

> Das vermeintliche M-Signal(TP12) hatte ich vorsichtshalber mit 1k
> angeschlossen. Aber am Display ändert sich auch nach Sekunden nichts,
> wenn ich M trenne. Von dem Display kommt dann von TP12 ein schwaches
> sinusoides Signal mit 200kHz. Also gut möglich, dass das Display
> "M" selbst herstellt und TP12 nicht beschaltet werden braucht.

Ja, das Display scheint den selbst zu erzeugen. Unterhalb von IC10 gibt 
es einen Jumper bei dem man zwischen AB und B wählen kann. AB ist ein 
intern erzeugtes M Signal, B das externe M Signal.
Das was du als Sinus siehst, ist eine kapazitive Kopplung zu dem daneben 
liegenden Pixel Schiebetakt. Der M Eingang ist also hochohmig. Keine 
Ahnung wieso der auch mit IC10 verbunden ist.
Die ganzen Jumper daneben dienen zur Einstellung des 
Teilerverhältnisses.  IC10 ist also irgendeine eine Form von einem 
einstellbaren Teiler.
Standardmäßig toggelt der Ausgang alle 13 Zeilen. Dazu wird das LP 
Signal in IC10 eingespeist (über die Via neben dem AB/B Jumper).

Wenn ich mich nicht verrechnet habe, dann möchte das Display mit 201 
Zeilen angesteuert werden, da es bei 200 Zeilen zu einem DC Anteil 
kommt.

Für die Grafikversion werde ich demnächst vermutlich meine Software 
anpassen, für die Textversion reicht der Speicher nicht aus.

Danke für die Hinweise. Speziell auf den leicht ungesunden DC-Offset!
Die Grafikversion werde ich demnächst nachbauen. Die LowCost-Lösung war
zunächst erstmal zum Schauen, ob das Display überhaupt irgendwie zum 
Leben
erweckt werden kann. Dazu brauchte ich nur kurz ein paar Kabel stöpseln.

Gruß
Stefan

Hallo,
nachdem ich in dem inzwischen schon sehr umfangreichen Thread dazu nicht 
die passenden Antworten gefunden habe, hier meine ( vielleicht ) blöden 
Fragen:

Wie wird bei der Eingabe eigentlich zwischen Texteingaben und 
Steuerbefehlen unterschieden?

Werden eingegebene Texte mit Erkennung von <CR> und <LF> angezeigt?

Erfolgt nach vollgeschriebener Seite einen Zeilen-Scrolling?

Über eine Antwort würde ich mich freuen.

Klaus

Klaus H. schrieb:

> Wie wird bei der Eingabe eigentlich zwischen Texteingaben und
> Steuerbefehlen unterschieden?

Die nicht darstellbaren Zeichen (also alles kleiner ASCII Code 32) sind 
Befehle, alles darüber Text.

> Werden eingegebene Texte mit Erkennung von <CR> und <LF> angezeigt?

Im Prinzip ja. CR und LF bewirken die entsprechenden Funktionen, also 
eine Zeile runter und wieder an den Beginn der Zeile.

> Erfolgt nach vollgeschriebener Seite einen Zeilen-Scrolling?

Nein. Danach springt der Cursor wieder an den Anfang des Displays.

Hallo Benedikt
und vielen Dank für die schnellen Antworten.

> Die nicht darstellbaren Zeichen (also alles kleiner ASCII Code 32) sind
Befehle, alles darüber Text.

Na ja, darauf hätte ich eigentlich auch selbst kommen können!

>> Erfolgt nach vollgeschriebener Seite einen Zeilen-Scrolling?
> Nein. Danach springt der Cursor wieder an den Anfang des Displays.

.... schade eigentlich, denn das würde mir sehr helfen

Zum "Monitoren" ständig ankommender Textstrings könnte das m.E. sehr 
hilfreich sein. Zur Zeit dürfte es so sein, dass alle bei Beschreibung 
der fast vollen Seite ankommenden Zeichen ggf. ganz schnell wieder 
verschwunden sind.
Ist das Hinzufügen einer solchen Funktion ( ohne größere Klimmzüge 
machen zu müssen ) denkbar?

Gruß
Klaus

Prinzipiell ist es machbar. Dazu muss der gesamte RAM Bereich quasi um 
eine Zeile (=40Byte) versetzt kopiert/verschoben werden. Das ist zwar 
eine Menge Kopierarbeit, aber da dies nur recht selten vorkommt sollte 
es keine großen Probleme machen.

Hallo,
ich habe noch ein Frage zum Thema "Inverter":
Für das Nan Ya-Display LTBE9_159_K von Pollin benötige ich ein 
geeignetes Exemplar. Auf den Seiten dieser Firma findet man aber derzeit 
nur noch einen ( in Verbindung mit einer Neonlampe gelieferten ) 
Invertertyp. Er hat die Best.Nr. 531321 und den Aufdruck: TDK XAD052S 
EA02052X. Leider habe zu diesem Typ im Internet überhaupt nichts 
gefunden. Vielleicht handelt es sich um eine für einen bestimmten 
Anwender hergestellte Ausführung. Auffällig ist dabei übrigens auch 
noch, dass die Anordnung der Bauteile etwas von dem auf der Pollin-Seite 
gezeigten Invertertyp abweicht.
Kann Jemand dazu etwas anmerken?

Klaus

Hallo Klaus,

ich habe mein Display auch mit genau diesem Inverter (Best. 531321)
angetrieben. Die stammen wohl aus einem Flachbett-Scanner.

Ich halte es für völlig unproblematisch, diesen Inverter mit dem
Nan Ya zu betreiben. Bei der letzten Bestellung habe ich mir auch
ein Nan Ya LTBE9T372G1K mitbestellt.
Ein kleiner Test jetzt gerade zeigt, dass es funktioniert ( und dass
ich ein Display mit einer Druckmacke bekommen habe :(  ).

Gruß
Stefan

Hallo Stefan,
vielem Dank für Deine Stellungnahme. Inzwischen habe ich die Inverter 
auch schon erhalten und erfolgreich getestet. Nachdem ich vorher noch 
nie etwas mit solchen Dingern zu tun hatte, war ich hinsichtlich ihrer 
Verwendbarkeit nur anfangs etwas verunsichert.

Gruß
Klaus

Kleiner Einkaufstipp zum Thema Inverter:

http://shop.wiltec.info/product_info.php/info/p2313_Single-Inverter-fuer-1-Roehre.html

habe ich 2 Stück im Einsatz, allerdings an Displays 640 x 200 (ca. 20 cm 
lange Röhre). Sind IMO sehr preiswert, auch der Versand.

Reinhard

Hallo,
inzwischen ist meine Displayeinheit aufgebaut. Nachdem die ( m.e. 
aktuelle )  ATMEGA168-Softwareversion vom 24.2.09 allerdings nicht zum 
Laufen zu bekommen war ( der Bildschirm wurde nur mit Zufallszeichen 
vollgeschrieben, aber es erschien kein Startbildschirm ), verwende ich 
inzwischen erfolgreich die ATMEGA8-Version vom 8.7.09.

Wie aus dem beigefügten Schaltbild zu ersehen ist, habe ich die 
Erzeugung der Vee-Spannung etwas gegenüber dem Original geändert und 
verwende hier einen für wenige Euros bei z.B. Reichelt erhältlichen 
DC/DC-Wandler.

Meine Anwendungen schliessen auch das Anzeigen von GPS-Navigationsdaten 
ein. Ein vorgeschalteter zweiter ATMEGA8 stellt vielleicht 
ingenieurmäßig gesehen nicht unbedingt die eleganteste Lösung dar, war 
aber ( in BASCOM-AVR ) immerhin ganz schnell programmlich umsetzbar.
Was ich noch suche, ist der ASCII-Wert, der falls vorhanden, für das 
Zeichen "°" im Display-Font benutzt wird.

Klaus

Hier der verwendete Zeichensatz. Das ° Zeichen hat den ASCII Code 248.

Hallo Benedikt,
dafür vielen Dank.
Hast Du auch eine Idee zu meinen Problemen mit der 
ATMEGA168-Softwareversion?

Klaus

Erscheinen da die Buchstaben/Zeichen vollständig (wenn auch in sinnloser 
Reihenfolge)?
Reagiert die Software auf die UART Signale?
Da du vermutlich die selbe Hardware für beide Versionen verwendet hast, 
kann man einen Hardwarefehler ausschließen. Da die Software bei Wigbert 
funktioniert einen Softwarefehler wohl auch.
Von daher habe ich eigentlich keine wirkliche Idee an was es liegen 
könnte.

Hi,
ich nehme nur die m168- Version,und die lief manchmal Tagelang.
Was kann man da falsch machen?
Fusebits?

Wigbert

@Benedikt

> Erscheinen da die Buchstaben/Zeichen vollständig (wenn auch in sinnloser
Reihenfolge)?

Ja

> Reagiert die Software auf die UART Signale?

Ja, aber dabei wird der Bildschirm immer nur mit einem bestimmten 
Zeichen ( wenn ich mich nicht täusche war es: 0xE0 ) vollgeschrieben. 
Änderungen der Baudrateneinstellung wirkten sich dabei nicht aus.

> Da du vermutlich die selbe Hardware für beide Versionen verwendet hast,
kann man einen Hardwarefehler ausschließen. Da die Software bei Wigbert
funktioniert einen Softwarefehler wohl auch.
Von daher habe ich eigentlich keine wirkliche Idee an was es liegen
könnte.

Da die Großanzeige für die GPS-Anzeige ohnehin nicht infrage kommt, 
besteht damit zur Zeit bei mir kein akutes Problem, aber dennoch würde 
es interessant sein, den Grund für das Nicht-Funktionieren 
herauszufinden.

@ Wigbert
> ich nehme nur die m168- Version,und die lief manchmal Tagelang.
Was kann man da falsch machen?

Wenn ich das wüsste! Mit anderer Software funzt der gleiche Atmega-Chip 
auch problemlos.

> Fusebits?

Daran hatte ich auch schon gedacht. Bei der ATMEGA8-Version klappt es 
aber bereits, wenn ich allein nur die Fuse für den externen Quarz 
setzte. Im Text schreibt Benedikt zwar noch, daß auch die Fuse "CKOPT" 
gesetzt werden muss, nur taucht dieser Begriff im Eingabemenü der von 
mir benutzen Brennsoftware ( myAVR Prog-Tool ) nicht auf. Ich gehe aber 
davon aus, daß ich diese automatisch mit setze, wenn ich bei mir 
Quarzfrequenzen > 8MHz auswähle.
PS: Ein anderes Exemplar des ATMEGA168 verhielt sich übrigens identisch.

Klaus

>Ein anderes Exemplar des ATMEGA168 verhielt sich übrigens identisch

na, wird der m168 richtig erkannt? Les doch mal den AVR zurück.
Ich kann hier hin und her proggen , finde nichts.
Ckopt ist dort gar nicht.

Wigbert

CKOPT existiert nur bei den älteren AVRs, also bei mega8,16,32 usw. 
sowie 8515 und 8535.
Bei den neueren (megax8 usw.) hat der Full Swing Crystal Oscillator eine 
eigene Kombination bei den CKSEL Fusebits.

Hallo,
das Problem mit dem ATMEGA168 werde ich in den nächsten Tagen noch 
einmal angehen. Inzwischen programmiere ich auch mit "AvrProg" von 
ATMEL. Das Handling der Fuses funzt dort sicherer als bei dem von mir 
vorher benutztem Tool.

Jetzt habe ich aber noch eine andere Frage, die mir vielleicht speziell 
der Wigbert beantworten kann:
Wie kann ich Befehle via BASCOM an den Decoder senden, wenn diese noch 
zusätzliche Parameter enthalten müssen?
Einfache Befehle, wie z.B. "Print chr(12)" klappen wunderbar, aber in 
Falle zusätzlicher X,Y-Parameter suche ich noch das richtige 
Eingabeformat. Mit Formaten wie "Print chr(17), 15,20" , "Print chr(17, 
15,20)" oder Ähnlichem geht es jedenfalls nicht.

Klaus

@Klaus H. (gpsklaus)

sowas in der Art?

Printbin 17 ; 2 ; 2            'Zeile Vorwahl Nr.
Print = Mid(text , 27 , 6)     'Vorwahl Nr.
Printbin 17 ; 1 ; 3            'Zeile Tele.Nr.
Print = Mid(text , 33 , 7)     'Tele.Nr.

(Auszug aus Telefonbuch)


Wigbert

@Wigbert

> sowas in der Art?
> Printbin 17 ; 2 ; 2            'Zeile Vorwahl Nr.
> Print = Mid(text , 27 , 6)     'Vorwahl Nr.

Danke, "PRINTBIN" hat mir sehr weitergeholfen.

Inzwischen habe ich noch gelernt, dass es z.B. auch so gehen würde:
Print chr(17) ; chr(2) ; chr(2)

Klaus

Bei dem "normally white" musst du auch ohne Backlight was sehen. Wenn 
dein Display normalerweise schwarz ist brauchst du unbedingt das 
Hintergrundlicht.

Ansonsten halt nochmal alle Lötstellen prüfen. Vor allem die direkt am 
Display. Oder mal ne etwas geringere Spannung probieren.

Sebastian

Ist das Display im eingeschalteten Zustand komplett dunkel? Falls ja, 
ist die Spannung zu hoch.

> Ich messe -19V das ist doch eher zu wenig als zu viel ??
Naja ich werde das mal mit weniger Spannung testen, wird aber etwas
dauern.

Nach meinen Erkenntnissen ist der Spannungsbereich, in dem das Display 
gut ablesbar ist, schon verhältnismäßig eng. Hast Du die Spannung einmal 
im Bereich von etwa -15 bis -20V variiert? Dabei muss sich auf jeden 
Fall etwas im Kontrast ändern.

Klaus

sry aber ich bin anfänger in beeriech mc`s...
könnte mir villeicht jemand den schaltplan genauer erklären und eine 
bauteiliste anfertigen???
wie steuert man den controller an wenn er fertig ist???
würde gern mit mega8 arbeiten
danke NONEVER

Schau dir doch mal das AVR-Tutorial an und arbeite es am besten auch 
mit Material durch. Dann dürften sich die meisten Fragen erledigt haben. 
Wenn es dann noch konkrete Probleme gibt helfen wir auch gerne an dieser 
stelle weiter.

Gruß, Sebastian

die grundlagen kenne ich ich...
also Standartbeschaltung eines avr 8 bit microcontrollers usw..
tut mir leid , dass ich gestern einen so kurzen und abgehackten Post 
gemacht habe war aber sehr in eile..
was ich nicht verstehe ist der untere Teil des Schaltplans mit den 2. 
Ic...
ich denke mal das dieser für die Kontrastspannung ca. 23 volt sein wird 
oder?
Meine 2. Wirkliche FRage ist wie dieser displaycontroller nun 
angesteuert wird, wenn er fertig ist??
so wie es aussieht warscheinlich über die serielle Schnittstelle das 
heißt den txd ausgang vom DIsplay Controller an txd vom mega8 zum 
ansteuern oder?
und dann mit dem Print befehl. wäre nett wenn mir jemand nochmal sagen 
könnte warum im schaltplan deutlich mehr bauteile zu sehen sind als auf 
der Platine im 2 post
gru? NoNever

Der MC34063 ist -wie du vermutest- für die Kontrastspannung. Warum der 
schaltplan so voll und die Platine so lehr ausschaut weiß ich auch 
nicht, aber ich nehme mal an, Benedikt hat SMDs auf der Rückseite 
verwendet.

Angesteuert wird über UART, du schließt also TxD von deinem µC an RxD 
vom Displaycontroller an.

Hallo Benedikt und alle anderen,

ich habe grad dein Projekt nachgebaut.
Leider kann ich nur die letzten 32 Zeichen des Zeichensatzes(siehe ein 
paar Beiträge weiter oben) ausgeben.
Woran könnte das liegen?
Habe schon andere Baudraten ausprobiert, leider ohne Erfolg!
Das Startbild wird richtig dargestellt und die Baudrate wird auch laut 
Jumper richtig erkannt.
Auch die Befehle(wie z.B. LCD löschen) funktionieren nicht.
Wenn ich dem ATMEGA in der Schleife alle 256 ASCII-Zeichen schicke dann 
werden nur die letzten 32 Zeichen des Zeichensatzes dargestellt.
Bitte um Hilfe!

Grüße, Nico

Hallo zusammen,
habe ein ähnliches Problem. NAN YA LTBE9T372G1K (noch ohne 
Hintergrundbeleuchtung).

Display wird nach dem Einschalten komplett hell. Text nicht zu sehen.

Frage: Ist es normal, daß die 20V nur im Leerlauf (ohne Display ) 
vorhanden sind ? D.h. Wenn ich das Display anstecke, brechen die 20V bei 
meiner Schaltung auf 10,5V zusammen.
Stromaufnahme auf Leitung VLCD 30mA.

Mein Display ist normal Dunkel. Nach dem Einschalten wird es komplett 
hell. Manchmal sind streifen zu sehen. Bedeutet das, ich muss die 
Hintergrundbeleuchtung trotzdem verwenden ?
Das erscheint mir fraglich, da ich sehe wie das Display zwischen Schwarz 
und weiss umschaltet und Pixel sichtbar sind. Hat mir Pollin evtl das 
"normal hell" Display geschickt ?

Danke für Eure Hilfe. Dies ist wirklich ein Super Projekt

Matthias

Nico R. schrieb:

> Leider kann ich nur die letzten 32 Zeichen des Zeichensatzes(siehe ein
> paar Beiträge weiter oben) ausgeben.

Passen die Zeichen auch exakt zu dem Wert der gesendet wird?
Ich würde auf einen falschen Quarz oder falsche Fusebits tippen.

Matthias Reichelt schrieb:
> Frage: Ist es normal, daß die 20V nur im Leerlauf (ohne Display )
> vorhanden sind ? D.h. Wenn ich das Display anstecke, brechen die 20V bei
> meiner Schaltung auf 10,5V zusammen.
> Stromaufnahme auf Leitung VLCD 30mA.

Nein, da passt etwas nicht. Ich würde auf vertauschte Pins oder 
ähnliches tippen.

> Mein Display ist normal Dunkel. Nach dem Einschalten wird es komplett
> hell. Manchmal sind streifen zu sehen. Bedeutet das, ich muss die
> Hintergrundbeleuchtung trotzdem verwenden ?

Ja. Das Verhalten ist nämlich nicht normal.

> Hat mir Pollin evtl das "normal hell" Display geschickt ?

So sieht das normally black aus, das braucht immer ein Backlight:
Beitrag "Re: Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus"

Das normally white dagegen ist auch ohne lesbar:
Beitrag "Re: Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus"

Danke für die schnelle Antwort.

Leider kein Erfolg. Vertikale Streifen sind zu sehen ( schwach ) aber 
die Spannung bricht noch immer ein. Ich sehe nicht ein warum da 30mA auf 
VLCD fließen sollen. Wahrscheinlich Display Defekt.

Alles durchgemessen.
Angeschlossen habe ich nach einem vorherigen Betrag:


Atmega  LCD    Pin
23      D0     7
24      D1     8
25      D2     9
26      D3     10

14      PCLK   3
16      LP     2
17      FLM    1
18      M  AC  ???diesen Anschluß gibts nicht am LCD!,Funktion???
19      OnOFF  11


Versorgung
     5V  VDD   4
     GND VSS   5
        VLCD   6   -24V

Trotzdem Danke.
Bestelle ein neues "normally white" display. Dann brauche ich auch nicht 
die hochspannung.

Grüße aus Wien
Matthias

-24V ist etwas viel. Das Datenblatt sagt absolut max. -27V gegen Vcc 
(also +5V) gemessen. Du bist bei -29V.
Typisch sind etwa -18V.

Randy schrieb:

> Bei dem steht explizit dabei dass es reflexiv ist. Weiß jemand was es
> für ein Anschlusskabel hat?

Folienkabel mit sehr engem pitch.

Nett sind die EL-Displays, von denen es vor ein paar Monaten ein paar 
gab. Nicht eben stromsparend, aber dafür mit 16er Pfostenstecker.

Randy schrieb:
> 
http://www.pollin.de/shop/dt/MTg2OTc4OTk-/Bauelemente/Aktiv/Displays/LCD_Modul_SHARP_LM038QB1R10.html
> Bei dem steht explizit dabei dass es reflexiv ist. Weiß jemand was es
> für ein Anschlusskabel hat?

Das ist hier zu sehen:
Beitrag "Re: Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus"
Anschluss auf dem Display ist ein Nullkraftstecker mit 0,5mm Pitch und 
24 Pins. Dieses Display benötigt eine positive und negative 
Betriebsspannung sowie Teilspannung dazwischen. Man benötigt also noch 2 
Doppel OPs + ein paar Widerstände.

> 
http://www.pollin.de/shop/dt/Mzk0OTc4OTk-/Bauelemente/Aktiv/Displays/LCD_Modul_WINTEK_WD_H3224V.html
> Für das Teil braucht man keinen CCFL-Inverter. Allerdings braucht es 32V
> Betriebsspannung. Das Kabel schaut nach so einem fürchterlichen
> unlötbaren Plastik-Falchband aus. Weiß das jemand genauer?

0,5mm Pitch. Die Spannungsangaben würde ich erstmal nicht beachten, da 
es nirgends ein Datenblatt gibt frage ich mich wo Pollin die Zahlen her 
hat.
Ich würde eher auf +25V tippen, da es dem untersten Display in dieser 
Liste sehr ähnlich ist (vermutlich gleiche Zeilen/Spaltentreiber bei 
denen absolut max 30V angegeben ist).

> 
http://www.pollin.de/shop/dt/ODI1OTc4OTk-/Bauelemente/Aktiv/Displays/LCD_Modul_NAN_YA_LTBE9S159J1K.html
> Das Teil ist wahrscheinlich auch reflexiv ablesbar?

Ja, mit Beleuchtung sieht es so aus, ohne wie das Sharp Display:
Beitrag "Re: Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus"

Anschluss über 1mm Folienkabel, kann durch 1,27mm Flachbandkabel ersetzt 
werden.

Und um die Liste komplett zu machen:
http://www.pollin.de/shop/dt/MjU0OTc4OTk-/Bauelemente/Aktiv/Displays/LCD_Modul_LCD_TG322450.html

Dieses Display hat auch ein Folienkabel mit 0,5mm Pitch und 24 Pins.
Optisch ist es mit dem NAN YA vergleichbar. Auch dieses Display benötigt 
wie das Sharp Display einen zusätzlichen OP, der die positive 
Betriebsspannung in mehrere Teilspannungen zerlegt.

Ich habe das Display noch nicht, da Pollin wohl ein paar Lieferprobleme 
damit hatte. Den Fotos auf ebay nach sollte das möglich sein (auf der 
Rückseite ist eine Platine die frei zugänglich ist).
Es gibt auch einen schon etwas älteren Eintrag hier im Forum dazu, in 
dem auch ein Datenblatt angehängt ist, allerdings passt dieses nicht zu 
dem Foto auf der ebay Seite. Von daher existiert bisher also noch keine 
Anschlussbelegung zu dem Display.

Randy schrieb:

> Kannst du sagen ob man an die Lötstellen de Kabels auf der Platine ran
> kommt?

Ich habe das bei solche einem Dings mal probiert. Die Folienbuchse von 
der Platine abgelötet um an die Pads mit Lackdraht ran zu kommen. Läuft 
etwas nach dem "Schnecke an der Mauer" Prinzip, weil man bei jeder 
Zinnbrücke mühsam angelötete Drähte wieder abmachen darf und nicht immer 
klar ist, ob man insgesamt an der Mauer eher hochkommt oder eher 
runterrutscht.

Im Grunde müsste man nach dem Lötprinzip der TQFPs vorgehen. Sich 
irgendwas besorgen oder bauen, dass bereits am einen Ende Drähte in 
0,5mm rausführt und diese nach dem SMD-Muster geschlossen anlöten. 
Einzeln ist das ein ganz übler Fummelkram.

In diesem Fall dürfte es etwas einfacher sein, denn dem Foto nach ist 
das Raster auf dem Display breiter als am anderen Ende des Kabels (ich 
würde auf etwa 0,8mm tippen).

So ich hab die Displays gerade bekommen.

Das Display hat 26Pins nicht nur 25 wie Pollin schreibt und dieses 
Datenblatt
http://www.dataimagelcd.com/product/tg/pdf/TG322450FNCWA-01.pdf sollte 
ansich gut passen.

Auf dem Aufkleber steht bei mir TG322450 FMCWA-10.

EDIT: Gerade mal ein Display aufgehebelt. Hier gibt es keine Möglichkeit 
ein anderes Kabel anzulöten da der Folienleiter intern als Leiterkarte 
dient.

Falls man nur so wie ich 24 Pol 0.5mm FFC Buchsen hat kann man die 
letzten beiden Kontakte abzwicken da das nur 2 von 5 Ground Verbinungen 
wären die dann fehlen.

Heute Abend mal etwas Adapter löten damit ich das an mein S1D13700 
Testboard hängen kann. Ich hoffe ich kann die Referenzspannungen wie für 
das kleine Sharpdisplay das es bei Pollin gibt ohne weiteres nutzen.

MfG Kai

Kai B. schrieb:
> Das Display hat 26Pins nicht nur 25 wie Pollin schreibt und dieses
> Datenblatt
> http://www.dataimagelcd.com/product/tg/pdf/TG322450FNCWA-01.pdf sollte
> ansich gut passen.

Das Datenblatt passt.

> EDIT: Gerade mal ein Display aufgehebelt. Hier gibt es keine Möglichkeit
> ein anderes Kabel anzulöten da der Folienleiter intern als Leiterkarte
> dient.

Könntest du mal ein Foto davon machen?

> Heute Abend mal etwas Adapter löten damit ich das an mein S1D13700
> Testboard hängen kann. Ich hoffe ich kann die Referenzspannungen wie für
> das kleine Sharpdisplay das es bei Pollin gibt ohne weiteres nutzen.

Nicht direkt: Das Display mag keine negativen Spannungen. Dafür ist es 
aber umso einfacher, da man lediglich normale Spannungsteiler benötigt.

Hallo Benedikt,

hab hier grad keine Kamera zur Verfügung. Aber ich werde heut Abend mal 
die Displays abfotografieren.

Ja stimmt das Sharp will noch ein bisschen was negatives. Und die 
Spannungsteilerwerte stehen ja im Datenblatt von dem Display.
Naja heut Abend mal löten.

Hast du auch das H3224V? Von dem würde mich auch mal ein Foto von der 
Rückseite interessieren, da die Bilder im Netz leider nur eine eine 
geringe Auflösung haben. Anders als bei dem G3224Z scheint dort nämlich 
der OP mit Spannungsteiler schon drauf zu sein.

Noch ein Tipp zu der Schaltung: Zwischen den OP und die Kondensatoren 
dahinter 15 Ohm Widerstände schalten, sonst schwingt der OP (das 
Datenblatt unterschlägt die nämlich in der Beispielschaltung).

Ja ich hab mir mal wieder ein ganzes Packet an Displays bestellt 
unteranderem auch das Wintek.

Guter tip das mit den Serienwiderständen an dem OP Ausgängen. Habe aber 
schon häuftig auf diversen Displays die gleiche Schaltung wobei die das 
da bisher nie beachtet haben.

Ich bin bei den Widerständen drauf reingefallen, der OP wurde bei rund 
50mA Stromaufnahme bei 25V auch gut warm...
Auf den meisten Displays sind die 15 Ohm Widerstände vorhanden, nur 
hatte ich da bisher nie drauf geachtet, denn neben den normalen 
Spannungsteiler Widerständen fallen die nicht auf. Keine Ahnung ob es da 
einen Unterschied zwischen dem LM324 und den Japan Versionen gibt, 
einige OPs haben schon Serienwiderstände von wenigen 10 Ohm eingebaut. 
Der LM anscheinend nicht.

Hi,
wer Lust auf Stecker hat, beim TG 322450:
Farnell Nr.165-9861 ; 124-5267
die Spannungsversorgung nach DBL mit angegebenen IC , nur die reihen-R
sind zusätzlich.

Meine WD-H3224 sind auch noch unterwegs. Ist wohl ein weiter Weg
zu mir.

Wigbert

So hier erst einmal ein paar Fotos ich hab auch mal noch die Rückseite 
des Optrex Teil im Anhang hier sieht man auch schön die Widerstände zu 
den Caps für V2-V5.

WIe schon gesagt bei den TG322450 ist der Folienleiter direkt mit den 
Zeilen/Spaltentreiber verbunden.

Und dann noch die Rückseite des WD-H3224V.

MfG Kai

So mal löten gehen

Danke für die Bilder.
Das H3224V hat also wirklich den OP drauf der die Teilspannungen 
erzeugt. D.h. die Datenblätter die existieren passen nicht, aber dafür 
erspart man sich Arbeit bei der Ansteuerung.

So das Wintek geht schonmal.

Die VCC mit +32Volt die Pollin angibt ist wie Benedikt schon gesagt hat 
viel zu hoch. Ich habe bei mir ca. 23 volt benötigt.

Der Kontrast sieht gut aus, nur die Farbe ist nicht wirklich schön (mir 
gefällt sie zumindest nicht).
Wenn die LEDs z.B. durch weiße austauschbar sind, dann wäre das Displays 
perfekt.

Ja die Farbe ich etwas unschön zumal meine Kamera die eher rötlich als 
in echt darstellt. Zudem hab ich dem Backlight nur ca. 100mA spendiert.
Die SideLEDs kann man tauschen ist nur die frage wie man da richtig 
hinkommen soll ohne zumindest den Zeilentreiber und das Touch abzulöten. 
Die Leiterplatte ist zwar angeklipst nur wirklich rausbekommen tut mans 
dennoch nicht.

@Kai B.

Wie hast du die LED Beleuchtung gemacht / montiert? Wäre ja eine 
alternative zum Backlight. ggf mit Foto wie LEDs Montiert sind.

Das H3224V Display hat standardmäßig ein LED Backlight.

So ich habe es mal gewagt und bei einem Display den Zeilentreiber und 
das Touchpanel abgelötet. Nur so kommt man an die LEDs ran.
Es sind 22 LEDs (3 Gruppen) und jede LED hat ihren eigenen Vorwiderstand 
(die 2x 11 36Ohm beim Wintek Logo) Morgen tausch ich die mal testweise 
mit weißen Sideleds idealerweise sollte es sowas sein wie OSRAM LW V18G 
ich werde es mal mit LW Y1SG probieren.

Das sieht doch schonmal gut aus mit den LEDs. Da bleibt also viel 
Potential zum Basteln.
Der Preis von den weißen LEDs war auch das erste über das ich gestolpert 
bin. Noname LEDs bekommt man für rund 1/3 von den OSRAM LEDs von 
Reichelt, allerdings ist dann da wieder die Frage nach der Lebensdauer.

Ich denke ich werde erstmal grüne LEDs in 0603 oder 0805 einbauen. Die 
sollten eigentlich auch rein passen. Abgesehen von den Lötpads die bei 
den Sideleds auch an der Seite hoch gehen, sehe ich da nämlich keinen 
Unterschied. Häufig sind die LEDs auch nur anders liegend verpackt damit 
das automatische Bestücken einfacher geht.

Die weissen LED's wären mir das Display schon wert. Gibt es die
nicht irgendwo mit Mengenrabatt.

Wigbert

Wir kaufen die für 25-27Cent/100  ein zumindest die LW Y1SG ab ca. 2000 
Stück. Bei RS sind die etwas teurer.

@Kai B.
Dank Dir , 2000 Stück würden es wohl nicht werden.
Na ja , mal sehen was wird.

Wigbert

Kai B. schrieb:
> Morgen tausch ich die mal testweise mit weißen Sideleds

Gibt es schon erste Erfolge?

Ja lötfrisch sozusagen xD

Zum einen nochmal 2 Bilder vom großen Optrex das lässt sich echt klasse 
auch mit invertiertem Bildinhalt nutzen.

Ein Bild mit getauschten LEDs leider nur ein Paar LEDs da ich die von 
ner defekten Platine löten musste und nicht mehr hatte. Und an den 36Ohm 
Vorwiderständen hab ich so gelassen. Mit weissem Backlight lässt es sich 
besser ablesen. Muss mir mal die oben erwähnten LW V18G bestellen.

Und das TG322450 läuft auch nur der Kontrast funktioniert noch nicht 
ganz sauber je mehr Pixel umso mehr Grau wir die Spalte. Kann aber auch 
am nicht ganz optimalen aufbai der V0 bis V4 liegen. Die V0 sind 
gleichzeitig die Versorgung vom OP im Datenblatt hats ja noch den extra 
Transistor. Das lässt sich ohne BL allerdings etwas schlecht ablesen 
finde ich. Kann aber auch an der Dämmerbeleuchtung hier liegen xD.

MfG Kai

Das H3224V mit weißen LEDs sieht nicht schlecht aus. An das TG322450 
kommt es nicht ganz ran, aber die 5-10€ für die LEDs scheinen sich zu 
lohnen wenn ich das Bild so sehe, denn die weißen LEDs dürften momentan 
mit deutlich weniger Strom laufen als die orangefarbenen.

@dejan278
Danke für den Tipp mit den LEDs. Ich habe mir auch eine Packung 
bestellt, und ich denke es hat sich gelohnt wenn ich die Displays 
vergleiche:
- original, 2,6V 300mA
- grün, LG L29K, 3,3V 500mA
- weiß, LW V18C, 3,3V 120mA

PS: Es scheint auch wieder Displays mit defektem Touchscreen zu geben, 
ich habe welche erwischt bei denen ein X-Anschschluss hochohmig ist. 
Funktionsfähig sollten es in X Richtung etwa 400-600 Ohm und in Y 
Richtung etwa 200-300 Ohm sein.

Ich glaub ich werd mir wohl auch bei Ebay die LEDs kaufen und meine 
Displays umbauen.
Das weiß sieht dann schhon gut aus. Das sorgt schon für einen doch 
besseren Kontrast im vergleich zum Original.
Sieht das Grün wirklich so dunkel aus?

MfG Kai

>Ich glaub ich werd mir wohl auch bei Ebay die LEDs kaufen und meine
>Displays umbauen

ich hab das schon getan. Ein Bild sagt mehr als tausend Worte.

@Benedikt K. (benedikt) (Moderator)
Ich wollte an das umlöten nicht ran, aber Weiß ist doch besser.
Schön, das Du uns Deine Varianten zeist.

Wigbert

Kai B. schrieb:

> Sieht das Grün wirklich so dunkel aus?

Etwas heller ist es schon.
Ich hatte aber absichtlich die Einstellungen beim Foto fest eingestellt 
und gleich gelassen, um den Unterschied zu weiß zu zeigen.

Das originale orange ist meiner Meinung nach unbrauchbar. Da muss man 
den Strom bis an die Grenze hochdrehen um überhaupt was erkennen zu 
können.
Grün ist da schon besser, es ist das typische gelb-grün, das man von 
normalen LCDs kennt (auf dem Foto geht das zu stark in Richtung 
dunkelgrün).
Es ist ausreichend hell, damit man das Display ablesen kann.
Aber im Vergleich zu den weißen LEDs ist auch grün Mist.
Ich werde daher alle Displays auf weiß umlöten. Das Geld ist es 
eindeutig wert. Vor allem, da man hier mit sehr viel weniger Strom 
auskommt.

Tip, bei den Fotos ein Teelicht neben dass Display.
Dann hat man einen Referenzpunkt ;)

Gruß Anselm

Ja. Beides sind normale 320x240 Display mit 4bit.
Man muss nur beachten, dass diese eine positive Kontrastspannung von 
etwa +23V benötigen anstelle der negativen.

Hallo zusammen.

Ich habe hier 2 Sharp-LM3201921 liegen. Die müssten mit dieser Schaltung 
ja auch gut gehen. Pinbelegung ist lt. Datenblatt klar. Nur ich bin 
etwas confused. VEE wird mit +16 bis +22V angegeben, doch eigentlich ist 
meist von einer negativen Spannung die Rede... Vielleicht kann jmd. hier 
etwas Licht ins Dunkel bringen oder mich von dem Schlauch auf dem ich 
stehe schubsen - ich wär euch dankbar :D

Danke schon mal und Grüße,
 Wolfgang


Pinbelegung Sharp LM3201921 (LM32019T, LM32019P, LM32019P0)

1  :S
2  :CP1
3  :CP2
4  :NC
5  :DISP OFF
6-9:D0 bis D3
10 :VDD (+5V)
11 :VSS-GND
12 :VEE (1921: 16-22V | 19T,19P,19P0: 17-26V)

Benedikt K. schrieb:
> Ja. Beides sind normale 320x240 Display mit 4bit.
> Man muss nur beachten, dass diese eine positive Kontrastspannung von
> etwa +23V benötigen anstelle der negativen.
Erzeugst du die dir per Stepup oder führst du die Extern zu?
Welche LEDs hast du den benutzt? Gibt es da bei Pollin passende oder 
benötigt man da was spezielles?
Gibt es vielleicht sogar einen passenden Konnektor?

Danke Läubi für die Antwort, die zwar wohl nicht mir galt aber sie hat 
mir vom Schlauch geholfen ;)

Positive Kontrastspannung - ok. Ich hätte nur lesen müssen.

Wegen deinen Connectoren: Ich habe so Zeug aus div. 
Unterhaltungselektronik (ich glaub es waren DVD-Player oder so) 
geschlachtet. Da ist ab und an was passendes dabei....

Lg,
 Wolfgang

Das wegen der Kontrastspannungserzeugung würde mich auch interessieren.

Hallo Läubi
wenn du die LEDs zum umbau von den WD-H3224V meint musste mal nach den 
Ebay link weiter oben schaun. Die sollten als replacment gut passen. Ich 
hab mir jetzt auch mal 200 so SideLEDs bestellt damit ich meine umbauen 
kann.

Hallo Kai,

könntest du mir den ggf. ein paar abtreten oder benötigst du alle 200 
Stück?
Und wie sind so die Erfahrungen lässt sich das Display danach wieder gut 
Zusammenbauen oder ist das eher Glücksache?

Wie du weiter oben ja siehst muss man das Touch und den Zeilentreiber 
ablöten.

Der folienleiter des Touchpanels geht noch recht einfach mit viel 
Lötzinn und alles auf einmal warmmachen ab.
Beim Zeilentreiber muss man aufpassen und mit vorsicht die Pins einen 
nach dem anderen warmmachen und nach oben ziehen.

Das umbauen und wieder zusammenlöten ist dann nicht das Problem.

Ein paar LEDs könnte ich dir gerne zuschicken. Ich kauf halt immer gerne 
auf Vorrat xD.

MfG Kai

Jaaaa! Es ist vollbracht. Jetzt nur alles schnell ins Gehäuse bringen 
damit nichts mehr passieren kann.

DANKE FÜR DIE DEINE ARBEIT BENDIKT.

Ich habe nun das Wintek in Betrieb (mit positiver Spannung). Ich habe 
zunächst alles noch einmal neu aufgebaut und wieder der selbe Fehler. 
Die Spannung ist zusammengebrochen.
Ich habe dann zur Kontrolle mal ein zweites Netzteil mit 24V 
angeschlossen und siehe da, es funktioniert.

Daraufhin habe ich mich auf die Erzeugung der +24V mit dem MC34063 
konzentriert.

Dabei verwendet habe ich ein Dimensionierungstool 
http://www.nomad.ee/micros/mc34063a/
Allerdings musste ich noch etwas mit den Widerständen spielen.

Der 34063 läuft nun ohne externen Transistor und es fließen 3mA bei 21V, 
die für den Kontrast beim Wintek ideal sind.

Zum Schluss nur die Versorgungsspannung auf genau 5V gebracht, da das 
Display etwas geflimmert hat, als ich ein altes Handy Netzteil mit 5.3V 
verwendet habe.

Das Display ist für meine Heizungssteuerung mit ATMEGA644 vorgesehen und 
die ideale Lösung dafür.


Grüße
Matthias

Hallo Benedikt:
erst einmal Danke für Deine tollen Projekte!
Benedikt K. schrieb:
> Hier eine neue Version mit einer zusätzlichen großen 32x48 Schriftart.
> Optimal um irgendwelche Infos anzuzeigen, die auch aus größerer
> Entfernung lesbar sein sollen. Der Zeichensatz ist per Software
> umschaltbar. Da der Zeichensatz sehr viel Speicher braucht, wird jetzt
> ein mega168 benötigt, dessen Flash zu 98,2% voll ist. Trotzdem wurde der
> Zeichensatz auf 64 Zeichen (Großbuchstaben, Zahlen und ein paar oft
> benötigte Sonderzeichen wie ,:° usw.) reduziert.
Hast Du den auch mit Kleinbuchstaben? Habe eh einen M328 verbaut und 
benötige nur den großen Zeichensatz da müßte das noch mit reinpassen.
Gruß Willi

Matthias Reichelt schrieb:
> Der 34063 läuft nun ohne externen Transistor und es fließen 3mA bei 21V,
> die für den Kontrast beim Wintek ideal sind.
magst du ggf. den Schaltplan+Werte veröffentlichen? Würde für den 
nachbau sicherlich hilfreich sein.

Läubi .. schrieb:
> Matthias Reichelt schrieb:
>> Der 34063 läuft nun ohne externen Transistor und es fließen 3mA bei 21V,
>> die für den Kontrast beim Wintek ideal sind.
> magst du ggf. den Schaltplan+Werte veröffentlichen? Würde für den
> nachbau sicherlich hilfreich sein.

Wie viel Strom zieht die ganze Sache denn am Eingang eigentlich? Und 
sind die 21V gegen Masse gemessen?

Moin,

der Thread ist ja mittlerweile schon ganz schön angewachsen, von daher 
konnt ich mir jetzt nicht alle Beiträge durchlesen, also sorry, falls 
einige meiner Fragen schon an anderer Stelle beantwortet wurden.

Ich will mir ne grafische Fernbedienung für meine Soundanlage basteln 
(Umsetzung jetzt mal zweitrangig). Dazu wollt ich das TG322450 + 
Inverter (Best. Nr. Pollin: 531 321) ordern.

1. Ist die Funktonalität des Touchpads hier schon mal besprochen worden, 
s.h. kann ich das so ohne weiteres benutzen, auch über den hier 
besprochenen Controller für das Display? (Laut Schaltung ist das wohl 
noch nicht mit drin, oder?)

2. Wie schnell ist das TG322450 wirklich? Laut Datenblatt um die 75 Hz 
Wiederholrate, aber kann ich da auch FFT drauf darstellen, ohne das da 
was schliert?

3. Ist das WD-H3224V dem TG322450 was Fragen 1 und 2 angeht ebenbürtig, 
oder gibts da Vor- bzw. Nachteile?

4. Oder schlagt ihr da ein ganz anderes Display für mein Vorhaben vor?

Komische Fragen, ich weiß, aber wo soll ich fragen, wenn nicht hier, bei 
denen, die sich mit den Displays auskennen und diese auch besitzen ;)

Gruß,
André

Hi,

sorry, habe schon länger nicht hier ins Forum geschaut. Werde morgen die 
Stromaufnahme messen. Die Schaltung für die Kontrastspannung habe ich 
nach http://www.nomad.ee/micros/mc34063a/ gebaut aber mit den 
Widerständen ziemlich spielen müssen. Ich muss ehrlich zugeben, dass ich 
die Büchse geschlossen habe nachdem alles funktioniert hat. Sie läuft 
nun seit 2 Monaten im Dauerbetrieb perfekt.
Hintergrundbeleuchtung und auch Touchscreen funktionieren. Die Mühe mit 
dem LED Tausch habe ich mir nicht gemacht. Das war mir zu viel. Ein 
super Display.
Ich mach nochmal auf schaue was ich da verbrochen habe :-). Dann kann 
ich Stromaufnahme und auch die Widerstände am 34063 ermitteln.
Das ganze incl. Net-IO Board hängt an einem alten Netzteil vom NEC 616. 
5.3V und 1A laut Aufdruck.

Grüße
Matthias

Hallo,

anbei die Schaltung, wie ich sie zur Erzeugung der 21V aus 5V verwende.
Bei der Erstinbetriebnahme habe ich jedoch erstmal die 21V von einem 
zusätzlichen Netzteil genommen um zu sehen ob Display und Controller 
funktionieren. Danach erst die verwendung der 21V aus dem 34063.

Insgesamt nimmt die Box 160mA auf. Incl. Atmega8 und LED 
Hintergrundbeleuchtung.

Der Touchscreen ist durch zwei Spannungsteiler und und Anschluß an 2 ADC 
Ports des ATMEGA 644 realisiert. Anbei ein Screenshot aus Wikipedia wie 
so ein Touchscreen aufgebaut ist.

Matthias Reichelt schrieb:
> anbei die Schaltung, wie ich sie zur Erzeugung der 21V aus 5V verwende.
Danke schon mal, aber Schaltplan als jpeg ist eigentlich nicht soo der 
Hit ;)
Das Display sieht cool aus, wie hast du das befestigt? Der Rahmen bietet 
da ja wenig Angriffspunkte, ist das ganze auch ohne Beleuchtung gut 
lesbar auf dem Bild sieht es zumindest so aus als sei diese abeschaltet?

André G. schrieb:
> 1. Ist die Funktonalität des Touchpads hier schon mal besprochen worden,
> s.h. kann ich das so ohne weiteres benutzen, auch über den hier
> besprochenen Controller für das Display? (Laut Schaltung ist das wohl
> noch nicht mit drin, oder?)
Der Controller hat keinen ADC und kann so das Touch nicht auswerten! Du 
benötigst mindestens einen weiteren Controller für die Auswertung.

> 2. Wie schnell ist das TG322450 wirklich? Laut Datenblatt um die 75 Hz
> Wiederholrate, aber kann ich da auch FFT drauf darstellen, ohne das da
> was schliert?
Muss man probieren, hängt auch von der Umgebungstemperatur ab, aber der 
hier vorgestellte Plan kann "nur" Text also nix Grafik! Dafür gibt es 
einen weiteren Thread!

Hi,

sorry wegen jpg aber bei mir zählt mehr die Funktion. Bei der begrenzten 
Zeit die ich zum Basten hab baue ich nicht auf Professionellem wege. 
Erfolge sind mir wichtiger.
Die Beleuchtung braucht man am Tage nicht unbedingt aber wenn das Licht 
ungünstig steht hilft die Beleuchtung auch am Tag.

Das Gehäuse ich vom grossen C. Im rechten Teil neben dem Display ist der 
Atmega und die Spannungsaufbereitung untergebracht. Befestigt ist das 
Display im Gehäuse mit Heisskleber :-) So läßt es sich perfekt 
platzieren, man sieht keine Schrauben und es hält super. Auch wenn man 
mal etwas stärker auf den Touchscreen drückt.

Hossa,

Läubi .. schrieb:
> Muss man probieren, hängt auch von der Umgebungstemperatur ab, aber der
> hier vorgestellte Plan kann "nur" Text also nix Grafik! Dafür gibt es
> einen weiteren Thread!

Ich werd die FFT anhand von Balken darstellen, da kann ich ja auch 
selbstdefinierte Zeichen nehmen. Das sollte klappen.

Gruß,
André

Hallo Benedikt,

Obwohl ich inzwischen einige ASM Projekte gemacht habe, bin ich immer 
noch Anfänger. Trotzdem möchte ich deinen Code verstehen, da ich das 
Projekt sehr interessant finde.

Nun hänge ich völlig fest bei der hloop Routine. Wenn ich es richtig 
verstehe, dann wird im ersten Durchlauf mit "ld ZL, X+" der Inhalt des 
Speichers 0 (durch "movw XL, XSaveL" wird ja zuvor die Adresse auf 0 
gestellt) nach ZL geladen. In der Simulation taucht dann in tempi der 
Wert 0x0B auf. Wo kommt der her und was soll damit geschehen??
Es ist zwar tatsächlich der erste Wert im Flash, aber alle weiteren 
stimmen nicht überein.
Wenn ich ins SRAM will müßte in XL doch eigentlich DDRAM stehen, oder 
liege ich völlig falsch??

Gruß
Bruno

Hi,

habe mir auch ein Wintek WD-H3224V Display von Pollin besorgt.
Leider ist mir nicht klar, wie ich das winzige 24 polige Flachbandkabel
mit meinem Controller verbinden kann.
Gibt es Buchsen bzw. Adapter? Wenn ja - Wo!

Gruß
Leo

>Gibt es Buchsen bzw. Adapter? Wenn ja - Wo!


Na klar.
Fertige Adapter bei
http://www.lc-design.de/shop/de/index.htm?http://www.lc-design.de/shop/de/k006u005s001.htm

Ich hatte FFC Stecker von Farnell.

Wigbert

Hallo

Ich habe mir vor langer zeit ein Wintek WD-H3224V zugelegt.
jetzt möchte ich es auch in betrieb nehmen.
Ich würde es erst mal testen ob es geht im einfachen Textmodus,
nur habe ich keinen Anschlussplan oder so und kein Testprogramm 
gefunden.

Bauteile die Zugverfügung stehen :

Wintek WD-H3224V
FFC Buchse
SMD-LEDs  für eine andere Hintergrundbeleuchtung
ATmega 32 oder auch 644
und Kleinteile Für die Testschaltung :-)

ich hoffe mir kann jemand helfen.

Hallo,

erstmal ein Kompliment an Benedikt für dieses tolle Projekt!

Als Anfänger eine Frage an die Display-Experten. Nachdem es mir gelungen 
ist, ein NANYA s/w Display zur Anzeige zu bewegen, stellt sich natürlich 
der Ehrgeiz ein.
Ich habe mir als Ziel gesetzt, eine Kalenderuhr zu realisieren. Als 
statische Anzeige funktioniert es schon ganz gut (siehe Bild). Da ich 
mich z. Zt. noch im Experimentierstadium befinde, nutze ich weiterhin 
den ATMega8 ohne externen Speicher.
Realisiert habe ich die Anzeige durch Speicherung des Bildes im Flash 
und zeilenweiser (24 Pixel) Übertragung ins SRAM. Dafür reichen die 
Speicher gerade aus. Nun versuche ich schon geraume Zeit, nicht nur 
ganze Zeilen, sondern Zeilensegmente ins SRAM zu laden, damit ich dann 
auch Werte ändern kann. Dabei stoße ich auf das Problem, dass einige 
geringfügige Programmänderungen dazu führen, daß das Bild völlig 
verschwindet. So funktioniert z.B. das Auffüllen einer Zeile mit 
Nullwerten normal, das Übertragen von Daten aus dem Flash bei sonst 
gleichem Code aber nicht. Kann es daran liegen, daß der Bildaufbau und 
die Datenspeicherung im SRAM irgendwann zeitlich kollidieren?

In diesem Zusammenhang suche ich auch noch nach einer optimalen 
Möglichkeit die Änderung von Teilbereichen zu realisieren. Wer kann mir 
dabei helfen????

Ich muß hinzufügen, daß ich nur mit ASM arbeite, für C hat es bislang 
noch nicht gereicht.

Für jede Antwort schon im voraus herzlichen Dank!

Bruno

Hallo,

leider hat sich auf meine Fragen noch keiner gemeldet?????

Für den ersten Teil kann ich die Antwort inzwischen selbst geben. Nach 
Ausschluß aller anderen Möglichkeiten konnte nur noch der ATMega8 defekt 
sein. Und so war es dann auch, was sich aber nur bei ganz speziellen 
Aufgaben bemerkbar macht. Mit einem neuen funktioniert es jedenfalls 
jetzt wie gewünscht.

Über Unterstützung würde ich mich aber nach wie vor freuen!

Bruno

Die Textmodus-software kenn ich zwar nicht (kenne nur die für 
graustufen), aber voller RAM und geringe Änderungen an der Software die 
dazu fürhen, dass nichts mehr so läuft wie es soll klingt stark nach nem 
Stacküberlauf. Sind nur mutmaßungen, aber vielleicht hilfts ja.

Hallo Sebastian,

herzlichen Dank für die Info!
Kann man so einen Stacküberlauf mit irgendwelchen Mitteln nachweisen??

Bruno

Wenn du einen Stacküberlauf händisch nachvollziehen willst musst du 
erstmal schaun, wie viel Ram dein Programm so verbraucht. Ich hab mal 
schnell die aktuelle Version von Benedikt durchassembliert. Hier sind 
das laut AVR-Studio 852Byte. Du hast also noch 1024-852=72Byte für den 
Stack übrig.
Stack wird bei Jedem call/rcall und jedem push gebraucht. Jetzt kann man 
durch den Quelltext gehen und die call-hirarchie mit allen pushes 
nachvollziehen. Dann weiß man es mit sicherheit.
Auf den maximalen Stackverbrauch des normalen programm kommt dann noch 
der Stackverbauch der Interrupts. Die darf man nicht vergessen.

Rein vom Gefühl her (hab den quelltext immernoch nicht angeschaut: Wenn 
du keine großen felder oder push-orgien eingefügt hast wirds nicht der 
Stack sein. Aber ich würde mal drüberschaun, 72Byte reicht nicht ewig.


Noch ne möglichkeit um sowas auf die Schliche zu kommen:
Initialisiere oberhalb der 852 reservierten Byte ein paar Byte Ram mit 
nullen. Dann überprüfst du in der Mainloop (bei einer funktionierenden 
version) ob die noch alle auf null stehn. Wenn nicht, kommt dein Stack 
dem genutzten Ram schon gefährlich nahe. Dann sollte mans genauer 
untersuchen.

Viel erfolg,
Sebastian

Hallo Sebastian,

da ich mein Programm etwas anders aufgebaut habe als Benedikt, habe ich 
noch mehr im SRAM belegt u.z 960 Byte. Ich übertrage die Bilddaten 
zeilenweise aus dem SRAM in das Display und nicht aus dem Flash. Eine 
Zeile 40 byte breit und 24 Pixel hoch ergibt 960 byte.
Ich habe das Programm mal ne Weile im Simulator laufen lassen und mir 
dann den Stack angesehen. Danach werden eigentlich nur 2 byte vom Stack 
genutzt (von 64). Müßte man es nicht auch auf diese Art sehen können?

Bruno

Wenn das Programm keine Eingaben von der Ausenwelt bekommt kann mans 
auch simulieren um den stackverbrauch zu beobachten. Wenns auch auf 
Eingaben reagiert müsste man die halt auch simulieren. Aber 2 Byte Stack 
glaub ich dir nicht. Allein schon, wenn du einen Interrupt verwendest 
brauchst du mindestens 3 Byte: 2 für die Rücksprungadresse (macht der 
controller selbst) und 1 byte fürs SREG (das musst du selbst sichern). 
Wenn du keine Register speziell für Interrupts reserviert hast musst du 
auch noch die im interrupt verwendeten Register auf den Stack sichern.
Nachdem dein Programm aber anders aufgebaut ist als Benedikts, brauchen 
wir/ich erstmal deinen Quelltext. Sonst kann man nur raten. Könnte ja 
auch was ganz anderes sein.

Sebastian

Inzwischen habe ich auch noch einen dritten ATMega8 versucht.
Resultat:
Code Version 2 verarbeiten alle 3 problemlos.
Code Version 3 klappt nur bei einem.

Was den Stack betrifft, so habe ich nur auf die Anzeige geschaut und da 
waren von den 64 bytes nur 2 überschrieben, alle anderen FF.

Bruno

Jetzt muss ich dich leider enttäuschen:
Der Stack passt wirklich. Du brauchst wirklich nur 2 Byte, weil du extra 
Interruptregister genommen hast.
Mehr kann ich aber nicht sagen, denn ehrlich gesagt fehlt mir grad die 
Motivation deinen Code nachzuvollziehen. Auch weil kaum Kommentare drin 
sind...

Trotzdem viel Erfolg beim finden
Sebastian

Auch wenn ich dich verstehe, bin ich natürlich doch enttäuscht!
Ich habe die Version 3 mal ausgiebig kommentiert, vielleicht kannst du 
dich ja doch noch überwinden.

Version 2 unterscheidet sich von Version 3 nur dadurch, daß alle Zeilen 
(außer Leerzeilen) im Flash komplett gespeichert sind und von dort ins 
SRAM gelesen werden.

Bruno

So, ich hab mal noch n blick drauf geworfen. Den Fehler hab ich zwar 
nicht, aber einiges zu sagen trotzdem...

Erst mal... hab ich das konzept richtig verstanden?
Im Flash liegt das gesamte Bild das angezeigt wird. Davon kopierst du 
immer 24 Zeilen in einen SRAM-Puffer, der dann vom Interrupt ausgelesen 
wird.
Das bild liegt aber nicht in Rohdaten vor (sonst würde es ja nicht 
reinpassen) sondern nur die Teile, in denen auch wirklich was angezeigt 
wird. Der Rest wird per Software als Null in den RAM übertragen.
Ein richtiger Font ist das soweit ich das sehe aber auch nicht, oder?

Mal angenommen das ist so richtig.
Es erscheint mir nicht ganz so vernünftig die Daten in der Mainloop von 
Flash zum Ram zu kopieren. Du synchronisierst das ganze zwar, aber wenn 
deine Mainloop zu lang wird löst der displayinterrupt wieder aus, bevor 
die Daten fertig sind und es wird irgendein Mist angezeigt. (Das KÖNNTE 
auch dein problem sein)

Wenn das ganze mal ne Kalenderuhr werden soll kannst du bei dem Konzept 
ja sowieso nicht bleiben. Die anzeige soll sich ja ändern. Das geht nur 
mit einem Font vernünftig.
Wieso baust du nicht auf der Version von Benedikt auf? Die hat einen 
integrierten Font und kann die Anzeige ändern. Du schmeißt die 
UART-empfangsroutinen raus baust aber auf seine High-level funktionen 
auf.

Ok, verschiedene schriftgrößen gibts dann erstmal nicht mehr (oder 
vielleicht zwei verschiedene - glaube da gabs was). Aber das lässt sich 
sicher reinoptimieren. Denkbar wäre zum Beispiel die Ziffern nochmal in 
einem größeren Schriftsatz zu hinterlegen so dass man dann zwischen 
beiden auswählen kann. Sollte sich jedenfalls alles als erweiterung auf 
Benedikts sofware aufbauen lassen.

Alternativ - wenn du unbedingt bei deinem Konzept bleiben willst: Ich 
würde das Umkopieren vom Flash in den SRAM im Interrupt erledigen, weil 
das eben unbedingt synchron zum Interrupt sein muss. Im Flash würde ich 
wieder einen Zeichensatz hinterlegen. Der Interrupt holt sich die 
aktuelle Zeit (die die Mainloop in den RAM schreibt) und wählt anhand 
der Uhrzeit/Datum aus, welche Ziffern ins Ram kopiert werden müssen.

viele Grüße,
Sebastian

Hallo Sebastian,

vorab herzlichen Dank, daß du dir doch noch die Zeit genommen hast. 
Finde ich super.

Nun der Reihe nach:

> Erst mal... hab ich das konzept richtig verstanden?
> Im Flash liegt das gesamte Bild das angezeigt wird. Davon kopierst du
> immer 24 Zeilen in einen SRAM-Puffer, der dann vom Interrupt ausgelesen
> wird.
> Das bild liegt aber nicht in Rohdaten vor (sonst würde es ja nicht
> reinpassen) sondern nur die Teile, in denen auch wirklich was angezeigt
> wird. Der Rest wird per Software als Null in den RAM übertragen.
> Ein richtiger Font ist das soweit ich das sehe aber auch nicht, oder?

Stimmt genau! Mein Ziel war im Flash nicht einen oder mehrere Fonts 
abzulegen (bei meinem Bild wären es vier), sondern die benötigten Daten, 
sprich Wochentage, Monate und die Ziffern in unterschiedlicher Größe. 
Die Rohdaten habe ich auch schon. Ganz egal wie ich es angehe, es 
sprengt auf alle Fälle den Speicher des ATMega8. Ich habe ihn trotzdem 
eingesetzt, da ich
- z.Zt noch keinen größeren habe,
- Benedikts Projekt schon funktionsfähig vorlag,
- und ich bei meinen Kenntnissen sowieso viel experimentieren muß.

> Mal angenommen das ist so richtig.
> Es erscheint mir nicht ganz so vernünftig die Daten in der Mainloop von
> Flash zum Ram zu kopieren. Du synchronisierst das ganze zwar, aber wenn
> deine Mainloop zu lang wird löst der displayinterrupt wieder aus, bevor
> die Daten fertig sind und es wird irgendein Mist angezeigt. (Das KÖNNTE
> auch dein problem sein)

Auch das ist natürlich völlig richtig. In meinem ersten Beitrag hatte 
ich ja schon die Vermutung geäußert, daß eventuell Bildaufbau und
die Datenspeicherung im SRAM irgendwann zeitlich kollidieren könnten. 
Inzwischen habe ich es allerdings kontrolliert und festgestellt, daß das 
nicht die Ursache für mein Problem sein kann. Die Übertragung ins SRAM 
ist bis jetzt immer noch schneller als der Aufbau des Bildes im Display. 
Aber du hast recht, das hat irgendwann seine Grenzen.
Ich habe diese Art der Realisierung gewählt, weil ich befürchtete daß 
das Display anfängt zu flimmern wenn ich alles in den Interrupt packe.

> Wenn das ganze mal ne Kalenderuhr werden soll kannst du bei dem Konzept
> ja sowieso nicht bleiben. Die anzeige soll sich ja ändern. Das geht nur
> mit einem Font vernünftig.
> Wieso baust du nicht auf der Version von Benedikt auf? Die hat einen
> integrierten Font und kann die Anzeige ändern. Du schmeißt die
> UART-empfangsroutinen raus baust aber auf seine High-level funktionen
> auf.

Das ginge natürlich, aber die Optik war mir dann doch wichtiger (-:

> Alternativ - wenn du unbedingt bei deinem Konzept bleiben willst: Ich
> würde das Umkopieren vom Flash in den SRAM im Interrupt erledigen, weil
> das eben unbedingt synchron zum Interrupt sein muss.

werde ich auf alle Fälle probieren!

> Im Flash würde ich
> wieder einen Zeichensatz hinterlegen. Der Interrupt holt sich die
> aktuelle Zeit (die die Mainloop in den RAM schreibt) und wählt anhand
> der Uhrzeit/Datum aus, welche Ziffern ins Ram kopiert werden müssen.

Prinzipiell hatte ich es so vor (abgesehen vom Interrupt), siehe oben.

Noch eine Bitte.
Letztendlich muß ich ja immer gezielt im Speicher einen Block von bytes 
ändern (mit unterschiedlicher Größe). Da ich dafür keine fertige Lösung 
habe, versuche ich mich mühsam ranzutesten (daher die unterschiedlichen 
Versionen). Kannst du mir dabei einen Tip geben?

Nochmals herzlichen Dank
Bruno

Wenn du die Daten im Interrupt kopierst dürfte es im extremfall stabiler 
laufen. Wenn bei der Mainloop-lösung das kopieren zu lange dauert zeigt 
er mist an. Halt das, was grade im Ram steht. Wenn die Interruptlösung 
zu lange braucht verliert er hin und wieder mal einen Interrupt. Dadurch 
sinkt die Framerate und das display wird ein wenig flackern. Aber er 
zeigt noch das richtige an. Nachdem du sonst keine Interrupts hast 
(erstrecht keine, die kurze Latenzen erfordern) stört es auch nicht dass 
der Controller dann relativ lang im Displayinterrupt hängt.

Zum Konzept. Wie Wärs damit:
Man könnte sich von dem 24-zeilen-block verabschieden und immer nur eine 
Zeile im SRAM behalten. Ganz grob gesagt würde ich dann immer eine Zeile 
vom Interrupt anzeigen lassen und danach (im Interrupt) die nächste in 
den RAM laden.
Fürs laden würde ich erstmal die gesamte Zeile löschen. Dann wird 
überprüft, welche Zeile denn überhaupt grade aufgebaut werden soll.
Dabei würde ich der reihe nach durchprüfen, ob der Wochentag, das Datum, 
die Jahreszahl,... angezeigt werden soll und bei jedem Treffer sofort 
die nötigen Daten rüberkopieren. Danach wird weitergegangen in der 
Überprüfungskette. Wenn du komplett durch bist steht der passende Teil 
der Anzeige im Ram. Leerzeilen haben sich auch schon erledigt, weil du 
ja vorher den Ram gelöscht hast. In leerzeile wurde er dann ja auch 
nicht überschrieben.
Als Beispiel postuliere ich jetzt mal, dass alle Wochentage 24*128pixel 
groß sind, also je 16*24 Byte im Flash belegen. Also hintereinander im 
Flash alle Wochentage als "Bild". Der erste liegt bei "Wochentage", der 
zweite dann bei Wochentage+16*24, der dritte bei Wochentage+2*16*24.
So, wir haben jetzt also festgestellt, dass in der aktuellen Zeile ein 
Wochentag reinmuss. Dann schau ich, welche Zeile des wochentags ich 
brauch (Day_Line = Aktuelle_Anzeigezeile-Wochentag_Startzeile) und 
welchen Wochentag wir haben (soll mal unter Day_of_week hinterlegt 
sein). Dann kann ich mir sehr leicht ausrechnen ab wo ich aus dem Flash 
laden muss:
Start=Wochentage+(16*24*Day_of_week)+Day_Line
Ab der Adresse liest du also 16 Byte ins SRAM an die stelle wo der 
Wochentag hinsoll (bezieht sich jetzt auf den X-offset).

Warum ich den 24-zeilen puffer abschaffen würde noch: Du gewinnst damit 
flexibilität beim Positionieren der Elemente. Außerdem brauchts deutlich 
weniger RAM.

So, ich hoffe ich habs verständlich geschriebn. In meinem Kopf ist das 
konzept vollkommen logisch :D

Sebastian

super!
Danke für die schnelle Antwort.

Damit habe ich fürs Erste genug Stoff zum Überlegen und Probieren.
Ich werde mich auf alle Fälle nochmals melden, aber das kann ne Weile 
dauern.

Bruno

Hallo Sebastian,

ich melde mich doch noch mal kurz. Ich habe meine Version 3, d.h. mit 24 
Pixelreihen je Zeile nochmals gestrafft und vor allem das Laden des SRAM 
nun in den Interrupt verlegt. Außerhalb des Interrupts ist nur noch die 
Warteschleife. In der Simulation funktioniert das Programm, aber ich 
bekomme keine Anzeige. Kann es am erforderlichen Timing für das LCD 
hängen?

Der nächste Schritt ist aber nun die von dir vorgeschlagene Version mit 
je einer Pixelreihe.

Bruno

Ich würde das SRAM-füllen hinter die Ausgabe-routine setzen. Dann zeigt 
zwar der erste Frame in der ersten Zeile kurz mist an, aber du 
verringerst den Jitter bei der Ansteuerung des LCD was gegens flimmern 
besser ist.
Wenn man will kann man den SRAM-puffer auch bei der Initialisierung des 
Controllers mit nullen vollschreiben. Dann ist die erste Zeile des 
ersten Frames immer schwarz - das fällt wirklich nicht mehr auf.

Zum Testen würde ich Den Puffer auch einfach mal mit nem markanten 
Muster füllen. Zum Beispiel Schachbrett. Dann siehst du schonmal, ob die 
Anzeige und das laden prinzipiell noch funktionieren. Wenn das läuft 
kannst du anfangen vernünftige Daten aus dem Flash zu holen.
(Wenn du den eindruck gewinnst, dass ich zu faul bin deinen konkreten 
fehler zu suchen... erwischt. Aber so lernst du auch noch was dabei)

Sebastian

Hallo Sebastian,

dein letzter Kommentar hat mich animiert, mit der 24 Pixel Version doch 
noch weiter zu experimentieren.
Nun bin ich aber mit meinem Latein am Ende.
Zuerst habe ich versucht, im Interrupt und nach der hloop Routine den 
Speicher mit einem Schachbrett zu füllen. -> kein Bild.
Dann habe ich den Speicher noch vor dem Hauptprogramm mit den Feldern 
aus dem Schachbrett gefüllt. -> sauberes Bild mit dicken vertikalen 
Streifen, d.h. OK.
Dann habe ich das Gleiche, aber innerhalb des Interrupts versucht, d.h. 
nicht genau das Gleiche, da ich ja den Speicher immer nach 24 
Pixelreihen neu lade, allerdings bleibt der Inhalt unverändert. -> 10 
dünne(1 Pixelreihe) Streifen und die dicken senkrechten Streifen kann 
man zwar erkennen, aber da muß man schon genau gucken.
Hast du die Erklärung?

Bruno

Du füllst deinen Speicher ja über eine verschachtelte schleife:
FeldHell schreibt je ein Byte und wird 4 mal durchlaufen
FeldDunkel schreibt je ein Byte und wird 4 mal durchlaufen
Und beide zusammen werden 10 mal aufgerufen
Also schreibst du da schon (4+4)*10=80 byte in deinen Speicher.
Und der ganze block wird dann CSize mal aufgerufen, wobei CSize=24. Also 
schreibst du 80+24=1920 Byte in den RAM. Damit überschreibst du auf 
jeden Fall den Stackpointer, womit das programm abstürzt.

Schreib mal statt CSize an der Stelle CSize/2, dann sollte es eigentlich 
funktionieren.

Allgemein noch ein Tipp: Mal dir vorher ein flussdiagramm von dem, was 
du programmieren willst. Das Programm wird deutlich strukturierter, es 
fällt leichter es zu schreiben und man macht weniger Fehler.

Sebastian

Deine Rechnung ist so nicht richtig.
FeldHell wird 4 mal durchlaufen, dann wird aber der Zähler 10 schon auf 
9 reduziert. Anschließend wird FeldDunkel 4 mal durchlaufen und der 
Zähler auf 8 reduziert. Insgesamt ergibt das 2x4x5=40 Byte, d.h. genau 
eine Pixelreihe. Mit CSize=24 bin ich wieder bei meiner 24Pixel-Zeile.

Trotzdem danke für den Tipp.
Aus Frust habe es inzwischen aber doch mit nur einer Pixelreihe im Stack 
versucht und da hat das Schachbrett auf Anhieb funktioniert.

Bruno

Du hast recht. Hab ich übersehen. Aber wenns jetzt läuft passt ja alles.

Hallo Sebastian,

Wie bereits angekündigt, hat es etwas länger gedauert, aber ich habe 
noch nicht aufgegeben!
Inzwischen habe ich das Programm entsprechend deinem Vorschlag aufgebaut 
und setze die einzelnen Zeilen aus den entsprechenden Datenblöcken 
zusammen.

So weit, so gut. Das Problem ist, daß sich dann nach jeder Zeile Linien 
einstellen und die Zeilen unterschiedlich starke Helligkeiten bekommen. 
Anscheinend hängt die Intensität auch von der Anzahl der Datensätze in 
der jeweiligen Zeile ab.
In der Zeile mit dem Monat (hier September) sind das z.B. 8 Datensätze.

Gibt es dafür vielleicht eine einfache Erklärung??

Bruno

Genaues kann man ohne Quelltext nicht sagen, aber nachdem du 
verschiedene Helligkeitsstufen hast tipp ich drauf, dass die Zeilen 
unterschiedlich lang angesteuert werden.
Wenns bei einer zeile länger dauert, bis die nächste ins display geladen 
ist wird sie vom display auch so lange angesteuert. Auch deshalb sollte 
man im Interrupt erst die Anzeige bedienen und dann den speicher neu 
laden.

Verwendest du im Ram Jetzt einen puffer für 24 Zeilen (danach schaut das 
bild aus)? Ich denke mal, dass deine laderoutine zu lang braucht. Das 
würde jedenfalls die hellen pixelzeilen erklären. Wenn du die Framerate 
probeweise mal runterstellst und die hellen Zeilen verschwinden solltest 
der Fehler dort liegen.
Die großflächig verschiedenen Grauwerte kann ich mir jetzt aber auch 
nicht erklären. Außer wenn du zeilenweise in den Ram Lädtst. Aber auch 
dann ists nicht ganz schlüssig.
Allgemein gilt aber: Ohne Quelltext kann man nur raten.

Btw: Ging doch jetzt richtig flott. Mein Projekt kommt mangels Zeit viel 
langsamer vorran :(

Viele grüße, Sebastian

Herzlichen Dank für die superschnelle Antwort.
Ich hatte gehofft ich könnte dir das Studium des Codes ersparen (-:

Ich baue das Bild aus einzelnen Pixelreihen (40 Byte) auf. Die Daten im 
Flash sind aber jeweils der gesamte Block mit 24, 48 oder 72 Pixeln 
Höhe. Ausgelesen werden sie zeilenweise, d.h. 7 Textzeilen mit jeweils 
24 Pixel Höhe und zusätzlich 3 Leerzeilen.

Bruno

Hallo zusammen,

hat jemand eventuell jeweils 2 Stück abzugeben?
Jeweils 10 bei Farnell zu bestellen, ist mir zu viel.


Wigbert Picht-dl1atw schrieb:
> Hi,
> wer Lust auf Stecker hat, beim TG 322450:
> Farnell Nr.165-9861 ; 124-5267
> die Spannungsversorgung nach DBL mit angegebenen IC , nur die reihen-R
> sind zusätzlich.
>
> Meine WD-H3224 sind auch noch unterwegs. Ist wohl ein weiter Weg
> zu mir.
>
> Wigbert

Gruß Sascha

wieso verschiebst du das 'cpi   C_Cnt, CSize' nicht nach skipcloop? 
Immer wenn skipcloop angesprungen wird kommt vorher genau dieser 
vergleich. Wenn dus zu skipcloop verschiebst wirds besser lesbar. Man 
sieht auf einen blick was vergleichen wird und was mit dem Vergleich 
gemacht wird.

Mal etwas nachgerechnet: Meine vermutung, dass du zu langsam füllst 
könnte stimmen. Wenn ich mich nicht verrechnet habe hast du zwischen 
zwei Interrupts nur 1024 Takte. Nachdem das Ausgeben der Daten ja auch 
ne gewisse Zeit braucht hast du fürs laden der Daten nur ca. 450 Takte. 
Vor allem in Zeilen mit viel Inhalt könntest du da leicht drüber kommen. 
Wenn du die Framerate verringerst sollte es also vor allem in der 
Monatszeile bessser werden, fängt aber halt zu flackern an. Also auch 
keine echte Lösung. Du müsstest dir also überlegen wie du die daten 
schneller laden kannst.

Die weißen querstreifen machen aber irgendwie keinen sinn... Muss aber 
zugeben, dass ich jetzt nicht mehr sagen kann. Hab den Code nicht soo 
genau angeschaut. Vielleicht später :D

Sebastian

Das mit dem cpi hat sich irgendwann so ergeben, da ich ja schnell mit 
den ursprünglichen branch Befehlen am Limit war. Aber du hast natürlich 
recht, so ist es Unsinn, nur man sieht es selbst nicht mehr.

Deine Vermutung betreffend Framerate war ebenfalls richtig. Ich habe das 
Display jetzt mit 45 laufen und die hellen Flächen sind weg. Von 
Flackern ist noch nichts zu sehen.

Das Problem mit den weißen Streifen habe ich auch gelöst u.z. ist mir 
aufgefallen, daß zwar die erste Zeile nach der Anzeige im LCD geladen 
wird, nach der letzten Pixelreihe jeder Zeile das Programm aber zuerst 
noch durch das Ladeprogramm der alten Zeile läuft und unmittelbar 
anschließend schon die zweite Zeile geladen wird. So habe ich am 
Zeilenübergang zwei Ladevorgänge und beide vor der Übertragung ins 
Display.

Nach Änderung dieser beiden Punkte, ist das Bild super.
Nun stellt sich das nächste Problem mit der Auswahl des richtigen 
Datenblocks im Flash, d.h. ich verschwinde erstmal wieder in der 
Versenkung.

Bruno

Hallo Max.
Das mit dem 16F88 wir wohl so ohne Weiteres nix werden. Außer man 
übertaktet ihn(was aber sehr gut möglich ist). Nächstes Problem ist der 
relativ kleine Flash. Das würde aber noch für einen abgespeckten, 
kleinen Schriftsatz reichen. Für den 18F2550 sieht die Sache schon 
besser aus. Schau mal (viel) weiter oben: 
Beitrag "Re: Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus"
Vielleicht hilft das weiter.
Wenn was unschlüssig sein sollte, melde dich ruhig noch mal.
Meik

PS: Da fehlt eigentlich noch die Schriftsatz-inc Datei im Quellcode. 
Falls du die noch brauchst, kann ich die gerne noch hochladen. Ist eine 
umformatierte Datei aus Benedikts font.zip

Hier die Dateien. Ich hoffe, die Belegung passt auf die Datei. Ich hatte 
verschiedene Versionen davon gemacht. Das Platinenlayout ist im Target 
Format.

Gruß Meik

Hallo Sebastian,

ich brauche wieder Hilfe!!!
Das Gute vorweg. Das Display funktioniert und ich kann die Werte zeigen, 
die ich vorher als Vorgabewert im SRAM definiert habe. Es fehlt jetzt 
eigentlich nur noch die Einspeisung dieser Vorgabewerte durch eine RTC.
Aber da fängt das Problem an. Ich nutze als RTC den DS1307 von Dallas, 
der mit einer I2C Schnittstelle arbeitet. Nun habe ich mal die 
wesentlichen Routinen in das Programm eingebaut und zwar schon so, daß 
jeder Wert einzeln gelesen wird. Aber auch dann sind die I2C Routinen so 
lang, daß ich außerhalb des Interrupts zu wenig Zeit zur Verfügung habe. 
Ich kann natürlich die Framerate reduzieren, aber das hat ja seine 
Grenzen.

Welche Möglichkeiten habe ich noch??

Gruß
Bruno

Erstmal natürlich glückwunsch, dass die Anzeige jetzt voll funktioniert.

Die eine möglichkeit wäre, den Code zu optimieren. Das kann einmal auf 
befehlsebene passsieren (also schleifenzähler runterzählen lassen statt 
hoch und ähnliches) oder auf Algorithmus-ebene. Letzteres bringt 
erfahrungsgemäß deutlich mehr. Meiner erfahrung nach ists dafür 
sinnvoll, sich das programm abstrakt als Flussplan aufzuzeichnen. Dann 
gewinnt man einen überblick und sieht leichter, wo strukturelle 
verbesserungen möglich wären.

Du könntest aber auch drüber nachdenken, die RTC im AVR zu realisieren. 
Entweder über den Prozessor-takt und einen Timer-interrupt (in der 
codesammlung gibts code zur erzeugung einer exakten 1s-zeitbasis). Oder 
über einen Uhrenquarz der einen Timer taktet. Ich kann dir jetzt aber 
nicht sagen, ob es damit besser wird, denn du hättest wieder den 
Timerinterrupt, der immer mal dazwischenfunkt und CPU-last erzeugt.

Das sinnvollste ist wohl erstmal dein Programm zu visualisieren und da 
optimierungen zu suchen. Vielleicht hast du auch irgendwo unnötige 
schleifen oder ähnliches drin. Sowas findet sich so auch relativ gut.

Viel Erfolg, Sebasitan

Danke für die gewohnt schnelle Reaktion!
Um ehrlich zu sein, habe ich im Moment nicht sonderlich Lust den Code 
mit dem ich mich ja nun schon mehrere Tage rumschlage nochmals 
anzugehen. Die Zeit kommt aber sicherlich wieder.
In der Zwischenzeit ist mir aber auch eingefallen, daß die Megas ja 
einen Hardware TWI haben. Daran hatte ich nicht gedacht, da ich bisher 
immer mit Softwarelösungen gearbeitet habe. Vielleicht klappt es ja 
damit.

Eine Grundsatzfrage habe ich aber noch. Was machen andere, die ja 
teilweise sehr komplexe Bildinhalte darzustellen haben? Natürlich werden 
die mit höheren Taktraten arbeiten, aber ist es nur das?

Bruno

Deine Frage ist jetzt ehr grundlegend gemeint, nicht speziell auf 
benedikts lösung bezogen, oder?

Erstmal gibts ja benedikts lösung auch als voll-grafik-version. Da hat 
er "einfach" noch ein wenig Hardware dazugenommen, die dann den 
Prozessor stark entlastet.
Wenn man größer werden will (aber auch schon für kleinere Displays) 
gibts spezielle Displaycontroller, die die gesamte Ansteuerung in 
Hardware implementieren und die Daten aus einem eigenen RAM auslesen. 
Man muss dann nur noch dem controller die Daten rüberschieben. Mit 
passendem Interface kann man dann auch schon mit einem AVR recht 
beachtliche Datenraten erreichen. Ansonsten braucht man halt einen 
größeren Controller, der schneller taktet, eine breitere Architektur hat 
(16 oder 32 bit statt 8) oder andere Techniken verwendet, um mehr 
rechenleistung/Datendurchsatz zu erziheln. Der Trick ist aber meist 
einfach, für die eigentliche Ansteuerung des LCD einen Seperaten 
Controller mit genügend RAM zu haben.

Gruß, Sebastian

Ja, genau so war die Frage gemeint. Ich hatte mir die Grafik_Version von 
Benedikt schon mal angesehen, aber soweit ich mich erinnern kann, ist 
das ja eine Kombination von C und ASM Codes. Da ich C nicht kann, bin 
ich da nicht tiefer eingestiegen. Von der Hardware gesehen war das ja 
hauptsächlich das externe RAM und ein dafür geeigneter Prozessor. Wo 
liegt da der Schlüssel für die Steigerung der Rechnerleistung? Der 
Speicher alleine machts ja noch nicht, oder?

Bruno

Ja, die Grafikversion ist in C und nur die Low-Level Routinen in ASM. 
Man kann sich aber einen zweiten Controller über UART dranhängen und die 
Daten an den Displaycontroller schicken. Dann braucht man sich auch 
nicht um C kümmern.
Der RAM ist (soweit ich das sehe) hauptsächlich nötig, um allgemein 
Grafik darstellen zu können. In der Textversion reicht es aus, einen 
Font im Flash zu haben und das bild erst während der Anzeige zu 
"synthetisieren". In der Grafikversion muss man immer das gesamte Bild 
im RAM vorhalten - es besteht ja nicht aus vordefinierten Elementen.
Was auf jeden Fall Zeit bringt, sind die Logikgatter die er noch 
verwendet hat. Die meisten Steuersignale des Displays werden in Hardware 
erzeugt. Auf diese weise kann man 8 Pixel in 6 Takten Rausschieben. In 
deiner Version werden dafür (wenn ichs richtig im Kopf habe) 13 Takte 
benötigt, also etwa das doppelte.

Danke für die Info!

Gruß
Bruno

Hallo Sebastian,

nach längerer Pause wieder ein Lebenszeichen!

!!!Die ATMega8 Uhr läuft!!!!

Einen ATMega16 habe ich mir in der Zwischenzeit schon besorgt, sodaß 
einer endgültigen Version nichts mehr im Wege steht.

Nochmals herzlichen Dank für die Unterstützung. Vielleicht hast du ja 
mal Zeit und Lust den endgültigen Code nach Vereinfachungen 
durchzuschauen. Ich werde ihn ins Forum stellen, wenn die Uhr fertig 
ist.

Noch nicht optimal ist das Einstellen der Uhrzeit. Im Moment muß ich 
dazu das Programm nochmals mit geänderten Vorgabewerten einspielen. Mir 
fällt dazu aber auch noch nichts Vernünftiges ein.

Bruno

Glückwunsch! Wegen dem Uhrzeit stellen: Ein paar tasten dran die in der 
mainloop abgefragt werden. Eine erhöht die Stunden, eine die Minuten und 
eine setzt die Sekunden auf Null. Wenn du willst kannst du auch noch 
jeweils eine fürs runterzählen nehmen. Beim Booten startet die Uhr halt 
um 00:00Uhr.
Etwas gedanken müsste man sich noch um die Tastenentprellung machen. 
Normal nimmt man einfach einen Timer. Nachdem du aber eh schon recht 
wenig zeit übrig hast würd ich die Tastenentprellung lieber in einen 
vorhanden timer dazuquetschen oder gar in der mainloop abhandeln. Aber 
um da konkrete Ratschläge zu geben muss man den Code kennen.

Sebastian

Das Problem ist, daß ich außerhalb des Interrupts nichts mehr 
unterbringe. Ich habe jetzt schon den I2C Bus mit dem Maximalwert von 
100kHz getaktet. Außerdem führe ich jede Aufgabe, d.h. Einzelwerte 
abholen und in BCD umwandeln immer getrennt aus, u.z. nur am Anfang 
eines Frames wo ich im Interrupt außer der Übertragung ins Display 
nichts weiter zu tun habe (die Leerstellen stehen ja noch von der 
letzten Zeile im SRAM). Die Framerate habe ich jetzt auf 55 stehen.

Bruno

Hallo,

neuerdings habe ich auch ein WD-H3224V mit eigenem Controller am Laufen. 
Dabei habe ich festgestellt, daß bei Anzeige von statischem Inhalt 
einige Pixelzeilen mit der Zeit 'einbrennen' bzw. 'müde' werden. Dies 
äußert sich in einem halbdunklen, diffusen Pixelsalat, der auch beim 
Abschalten der Displayspannungen noch einige Sekunden sichtbar bleibt. 
Hat sich dieser Salat abgebaut und schaltet man das Display wieder ein, 
ist wieder alles für eine gewisse Zeit normal, bis das Phänomen wieder 
auftritt. Ich habe schon mit verschiedenen Frequenzen des M-Signals 
herumgespielt (toggeln alle 7, 13, 21 Zeilen oder 1x pro Frame), wobei 
hohe Frequenzen das Ergebnis verbesserten, aber zu einer hohen 
Stromaufnahme führten. Ganz weg ist das Problem aber nie. Kann das 
jemand von euch nachvollziehen?

Alo ich habe nochmal probiert und das Problem tritt hauptsächlich dann 
auf, wenn die LCD-Spannung geringfügig zu hoch ist, so daß 
nichtangesteuerte Pixel leicht grau mitschimmern. Nehme ich die Spannung 
etwas zurück, verschwinden die Geisterpixel. Bei anderen Displays ist 
mir das bislang nicht aufgefallen.

Hallo Sebastian,

Nachdem ich mir ein paar Tage Auszeit genommen hatte, läuft nun die 
komplette Uhr auf dem ATMega16. Es war allerdings wieder mit 
Hindernissen versehen, da auch der Speicher vom AT16 zu klein ist um die 
Daten bequem unterzubringen. Mit bequem meine ich, die Texte für Monat 
und für Wochentag jeweils mit konstanten Längen abzuspeichern. So mußte 
ich im Programm noch eine geeignete Längenanpassung vornehmen.
Nach wie vor ungelöst ist das Stellen der Uhr, auch wenn die Genauigkeit 
der Dallas RTC sehr gut ist.
Insgesamt ist das Programm schon sehr umfangreich geworden und ich frage 
mich wirklich ob es nicht auch einfacher geht. Aber es läuft zumindest.

Gruß
Bruno

@travelrec:
Kann dir leider nicht wirklich helfen. Das einzige was ich sagen kann 
ist, dass es normal ist, dass LCDs irgendwann "einbrennen". Aber die 
Zeiten liegen eigentlich deutlich höher als ein paar Stunden oder Tage. 
Zumindest soweit ich weiß.

@Bruno:
Teile deinen Quellcode mal auf mehrere Dateien auf. Das macht das ganze 
viel Übersichtlicher. Steck z.B. die ganzen Datentabellen in eine 
Extradatei (wenn nicht sogar mehrere). Oder auch den Interrupt 
auszulagen macht bei der länge deines Interrupts durchaus Sinn. Auch 
Unterfunktionen machen sich immer gut in Extradateien. Die Dateien 
kannst du dann einfach über .include einbinden.
Wenn das passiert ist schau ich auch mal genauer über deinen Code.
Eine Sache ist mir dann doch noch aufgefallen: Du synchronisierst deine 
Mainloop mit dem Bildaufbau, oder? Gibts dafür einen besonderen Grund?

Gruß, Sebastian

Wenn ich dich richtig verstehe, dann meinst du mit synchronisieren, daß 
ich nur jeweils am Ende eines Bildes einen Befehl im Mainloop ausführe.
Der Grund dafür ist, daß ich anfangs das Auslesen der RTC und das 
Umwandeln der Zahlen in einer Aufgabe erledigen wollte und dann nichts 
mehr funktionierte, weil die Zeit im Mainloop viel zu kurz war. So habe 
ich den Umfang der Befehle schrittweise so weit reduziert, daß es paßt 
und darüberhinaus das Bildende genutzt, weil ich dann im Interrupt kaum 
etwas zu tun habe (die Leerbytes stehen ja schon im Speicher).

Die Aufteilung des Codes werde ich in Angriff nehmen.

Bruno

Hallo Sebastian,

so, der Code ist aufgeschlüsselt. Ich hoffe es entspricht deinen 
Vorstellungen.
Bei dieser Gelegenheit konnte ich auch noch etwas kürzen.

Bruno

Wenn du dir den Code ansiehst, möchte ich gleich noch eine Frage 
nachschieben.
Mir ist es bis jetzt noch nicht gelungen, die RTC unabhängig vom AT16 zu 
betreiben. Damit meine ich, daß beim Abschalten oder auch beim 
Einschalten des LCD's und AT16 die Uhr auf den zuletzt eingestellten 
Wert zurückgesetzt wird, obwohl die Uhr mit Batterie läuft. Eigentlich 
fängt das Problem schon damit an, daß ich das laufende Programm nicht 
mit einer Version ohne Start Routinen für die Uhr überschreiben kann, 
ohne daß die Zeit zurückgesetzt wird. Woran kann das liegen?

Bruno

@Chris

Als Display gehen nur Controllerlose. Der Witz dieses Projekts ist, den 
Controller in Software auf einem AVR zu realisieren.
Zum Beispiel kann man das hier verwenden:
http://www.pollin.de/shop/dt/ODI1OTc4OTk-/Bauelemente/Aktiv/Displays/LCD_Modul_NAN_YA_LTBE9S159J1K.html

Das von dir gelinkte hat einen integrierten Controller, funktioniert 
also nicht mit diesem projekt. Mit einem AVR kann man es trotzdem 
ansteuern.

@Bruno
Dass dein Display bei jedem Neustart mit der gleichen Uhrzeit anfängt 
sollte ja klar sein. Sowiet ich das jetzt gesehen habe setzt du ja bei 
jedem Start deines Controllers die Zeit auf den eingeflashten Wert.
Warum die Uhrzeit auf den gleichen Wert gestellt werden soll, wenn du 
eine neue Version ohne Zeit-stell-Software flasht kann ich mir grad auch 
nicht so richtig erklären. Ich denke doch mal, dass dein Board nicht 
über den Programmer mit Strom versorgt wird, oder?
Im Prinzip darfst du beim Systemstart die Zeit garnicht stellen. 
Stattdessen musst du etwas Code einfügen um Tasten abzufragen mit denen 
du die Zeit dann änderst. Genauere Vorschläge kann ich dir aber 
Frühestens Dienstag machen. Muss noch für ne Prüfung lernen - da hab ich 
leider nicht so viel Zeit übrig.

Sebastian

Natürlich geht deine Prüfung allemal vor. Super, daß du trotzdem schon 
wieder geantwortet hast.
Bei dem ins Forum kopierten Code ist es natürlich klar, daß die Uhrzeit 
gestellt wird. Bei meinen Tests habe ich aber immer das RTC_Write und 
meist auch das RTC_Read nur als Bemerkung stehen. Wo dann die alten 
Stellwerte herkommen ist mir ein Rätsel. Im ATMega können sie doch nicht 
mehr stehen,oder? Bleibt dann ja nur das Uhren-IC????
Das Ein- und Ausschalten hat sich inzwischen geklärt, u.z. lag es am 
fehlenden pull-up am Reset Pin.
Jetzt stellt er nur noch dann zurück, wenn ich eine neue Programmversion 
aufspiele (ohne Stellen der Uhr!).

Bruno

Ich habe die Zeit genutzt und den Code nochmals überarbeitet. Beim 
Bildaufbau ist alles unverändert. Das Auslesen der RTC erfolgt aber 
jetzt nach den 4 erten Pixelreihen im Abstand von 10 (das ist natürlich 
auch noch variabel) Bildern. Damit bleibt eventuell Zeit für weitere 
Aufgaben.

Bruno

Leider habe ich erst jetzt festgestellt, daß die Version 2 nur in der 
Simulation funktioniert, in der Praxis aber nicht. Es werden zwar die 
Uhrwerte für Sekunden und Minuten richtig angezeigt, die Stunden und 
anderen Daten bleiben aber stehen. Warum das so ist weiß ich nicht. 
Zumindest hat sich aber das Thema "Änderung der Uhrzeit beim Einspielen 
eines neuen Codes" damit erledigt.

Bruno

Hallo Bruno,

bin grad dabei deinen Code anzuschaun. Ich schreib jetzt einfach mal der 
Reihe nach auf, was mir auffällt, also vll. etwas durcheinander. Ich 
bitte das zu entschuldigen.

Deine Daten hast du über die .org Direktive platziert. Das macht man 
eigentlich nicht, weil es leicht zu Problemen führt. Genauso hast du die 
einzelnen Startadressen über feste Werte definiert. Konkret mein ich das 
hier:

1

.equ Font_St    =0x600*2

2

.set WTag_St    =0+Font_St

3

.equ den      =2400+Font_St

4

.equ Jahr_St    =2544+Font_St

5

.equ Dat_St      =4464+Font_St

6

.equ Punkt      =5044+Font_St

7

.set Mon_St      =5092+Font_St

8

.equ Zeit_St    =8452+Font_St

9

.equ Sek_St      =4464+Font_St

10

.equ Doppelpunkt  =12772+Font_St

und dann unten vor den Daten:

1

.org Font_St/2

Sinnvoller ist es, Labels zu verwenden. Du schreibst einfach vor den 
Daten des Doppelpunkts

1

Doppelpunkt:

Vor den Wochentagen kommt

1

WTag_St:

Mit diesen marken kannst du dann genauso arbeiten. Für außenstehende 
ists aber deutlich leichter zu lesen und es ist DEUTLICH weniger 
Fehleranfällig. Wenn sich deine Datenlänge mal ändert passt der 
Assembler die Zahlenwerte selbst an und du musst dich nicht selbst drum 
kümmern.

Genauso das hier

1

Januar:

2

.SET  Mon_St = 5092+Font_St

3

  ldi    ZL, LOW(Mon_St)

4

  ldi    ZH, HIGH(Mon_St)

ist schlechter Programmierstiel.
Setze vor die Daten des Januar ein Label. Also zum Beispiel

1

Januar_Data:

obiger Code wird dann zu

1

Januar:

2

  ldi ZL, LOW(Januar_Data*2)

3

  ldi ZH, HIGH(Januar_Data*2)

und schon gibts keine komischen Zahlen mehr, von denen keiner mehr weiß, 
woher sie kommen. Man kann auch nicht vergessen, sie bei Änderungen 
anzupassen. Das macht dann alles der Assembler.


Du solltest darauf achte, Code der logisch zusammengehört auch in eine 
Datei zu schreiben. Dass das jetzt noch nicht perfekt ist ist klar, du 
hast den Code ja grade erst aufgeteil. Aber z.B.

1

Warte:  

2

  in  temp, TWCR

3

  sbrs  temp, TWINT

4

  rjmp  Warte

5

  ret

sollte schon auch zum Rest des RTC-codes. Das Label könnte man auch 
eindeutiger wählen. Z.B. "WarteAufTWI:" oder "WarteAufRTC:". So schauts 
auf den ersten blick aus wie eine normale Delay-funktion, die einfach 
nur eine feste Zeit wartet. Wenn man den Code nachvollziehen will hilft 
soetwas doch sehr.



Soetwas

1

  cpi  C_Cnt, 4  ;bei C_Cnt =>4 ist das Lesen beendet

2

  ldi  RTC_Flag, 1

3

  brsh  Mainloop

sollte man auch vermeiden, wenns keinen Grund gibt. Der Vergleich sollte 
doch möglichst direkt vor dem Branch kommen. Hier ists egal, weil "ldi" 
das SREG nicht ändert, aber wenn mal noch ein Befehl eingefügt wird ists 
schnell passiert, dass man plötzlich nach einer ganz anderen Bedingungn 
brancht.

So, jetzt hab ich hunger und Simpsons haben schon angefangen. Um dir 
noch bischen Arbeit zu geben noch ein paar allgemeine Sachen ;)

Mir noch nicht ganz klar, warum du die Mainloop auf eine bestimmte 
stelle im Bildaufbau synchronisierst. Der Interrupt holt sich immer so 
viel Rechenzeit wie er braucht, ob die CPU in der Mainloop gerade was 
sinnvolles tut oder nur wartet ist dem egal. Natürlich schadets erstmal 
nicht, die Zeit nicht sooo häufig auszulesen, aber es macht halt Mehr 
Arbeit.
Du hast doch sowieso eine Routine, die die gesamten RTC-Daten ausliest. 
Wieso lässt du die nicht einfach endlos in der Mainloop aufrufen?

Zum Uhr stellen:
Erstmal brauchst du doch sowieso tasten. Die sind ja (laut sourcecode) 
noch garnicht vorhanden. Die Uhrzeit einmal einzuflashen und danach auf 
die RTC zu vertrauen kann ja auch keine Lösung sein. Selbst wenn du die 
Zeitumstellung mit einprogrammierst wird die Uhr irgendwann falsch gehn.
Dann schau dir mal an, wie Tasten entprellt werden. Das wird zum 
Beispiel hier beschrieben:
http://www.mikrocontroller.net/articles/Entprellung

Versuch das zu verstehen und überleg dir, wie du entsprechenden Code in 
dein Grundgerüst integrieren könntest. Das Uhr stellen sollte dann 
eigentlich trivial sein:
Bei Tastendruck (z.B. Stunden erhöhen) wird der Stundenwert im RAM 
erhöht und in den RTC-baustein geschrieben. Fertig.

Bei gelegenheit oder wenns ne neue Version gibt schau ich nochmal über 
den Code. Heut aber erstmal nicht mehr.

Viele Grüße,
Sebastian

Hallo Sebastian,

ich hoffe deine Prüfung war erfolgreich (-:

Herzlichen Dank für den umfangreichen Beitrag. Da habe ich erst mal was 
zu tun.

Das Tastenentprellen ist kein Problem. Damit habe ich mich schon 
mehrfach beschäftigt. Mein Problem war aber bisher, daß ich nicht wußte, 
wo ich eine Tastenabfrage mit Entprellung und Uhr nachstellen zeitlich 
noch unterbringen könnte. Ich hatte ja schon mit dem Auslesen der Uhr 
erhebliche Probleme. Inzwischen sehe ich da aber etwas Land.

Nun aber vielleicht auch noch für dich eine Denksportaufgabe:
Ich hatte ja geschrieben, daß die Version 2 meines Codes nur die 
Sekunden und Minuten ausliest, aber die übrigen Daten nicht. Inzwischen 
habe ich mit einer LED festgestellt, daß im Programmteil "_Wahl" die 
Sprungbefehle nicht befolgt werden, obwohl es in der Simulation keine 
Probleme gibt. D.h. Std_Read und die danach kommenden Routinen wurden 
gar nicht angesprungen. Versuchsweise habe ich dann statt der Variablen 
C_Cnt die ich in _Wahl genutzt habe, eine neu definierte Variable 
eingesetzt und siehe da es funktioniert. Warum das aber so ist, habe ich 
keine Ahnung????

Gruß
Bruno

Buuhaaaa! Da hättst jetzt besser nicht gefragt. Dann hätt ich folgendes 
nicht gefunden:

1

  add    ZL, C_Cnt

2

  clr    temp

3

  adc    ZH, temp

auch wenn clr das Carry-bit nicht ändert... Das ist einfach unterste 
Schublade. Das adc sollte wirklich auf jeden Fall direkt hinter dem 
zugehörigen add stehen. Du provozierst die Fehler sonst geradezu. Zur 
strafe 100 Zeilen Compilierten C-code disassemblieren! ;)

Die Antwort auf deine detektivaufgabe ist ziemlich simpel:
In der Simulation setzt du das TWINT-bit sobald es abgefragt wird. In 
Realität musst du da auf die RTC warten. In Echt dauert also die ganze 
Kommunikation mit der RTC viel länger. Bis die Sekunden ausgelesen sind 
hat der Interrupt schon vier mal ausgelöst. Dann ist C_cnt zu groß und 
die RTC wird erst wieder ausgelesen wenn das Bild vorne anfängt.

Wenn du schon das Auslesen mit der Anzeige synchronisieren willst, dann 
häng das auslesen wenigstens am Stück an. Sprich: Du wartest, bis das 
Bild wieder oben anfängt. Dann wird die Zeit am Stück komplett 
ausgelesen. Danach wird wieder auf Bildanfang gewaret. Der Interrupt 
holt sich schon genug Rechenzeit. Dem ist das egal.

Sebastian

Deine Erklärung klingt zwar logisch, aber sie provoziert eine Reihe 
anderer Fragen:
Ist deine Feststellung, daß der Interrupt schon 4 mal ausgelöst hat eine 
Vermutung, oder Berechnung? Wenn sie stimmt, dann verstehe ich nicht, 
daß das von dir vorgeschlagene Auslesen am Stück bei mir eben nicht 
funktioniert hat. Ich bin nämlich genau so gestartet und mußte 
feststellen, daß die Anzeige dann weg ist, oder wirres Zeug zeigt. Meine 
Vermutung war, eben weil während des Auslesens der Interrupt zuschlägt 
gibt es Probleme. Also habe ich das Auslesen so weit zerlegt, daß es 
keine Probleme mehr gab und war davon ausgegangen, daß die Zeit im 
Mainloop dann ausreicht. Das ist ja auch der Grund, warum ich das 
Auslesen mit dem Bildaufbau synchronisiert habe.

Bruno

Sebastian, deine Antwort auf meine "Detektivaufgabe" wie du geschrieben 
hast, hat mir sehr geholfen. Sie hat mich nämlich veranlaßt über das 
Problem nochmals nachzudenken und siehe da, es funktioniert nun auch mit 
dem Auslesen an einem Stück. Dadurch wird vieles einfacher.

Gruß
Bruno

Hallo Sebastian,

es ist so weit! Die Uhr läuft und Sekunden und Minuten lassen sich 
stellen. Mehr brauche ich nicht.

Vorgesehen ist ein Schalter zur Wahl zwischen Sekunden und Minuten, und 
ein Taster zum Stellen.

Gruß
Bruno

Hallo.

Hat schon jemand ne richtig funktionierende Schaltung für die 
Kontrastspannung für das TG322450 Display ? Weil wie schon weiter oben 
beschrieben, hab ich auch das Prob, das in Abhängigkeit zu der Anzahl 
der angezeigten Zeichen die Spannung hoch- bzw. runtergeregelt werden 
muss, sonst wirds ziemlich grau.

CU
Bernd

Hallo Bernd

Mein TG322450 arbeitet jetzt einwandfrei. Ich hatte auch meine 
Schwierigkeitn mit dem Kontrast. Die Kontrastschaltung ist im Anhang 
allerdings habe ich einen LM324 genommen und anstelle dem Transistor 
eine Zehnerdiode 5,6V eingesetzt. Die Kontrastspannung regle ich mit 
einem Poti das in der Step up Schaltung eingebaut ist damit die 
Ausgangsspannung stabil bleibt.

Vielen Dank an alle mitwirkende dieses Projekts.

MFG
Sebastian

Hallo,

durch euere tollen Projekte habe ich lust bekommen mich an die 
Ansteuerung des TG322450 Displays von Pollin heranzuwagen.
Sebastian wäre es dir möglich, den Schaltplan oder dein Projekt ins 
Forum zu stellen oder es mir per E-Mail zuzusenden? Mir fehlen die 
Informationen, wie ich die Versorgungsspannung von ca. 23V und die 
Teilspannungen erzeugen muss.

Wie wird bei diesem Display das Touchpennel ausgelesen? Ganz einfach mit 
zwei analogen Eingängen an einem Mikrokontroller für die X- und Y-Achse?

mfg Florian

Hallo. I am testing the textmodus controller in the spare time...
...but for now I obtain only vertical lines like a barcode...
I think it could be a wiring error. Did you ever experienced something 
like this?
Danke,
Alez

Bei meinen Versuchen, einen Controller für das Epson-Display 
(Beitrag "LCD Display 480x360, blau, bei Pollin") zu finden, bin ich hier 
gelandet.
Was ich hier sehe sieht echt super aus.

Die reine Textdarstellung reicht mir, aber wenn ich jetzt theoretisch 
den Controller aus dem Eingangsthread nachbauen würde,würde der dann 
funktionieren?
Oder wie muss man den modifizieren?

Ich finde die Idee, einen LCD-Controller fast nur mit einem MEGA 8 zu 
bauen (besonders da ich hier noch einen herumliegen habe), einfach 
genial, bin aber in ASM nicht besonders bewandert.
Kann mir da jemand helfen?

Auch mit der Anschlussbelegung habe ich so meine Probleme.
Ich habe zwar das Datenblatt meines LCD 
(http://www.mikrocontroller.net/attachment/3883/EG9006F_NS.pdf), finde 
aber die Bezeichnungen aus dem Schaltplan nicht wieder.
Wie schließe ich das an?

Mit freundlichen Grüßen,
Valentin Buck

Hallo zusammen,

(ich hoffe das liest noch jemand :-) )

ich habe das Projekt hier nachgebaut und muss sagen : SUPER ARBEIT! 
Großes Lob an alle, die mitgeholfen haben.

Jetzt hab ich aber ein kleines Problem. Ich sehe den Begrüßungstext 
problemlos, also Kontrastspannung u.s.w. alles OK denke ich.

ABER : Ich habe durchlaufende horizontale weiße Streifen auf dem 
Display. Sieht so ein bischen aus, als könnte man den Bildaufbau sehen ?

Ich benutze einen Mega8 und ein altes Optrex Display DMF50081. Kann es 
sein, dass der Mega8 zu langsam läuft ? Fuses sind OK, kann man das 
vieleicht irgendwie messen ? Mit meinem Frequenzzähler kann ich leider 
nicht am Quarz messen, dann bricht der Schwingkreis zusammen.

Danke schon mal

Markus