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);
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
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.
Mal ne Frage zum Röhre Dimmen: Ich hab für mein Display den Inverter von
Pollin (den blauen, bei dem die CCFL dabei ist). Kann ich da einfach die
Spannung am eingang verringern? Also z.B. 7V statt 12V? Kann ich auch
mit PWM rangehn, oder mag das der Inverter nicht?
Gruß, Sebastian
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
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
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.
@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
@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
Hallo,
ich habe so meine Probleme mit dem Nachbau dieses Projekts.
Folgendes Problem kriege ich nicht in den Griff:
Ich kann den Begrüßungstext von Benedikt nur sehen, wenn ich von der
Seite auf das Display schaue. Wenn man direkt drauf schaut, ist alles
Schwarz.
Ich mess zwischen GND und Vee -19V. Wenn ich die Spannung erhöhe auf
-23V sehen ich auch von der Seite nichts mehr vom Text.
Hat jemand eine Idee oder einen Tipp wo ich suchen sollte ?
Vielen Dank!
Das Backlight habe ich bisher noch nicht angeschlossen.
Ich habe das Nanya Display von Pollin mit dem "weißen" Hintergrund für
14,95.
Kann man ohne das Backlight nichts erkennen ?
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
Naja wenn ich von oben draufschaue ist es komplett dunkel, von der Seite
her sehe ich den Text.
Mit angeschlossenem Backlight sieht es nicht viel besser aus.
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.
Danke für die Hilfe bis dahin.
> 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
Hallo,
weiß jemand welches der momentan bei Pollin angebotenen Displays
"brauchbar" ist? D.h. kein Plastik-Flachbandkabel das einen exotischen
Stecker braucht, und möglichst ein Display das auch ohne
Hintergrundbeleuchtung ablesbar ist. Oder benötigen die alle ein CCFL?
Bei der Beschreibung im Katalog wird das leider nicht immer deutlich.
Vielen Dank
Randy
>> http://www.pollin.de/shop/dt/Mzk0OTc4OTk-/Baueleme...>> Das Kabel schaut nach so einem fürchterlichen>> unlötbaren Plastik-Falchband aus. Weiß das jemand genauer?>0,5mm Pitch.
Kannst du sagen ob man an die Lötstellen de Kabels auf der Platine ran
kommt?
Dann hätte man trotzdem eine Chanse doch ein Falchbandkabel anzulöten.
Ansonsten nehm ich das NAN YA, die CCFL Beleuchtung ist ja optional.
Randy
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.
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.
Eine zur Seite strahlende weiße LED kostet bei Reichelt 0,47 Euro...
http://www.reichelt.de/?;ARTICLE=65106
Damit wird die Neubestückung der Hintergrundbeleuchtung ähnlich teuer
wie das Display...
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.
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.
Hallo,
ich habe diese hier bestellt. Hoffe das sie passen( für das WD-H3224V)
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=390104822790
100Stk. Mit Preisvorschlag für 12.- zu bekommen.
Jetzt müssen nur noch die Displays ankommen.
Grüße aus Tirol.
Hallo,
ich habe von den LED zu viele ersteigert. Hätte jemand Interesse an 50
LED incl. Versand für 7,50.
Habe leider keinen Verwendungszweck dafür, außer für die Displays.
Mail an: aon.912847351@aon.at
Grüße aus Tirol.
@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.
Hallo,
in der letzten Zeit ist hier von zwei neuen Display's die Rede. Dazu
habe ich eine Frage kann man das TG322450 auch mit der Schaltung von
Benedikt ohne große Änderungen betreiben? Hierzu habe ich leider nichts
gefunden.
Gruß
Dieter
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.
Hallo,
könnte mal einer bitte ein Video machen und hochladen, wo man sieht wie
schnell das Display Arbeitet, wenn z.B. das ganze Display gelöscht wird?
Wäre echt super.
Danke.
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
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.
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
ich habe mal eine frage zum Grafik Display
ich habe an meine Display folgende Anschlüsse
1 VDD +5 V
2 GND
3 VCC +32 V
4 FLM
5 Display off
6 M
7 Load
8 CP
9 GND
10 D0
11 D1
12 D2
13 D3
14 GND
15 Beleuchtung +
16 Beleuchtung-
17-20 Touchscreen
nur weiß ich nicht so ganz wie ich es an meinen ATmega 32 anschließen
soll
ich würde es so machen
Anschlüsse 4;5;6;7;8;(17-20)Touchscreen wird noch nicht benutzt!
10 bis 13 ist klar
Kommen an den Mikrocontroller
ist das richtig?
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
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,
Ich habe mir letzte Woche ein WD-H3224V LCD bei pollin gekauft.
Kann mit dem Datenblatt von pollin aber nicht anfangen.
Ich möchte das display später mit einem PIC ansteuern.
Zur Zeit arbeite ich mit dem PIC 16F88 oder 18f2550.
Also suche ich ein kleines test programm
und eine Seite wo beschrieben wird wie ein solches Display ansteuert.
ein danke schon mal im vorraus
Gruß max
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
Hallo Meik,
Danke für den Tip.
Währe aber nett wenn du mir noch sagts wie du das display an den
PIC Angeschlossen hast. (Schaltplan)
Währe auch nett wen du mir die Schriftsatz-inc Datei hochladen würdest.
Danke
Gruß Max.
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.
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 Zusammen,
ist es möglich dieses tolle Projekt (Die LCD-Ansteuerung) in WINAVR
umzuwandeln, oder kann ich die Assembler-Datei auch irgendwie zu meinem
in c geschrieben dateien 'includen' ?
Hintergrundgedanke wäre das ich meine jetzige Anzeige 40x4 auf 40x20 zu
erweitern :)
Gruss,
Martin
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
Hi,
ein tolles Projekt :)
Inspiriert durch diese vielen Posts, stellt sich gerade nur die Frage,
welche
Display man/ich benutzen könnte?
Sehr sehr weit oben habe ich gelesen das der S1D13700 gehen soll...
Könnte Jemand ein paar Kompatible Kontroller listen damit man/ich ein
Display im Netz suchen kann, wäre supi :)
Bin eben durch zufall auf das hier gestossen, nur bin ich mir wegen der
Pinbelegung nicht ganz sicher.
http://www.cct.com.my/Products/Graphic%20Module/PG64-G2432X17.pdf
Gruss,
Chris
@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
Hallo,
Zuerst mal ich bin noch ziemlich schlecht im programmiern.
War also froh als ich gestern den LCD controller ans Laufen ans Laufen
gebracht habe.
Nun habe ich mal eine Frage:
Und zwar will ich auf meinem Display einen Text an zeigen.(250 worte auf
mehren Seiten)
hat schon mal Jemand so etwas gemacht oder kennt einer eine Lösung für
mein Problem?
(habe PIC 16F88/876 oder Atmega 168/32 zur verfügung)
Schon mal Danke für eure Mühe
Mit freundlichen Grüßen,
Chris
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,
super Projekt.
der lcd controller funktioniert super.
habe nur ein kleines problemm mit meinen programm wo mit ich den
controller ansteuern will.
und zwar seit dem ich text4 eingefügt (bis text 3 war alles super)habe
gibt das programm mir noch mist am TX raus
hat einer eine Idee wo der fehler ist habe da selbst nicht so viel
ahnung von. mein code ist im anhang.
Schon mal ein Dankeschön im vorraus
Gruß, Max
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,
ich war von der Idee begeistert einen atmega als Kontroller einzusetzen.
Hier ein Großer Dank an Benedikt!. Was mir nicht so gut gefallen hatte,
war das dieses Projekt viel in Assembler geschrieben wurde. Ich sträube
mich nicht gegen Assembler im Allgemeinen... Wenn man aber mit jedem
Prozessor auf 'Du' sein will, verliert man irgend wann den Überblick.
Die Konsequenz daraus: schreib das doch in C. Weil diese Forderung an
Benedikt eine unverschämtheit wäre (er hat hier schon genug
Peonierarbeit geleistet) habe ich dies übernommen ;-).
Gleich zum Nachteil: die Bildwiederholfrequenzen von Benedikt bekomme
ich nicht hin! No WAY!!! aber 45Hz sind auf den Displays durchaus noch
machbar.
Warum das ganze in C?
Ich wollte ein Display mit Touch-Screen das auch ein kleines Menüsystem
hat mit dem man sich die 'Knochenarbeit' sparen kann. Weil ein
Touchscreen angedacht war habe ich mich für das WD-H3224 von Pollin
entscheiden. Rausgekommen ist dabei eine Platine die alle nötigen
Aufgaben übernimmt. Mit einem Atmega168 oder Atmega328 ist auch noch ein
zweiter Zeichensatz für große darstellung mit drin und ein Menüsystem in
dem durch einfache definitionen Seiten und Funktionen definiert werden
können.
eine Seite kann dabei enthalten:
Radiobutton (im eeprom gespeichert)
Checkboxen (im eeprom gespeichert)
Slider Horizontal
Button (mit Funktion zum direkten Aufruf andere Seiten)
Text
Text editierbar und im eeprom abgelegt
Text (int) editierbar und im eeprom abgelegt
Um einen Text zu editieren wird eine 'Tastatur' eingeblendet und nach
der Eingabe wieder in die vorherige Seite gewechselt. Leider hat die
Ram-Beschränkung es nicht gestattet das über Layer abzuwickeln.
Der Touchscreen wird direkt durch den Atmega abgefragt. Wird während dem
Einschalten auf den Touchscreen gedrückt, wird die LCD-Anzeige mit
Zeichen vollgeschrieben und man kann durch das berühren (horizontal) den
Kontrast einstellen. Mit einen Druck auf den unteren Drittel des
Displays wird die Kontrasteinstellung verlassen.
Ich Packe hier den Code mit den Layoutdaten im Zip mit an, auch wenn der
Code noch nicht 'Salonfähig' ist; er Funktioniert aber!
Ach so.. jeder Druck eines Objektes der Seite ermöglicht das Aufrufen
einer Definierten Funktion. Damit kann man z.B. auf ein 'Auf/AB' mit
eigenen Funktionen reagieren.
ich hoffe das das regt an damit was anzufangen ;-)
bye woodym
Hallo,
Ich finde es klasse, wie lange dieses Thema konsequent verfolgt wird.
Ich bin Programmierer, aber Elektronik Laie und bin ueber den Post hier
gestolpert weil ich die CRT Roehre meines Kompakt Macs gegen ein LCD
austauschen moechte. Das Videosignal ist im Anhang dargestellt.
Nun lese ich hier "...aber 45Hz sind auf den Displays durchaus noch
machbar...." - das Macsignal hat einen von nur 15Mhz.
Mein Ihr, das ich die hier beschriebene Ansteuerung fuer mein Vorhaben
benutzen koennte?
hallo Christoph,
leider muß ich dich enttäuschen. Zum einen haben die 45 Hz nichts mit
deinen 15MHz zu tun (die 45Hz sind die Bildwiederholfrequenz die 15 MHz
ist die Videofrequenz) und zum anderen ist dieser Kontroller auch nicht
geeignet ein Videosignal darzustellen.
45Hz als Bildwiederholfrequenz scheint nicht viel zu sein (sieht man
flimmern?). Bedingt durch die Art der LCD's die hier zum Einsatz kommen
sind aber die LCD-Kristalle sehr träge. D.h. werden die Kristalle einmal
ausgerichtet (schwarz oder weiß durch die Polarisationsfilter) braucht
es eine nicht unerhebliche Zeit bis diese umgekehrt ausgerichtet werden
können. Darurch ist auch bei einer geringen Bildwiederholfrequenz kein
Flimmern zu sehen.
Man darf nicht den Fehler machen dies mit heutigen LCD's (TFT) zu
vergleichen. Damit diese ausgerichtet bleiben ist für jeden Bildpunkt
ein eigener Transistor zuständig und eine andere Technologie beim
LCD-Aufbau kann verwendet werden.
Das was du suchst ist ein LCD mit einem Video-Eingang. Ob in Farbe oder
SW kann ich aus den Unterlagen nicht erkennen. Das einfachste und
unkomplizierteste dürfte in deinem Fall ein moderner LCD-Bildschirm sein
der ein Videoeingang hat. Aber vorher vergleichen ob die horizontal,
vertikale und video-Frequenz unterstützt wird. Das ganze läßt sich auch
basteln... aber glaube mir aus eigener Erfahrung... ein fertiger
Bildschirm ist billiger und nervenschonender. Investiere die ersparte
Zeit dann lieber in ein schönes Softwareprojekt ;-).
Übringens Softwareprojekt.... wie wäre es für das Menüsystem ein
Konfigurationssoftware zu machen... grafisch schibt man sich die Seiten
zusammen und bekommt dann als ergebnis eine Definitionsdatei die direkt
in ein Projekt eingebunden werden kann.
bye woodym
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
Hi,
hier die Fuses. Mittlerweile habe ich die Streifen ohne flackern auf dem
Bild. Das habe ich durch anpassen der Quarzfrequenz im Source
hinbekommen. Ein Bild dazu hab ich angehangen. Vieleicht hast Du eine
Idee dazu.
Gruß Markus
Hm. Die Fuses sollen passen. Wie sieht dein Aufbau aus? Kerkos an den
Quarz-Pins nach GND? Wert? (Ich nehm immer 22pF und hatte nie Probleme)
Vielleicht zu lange Beine am Quarz und den Kerkos? Steckbrettaufbau oder
so? Anderen Quarz getestet?
Hi,
erst mal danke für Deine Mühe, bin grade nochmanl alles am checken.
Platine ist selbst geätzt, Layout sollte in Ordnung sein, am Quarz sind
22pF. Ich habe langsam das Gefühl, dass es doch nicht die Frequenz ist,
sondern irgendwie Daten fehlen, die zum Display gehen. Das Ganze ist
doch schon SEHR regelmäßig, die Abstände sind gleich. Das macht mich ein
wenig stutzig.
Gruß Markus
Soooo,
Problem gelöst !!!!
Meine Versorgungsspannung beträgt gemessene 5,1V. Ich hatte die
Brownout-Detection an.
Wenn ich die Brown-out-Detection ausschalte, dann läuft der Controller
einwandfrei.
Hier noch ein Bild von den aktuellen Fuses.
Danke nochmal für die Tipps !
Gruß Markus
o0 Das bedeutet, dass deine Spannung zeitweise unter 4V faellt und
wahrscheinlich auch hoeher als 5,15 V ist in den Peaks. Ueberpruef mal
deine Spannungsversorgung (Oszilloskop), irgendwas laeuft da schief!