Hallo, hier ein einfaches Demo Program für Atmel AVR zur BitMap Ausgabe auf das Display des Siemens S65/M65/CX65/SK65 Mobiltelefon. Dieses Display gibt es bei diversen Quellen recht günstig als Ersatzteil zu kaufen. Preis derzeit z.B. 10EUR beim Internet Versteigerer zum sofort kaufen. Die weitergehende der Software und Hardware findet sich hier: http://www.superkranz.de/christian/S65_Display/DisplayIndex.html Dort gibt es auch die Quelltexte für die angepasste glcd die ursprünglich für das Nokia 6100 Display entwickelt wurde. http://www.mikrocontroller.net/forum/read-4-74872.html#new Have Fun Christian
Ich hab mir auch mal eins bei ebay für 10EUR geordert, hab leider zu spät gemerkt das bei diesen Displays der Artikelzustand als gebraucht beschrieben ist... Naja ich bin gespannt für den Preis kann man ja nicht sehr viel falsch machen :)
Hallo Christian, Du hast in Deiner Webseite http://www.superkranz.de/christian/S65_Display/DisplayIndex.html die Tag-Klammern zu den verlinkten Seiten etwas unglücklich gesetzt. Der IE6 verweigert deshalb die Links. Ansonsten sehr gute Arbeit! Gruß Joachim
oh ja, habe die schliessende Klammer(n) vergessen... Ich hab's repariert. Leider habe ich zuhause keinen IE und kann das nicht testen... Mozilla hat das nicht gestört. Grüße Christian
Und ich dachte die ganze Zeit, dass die Seite noch nicht fertig ist. Der hier gepostete Source-Code ist für mich nur schwer zu verstehen (C mit ASM kann ich noch nicht so gut) Durch deine Homepage ist mir der Ablauf der Display-Ansteuerung endlich klar geworden. Andy
Hallo Christian, in den Startsequenzen Init1 und Init2 sind pro Reihe eine unterschiedliche Anzahl Kommandos enthalten. Hat dies etwas zu bedeuten, muss ich außer den 7 ms zwischen Init1 und Init2 noch andere Zeitintervalle einhalten? Wie hoch kann die minimale bzw. maximale Taktfrequenz der seriellen Ansteuerung sein? MartinK
Hallo, die Aufteilung in verschiedene Reihen habe ich gemacht, weil ich vermute dass jede Zeile ein Command ist. Die Software (lcd.asm) schickt die Sequenzen einfach byte für byte als grosses Packet. Ich benutze 8MHz SPI clock, dürfte kein Problem sein, da das Display im Original mit 13MHz benutzt wird. Es funktioniert aber auch ohne double clock bit und mit 1/16 Teiler. Grüße Christian
Hi, ist es auch möglich mit bascom dieses LCD anzusteuern ? Besser gefragt, hat dies schon jemand gemacht ? ( Wird schon gehen, nur wie ? ) mfg Kay
Naja, die Ansteuerung hat im wesentlichen ja nichts mit der Ansteuerung zu tun. Bascom wird nur um einiges mehr Code produzieren, sollte aber trotzdem funktionieren.
So, ehe unser Oberguru Jens Dinspel wieder aus der Bahn geworfen wird*, hier eine korrigierte Fassung meines obigen Postings: Naja, die Ansteuerung hat im wesentlichen ja nichts mit der Programmiersprache zu tun. Bascom wird nur um einiges mehr Code produzieren, sollte aber trotzdem funktionieren. *) http://www.mikrocontroller.net/forum/read-5-244046.html#244746
Hy Leute, Hab mir vorhin mal die zeit genommen und das Zeug was auf der HP von Christian Kranz (ChristianK) war in ein PDF gepackt. Sollten irgendwelche Fehler oder Sonstiges sein, bitte sofort mir sagen. Gruß Lightning
Hat jezt nix mitm Disp zu tun, aber ich wllte euch nur mal drauf hinweisen, dass "actually" im Englischen icht aktuell sondern tasachlich bedeutet. Ihr wollt in dem Satz "Actually there are known three different types of the display." wohl eher "Currently" nehmen :) Gruss Tobias
@Christian: bei der Addressierung des DisplayRAMs gibt es wirklich nur diese 2 Modis ? Das bedeutet das dieses LCD mit meinen Font Routinen der GLCD nur Sinn macht wenn es senkrecht benutzt wird, mit Koordinate (0,0) Links Oben. Das ist Schade da es gerade waagerecht eingebaut interessant wäre. Hast du bei den Commandbytes mal alle Bits durchgetestet ? Ich könnte mir vorstellen das es ein Bit gibt das die Ansteuerung der Koordinaten spiegelt. In diesem Moment wären alle 4 Richtungen wieder möglich. Das Problem mit meinen Font Routinen ist, das sie durch die Komprimierung und dementsprechende Live-Dekomprimierung während der Anzeige eines Zeichens, nur in Richtung der Y Koordinate bottomup und der X Koordinate bottomup gezeichnet werden können. Eine einfache Art&Weise dieses Verhalten umzuprogrammiern wird es leider nicht möglich sein. Die Fonts müssten in ihrer Pixelreihenfolge schon während der Komprimierung umprogrammiert werden. Was natürlich zu einer Inkompatibilität der verschiedenen Fonts untereinander führt. Funktionieren denn meine Linien Routinen ? Ich erinnere mich dunkel daran das auch die Linienfunktionen von der spez. Memory Addressierungen Gebrauch machen. Kann man den DisplayRAM des LCDs auch wieder auslesen ? Ansonsten super Arbeit. Gruß Hagen
@ Tobias Schneider Hallo, Gut das du das mit demActually bemerkt hast. Ih habe bereits ein neues PDF gemacht wo der Fehler korrigiert ist. Ich warte aber noch mit dem Upload, vieleicht tauchen noch mehr solche Fehler auf. Gruß Lightning
@Hagen, ich habe einige (allerdings wohl nicht alle) Bit-Kombinationen nach dem 0x05xx Command getestet. Zumindest alle Einzelbits und FF. Ausser bei der 04 hat sich nichts getan... (habe natürlich auch 0x04xx und 0x03xx getestet ohne Wirkung) Ich habe mir da aber nicht sehr viel Zeit genommen, vielleicht ist noch was versteckt.... Die Linien habe ich in alle 4-Richtungen diagonal getestet, waren o.k. Leider kann man das Display Memory nicht zurücklesen. Macht im Mobile Phone Betrieb auch keinen Sinn, da der RAM-Inhalt regelmässig (etwa jede Sekunde) vom µC aufgefrischt wird um Pixelfehler zu vermeiden. Wie man mit der GLCD weitermacht weiss ich auch noch nicht. Mir reicht im Moment erst mal der 90-Grad Betrieb. Vermutlich könnte man sie schon einfach anpassen, wenn man etwas Performance und RAM opfert.... Grüße Christian
Im Notfall könnte man die zu zeichnenden Zeichen ins RAM des uC dekomprimieren und von dort aus entsprechend gedreht ans Display senden. Bei einer 2 Farb Font bräuchte man für ein 32x32 Pixel großes Zeichen gerade einmal 128 Byte.
@Hubertus du bist sowas von armsehlig... schade, dass solche, wie du meinen sie muessen leuter persoehnlich angreifen und somit solche foren, wie hier in den dreck ziehen nunja du bist der beste mach weiter so..
hi, nochmal zu bascom ... hat jemand vor, das ganze auch auf bascom zu portieren, oder bleibt ihr lieber bei C ? mfg Kay
In Bascom nicht aber in Assembler. Gruß Lightning
@Christian: >> Die Linien habe ich in alle 4-Richtungen diagonal getestet, >> waren o.k. Schlechter Test ;) versuche mal 4 Linien mit den Koordinaten 40,0 -> 60,176 60,0 -> 40,176 60,176 -> 40,0 40,176 -> 60,0 Deren Steigung ist < 1 in Y Richtung Dann noch 0,78->128,98 0,98->128,78 128,98->0,78 128,78->0,98 Deren Steigung ist ebenfalls < 1 in X Richtung Bei den Fonts gäbe es noch die Möglichkeit ohne Komprimierung zu arbeiten. Man kann dann die Speicherzugruiffe auf die Fontdaten entsprechend umbauen. Allerdigs hats eben mehrere Nachteile 1.) monochrome große Fonts werden normalerweise auf 1/4'tel oder sogar 1/8'tel der Größe komprimiert. Bei 16Kb also nur 2-4Kb an real benötigtem Speicher, das ist ne Menge Holz. 2.) Der Code muß 4 Orientierungen separat umsetzen, für jede Orientierung eine eigene Schleife, ergo mehr Programcode 3.) Man kann nun nicht mehr linear sequientiell die Fontdaten aus dem Speicher laden. Das ist im ersten Moment für einen Laien kein größeres Problem. Aber ich habe exakt auf dieses spezielle Feature Acht gegeben damit man nämlich die Fontdaten in externen seriellen Speicherbausteinen, oder SD/MMC Karten ablegen kann. Bisher gibt man den Startadresse an dem ein Font beginnt vor. Beim zeichnen eines Zeichens wird immer linear sequientiell ab dieser Addresse die Daten aus dem Speicher gelesen. Darauf müsste man dann verzichten. 4.) die bisherige innerste Loop der Fontroutinen ist so ausgelegt das sie während 1 Byte übers HW-SPI im Hintergrund gesendet werden mit maximal 16 Takten die nächsten Koordinaten berechnet und die Daten dekomprimieren kann. Es entsteht also eine enorm hohe Performance der Font-Routinen im Vergleich zum Datendurchsatz. Wie Ape schon oben vorgerechnet hat: ein String mit 32 zeichen a 16x16 Pixeln und 16Bit Farben muß an das Display 16Kb übertragen. Nur 32 Zeichen !! Bei komprimierten Fonts ist aber die innerste Schleife samt Clipping meistens schneller fertig mit den neuen Daten als das das HW-SPI seine 8 Bits rausschicken kann. Man erreicht also theoretisch Clock/2 MBit Durchsatz. Gruß Hagen
wäre es denn möglich, einen avr zu nehmen, der in Assembler oder C das display ansteuert und die "daten" über die serielle bekommt ? mein problem ist, das ich kein C und kein assembler kann. würde halt gern mit bascom programmieren.
Hallo Kay, ich werde mich nicht mit BASCOM beschäftigen. Allerdings dürfte - wenn du dich ein wenig mit BASCOM auskennst - die Display Ansteuerung nicht so schwer sein. nach der Homepage kann Bascom: a) SPI Interface ansprechen b) externe C/Assembler Routinen aufrufen D.h. für eigene Grafik-Routinen reicht a), wenn du die glcd benutzen willst musst du dich mit b) beschäftigen... Grüße Christian
hab im oberen post den halben text vergessen. ich habe mir jetzt so ein display bestellt. ich warte bis das display hier ist und werde dann mal schauen wie weit ich komme. Will einfache Texte an einer bestimmten position platzieren. und grafiken anzeigen lassen. vielleicht bekomme ich das mit bascom ja hin. wenn nicht, dann halt nicht. probieren kann man es ja mal. mfg Kay
Ich habe Vorgestern mein Display (blaue Platine) erhalten. Doch leider gelingt mir die Ansteuerung nicht. Zuerst habe ich es mit Bascom versucht, da ich mit Basic schon die Ansteuerungsroutinen für die Nokia-Displays 3510i und 6100 geschrieben habe. Prinzipieller Ablauf (verkürzt wiedergegeben): Mega128, 2.8 Volt, 4 MHz-Resonator, Port C Reset (low), dann Pegel auf high CS auf low, RS high (Commands) Datenpin high/low setzen, mit CLK auf high wird Zustand eingelesen die Wartezeiten zwischen Init1 und Init2 habe ich variiert (0-40 ms) RS low für Daten Leider tat sich nichts Dann habe ich das Beispielprogramm simple_display3 genommen, das Display an Port B angeschlossen, und im ASM-File Xtal auf 4 MHz gesetzt, und make all vom AVR-GCC gestartet. Dann das Gleiche nochmal mit dem internen kallibrierten 1 MHz Oszillator ausprobiert. Leider zeigte das Display keine Reaktion. Jetzt bleiben noch 3 Möglichkeiten übrig: Display ist defekt Display is inkompatibel ich habe irgendwas falsch gemacht (nur was?) Vielleicht weiss einer Rat. MartinK
Hallo Martin, grundsätzlich hört sich das o.k. an. Läuft der atmega mit 2.8V zuverlässig? Drei Dinge: a) mit so langsamen Takt habe ich das noch nicht probiert, der langsamste waren 8MHz mit einem ATmega32 b) Für dein BASCOM: Ich glaube, das zwischen den Commands das CS toggeln muss. c) Blaue Platine? Bisher kenne ich nur die grüne und zwei verschiedene braune.... Vorschläge: -> Überprüfe die Verdrahtung mit den #defines in simple_display3 -> kannst du dir die Port Signale anschauen und überprüfen? Wenn ja check die Verzögerung zwischen INIT1 und INIT2 mit dem Osci. sowie die Daten -> Überprüfe deinen Display Anschluss. Ich kann ESD Schutzdioden zwischen den Steuersignalen und Supply/GND messen (ca. 1V mit meinem Diodentester). Damit kannst du testen ob der Kontakt da ist. -> Nehme Spannungsteiler, 5V und 16MHz
@MartinK Kannst du bitte mal n Foto von dem Display mit der blauen Platine Posten ?? (Vorder + Rückseite) Mfg. Lightning
@Lightning Tut mir Leid, aber momentan habe ich keine Digitalkamera. Das Display habe ich bei Ebay ersteigert (Cellow), sieht fast genauso aus wie das linke Display auf Christians Homepage. @Christian Ich habe den Mega128L, kann max 8 MHz, läuft aber bei 2.8 Volt zuverlässig. Die Schutzdioden habe ich auch messen können mit Ausnahme von Pin 1 (RS), bei dem ich absolut nichts messen kann, vielleicht liegt hier der Fehler. MartinK
Das ist zumindest ein Fehler. Ich kann auch bei RS die Dioden messen.
@Christian Die Signalleitung von Pin 1 (RS) ist definitiv irgendwo unterbrochen. Im Übrigen gleicht mein Display deinem Grünen fast 100%ig, nur der Lötstopplack meiner Platine ist blau. Sogar die Platinenaufdrucke sind gleich. Ich habe bei meinem Display den weissen unteren Platikrahmen abmontiert. Dann habe ich kurz vor der Bending-Area, also dort, wo die Leiterfolie auf die Platine geklebt ist, mit einem scharfen Cutter den Lötstopplack von der Platine gekratzt. Da die Leiterbahnen an dieser Stelle sehr klein und eng beianander liegen (etwa 60 auf 2,2 cm), habe ich mit einem akustischen Durchgangsprüfer die Signale zwischen Leiterbahnen und Anschlusspins geprüft. Alle Pins mit Ausnahme von RS gaben einen Signalton. Der einzige Punkt, an dem ich noch ein Signal erhalte, ist der rechte Lötpunkt von R4 (oder A4). Von da an verliere ich das Signal. Und bei einer 4-Layer (oder noch mehr) Platine kann ich nichts mehr machen. Vielleicht könntest du mir helfen. Von Reset und CS weiss ich, dass das Signal bei einem Kondensator oder Widerstand wieder auftaucht. (CLK taucht erst an der Bending-Area wieder auf). Vielleicht gibt es eine direkte Verbindung zwischen RS und irgendeinem Baustein oder Lötpunkt. Dann könnte ich einfach ein Kabel daran löten. Unter dem weissen Abdeckrahmen sind keine Bausteine. MartinK
Martin, habe gerade mein grünes Display untersucht: a) ich kann RS nirgends, ausser an R4 finden b) ich messe bei RS auch keine Schutzdiode!!!! Das ist ein Unterschied zwischen den grünen/blauen Display und den braunen... Grüße Christian
@ChristianK: > Das ist ein Unterschied > zwischen den grünen/blauen Display und den braunen... Das heißt jetzt was genau? Ich werde wohl morgen auch ein blaues erhalten (Cellow, ebay). Laut dem PDF sollte es 3 Versionen geben (wohl blau, braun und grün). Sind jetzt alle gleich oder nicht? @MartinK: Wenn meins morgen ankommt werde ich mich mal am WE dran begeben. Ich meld mich dann mit den Ergebnissen. Grüße, André
Ach noch was. In der Artikelbeschreibung von Cellow ist aber ein ROTES mit brauner(?) Folie abgebildet. Laut PDF: Grün=Braun Laut ChristianK: Grün=Blau!=Braun Hilfe! Farbenwahn! Grüße, André
@Christian Hast du das grüne Display mal ausprobiert? @André Ja, ich habe bei meiner Bestellung bei Cellow auch ein Display mit einer rötlichen Platine gesehen. Streng genommen ist meine Platine nicht rein blau, sondern hat einen kleinen Grünstich, also dunkel-Türkis MartinK
Hm. Wenn meins morgen da ist, up ich mal 'nen Scan. Vielleicht sollte das PDF dann um Eigenarten der verschiedenen Displaytypen ergänzt werden. AK
Zum Aufklären des Farbwirrwars: Also ich besitze: a) ein braunes wie auf Web-Page abgebildet b) ein braunes mit anderer Platine (kein Foto, da eingebaut ) c) ein grünes wie auf Web-Page abgebildet Diese drei verhalten sich gleich. Martin hat jetzt noch ein türkis-farbenes das aber wie mein grünes aussieht... und offensichtlich die gleiche Eigenschaft hat dass keine Schutzstruktur am RS pin zu messen ist.
Hallo, ich habe die Software (WEB und hier) nocheinmal upgedated. Grund ist, dass das Display nicht immer zuverlässig gestartet ist. Es konnte passieren, dass mehere Reset's nötig waren um das Display zu starten. Wenn es dann einmal lief, lief es ohne Probleme. Zuerst habe ich das auf meine unvollkommene Reset-Beschaltung geschoben, konnte heute aber nachweisen, dass es nicht der µC ist der die Probleme macht. Also habe ich die init1 sequence in zwei Sequenzen aufgeteilt (wie beim S65 gemessen) und eine Wartezeit von 68ms dazwischen eingebaut. Bisher hat damit das Display problemlos funktioniert. Grüße Christian P.S: Diesmal habe ich die HEX-Files im Zip gelassen. Diese HEX Files habe ich bei mir getestet und sie funktionieren.
Hy Leute, Wenn ihr alle Arten von Displays untersucht habt, schickt mir bitte Infos zu (oder hier Posten). Dann werd ich in mein PDF da noch ne extra Rubrik für die verschiedenen Displays und deren Tücken, Farben,... etc. reinbasteln. Gruß Lightning
Da stehen doch auch Typbezeichnungen auf der Rückseite drauf, z.B. LPH8836 oder LS020... Gibt es denn innerhalb eines Typs verschiedene Leiterplattenfarben? Gruß Roland
hi, das display braucht ja eine Versorgungsspannung von 2,9V. macht es dem display was aus, wenn es 3,3 V sind ? habe nämlich noch einen LM3574 den ich gerne benutzen würde. nur will ich auch nicht mein Display schrotten. mfg Kay
Ob 3.3V funktionieren weiss ich nicht, ich würde da aber erstmal keine Experimente eingehen. Letztendlich hängt die ganze Spannungserzeugung für das Glas daran.
dann muss ich wohl das ganze von 3,3 auf 2,9 V bringen. müsste doch mit nem widerstand machbar sein oder ?
@Christian, auf den Fotos auf Deiner Homepage ist ja auch ein LPH8836 zu erkennen. Hast Du Deine Software auch mit dem LPH8836 getestet oder nur mit dem anderen LS020-Typ? Bei meinem LPH8836-3 funktioniert außer der LED-Beleuchtung leider noch nichts. Verdrahtung habe ich schon mehrfach kontrolliert, am Power-Up-Timing habe ich auch schon herumprobiert, leider ohne Erfolg. Was mich etwas wundert: weshalb geht bei Dir das Power-Up-Timing schief, wenn die Wartezeit zu groß ist? Eine Mindestzeit hätte ich erwartet, aber eine Maximalzeit...? Michael
Angehängte Dateien:
-
LCD_Back.jpg
44 KB
Hi, mein Cellow-LCD ist da. Grün (also kein Türkis wie bei MartinK). Allerdings auch keine Typenbezeichnung drauf ;-( Hoffe es ist ein LPH8836 (DAS sollte ja gehen). Layout paßt schonmal. Grüße, AK
Meins ist auch da, ein braunes mit LS020..... über eb** müsste auch passen
@André Cellow scheint verschiedene Chargen zu verkaufen. Meins sieht zwar genauso aus (außer der Farbe) Als Herstelldatum auf dem weißen Kunststoff steht bei mir 4 04, also 3 Monate jünger als deines. Die Nummer auf dem weißem Aufklebr ist: 3738.1 Nummer auf der Platine (neben den Anschlüssen): 3320 010 2051.2 Mein Display läuft leider immer noch nicht. Es wäre schön, wenn du bei erfolgreicher Ansteuerung dein Ergebnis mal posten würdest. MartinK
@MartinK Ergebnisse kommen (wohl frühestens am WE). Wenn Deins jünger ist, geh ich mal davon aus daß nur der Lack-Hersteller gewechselt wurde. Deine Chancen (und meine) stehen wohl gut ;-) Grüße, AK
Kann mir jemand die exakten Einbau-Masse des Displays nennen ? Danke im Voraus an alle Hilfsbereiten. Daz
Hallo, ich benutze derzeit ausschliesslich das Display, das auf der Web-Seite rechts neben dem grünen zu sehen ist. (braun LSxxx) Das grüne hatte ich nur einmal ganz kurz vor einiger Zeit im Betrieb. Nur um zu testen ob es funktioniert. (damals hatte ich die Displays übrigens parallel geschaltet, - beide zeigen dann das gleiche Bild...) Die Ansteuersoftware hat sich danach noch geändert. Im wesentlichen "Weg-Optimierungen" von "überflüssigen" CS toggeln, Änderungen im Timing etc. Es besteht daher eine gewisse Wahrscheinlichkeit, dass das grüne Display mit der derzeitigen Ansteuerung nicht (mehr) funktioniert. Nach dem Motto was nicht getestet ist funktioniert meist auch nicht. Ich werde - frühestens am Wochenende - das grüne mal wieder anschliessen. Dann kann ich näheres sagen. Zu den Kodes: LSxxxxxx Hersteller vmtl. Epson? L2F50126 Hersteller vmtl. Epson LPHxxxxx Hersteller vmtl. Philips? Ihr könnt aber auch selber experimentieren. Die Timing's der Original-Ansteuerung sind ja verfügbar. Im worst case muss man die einfach exakt nachbauen...
ich habe jetzt über einen Spannungsteiler mit 2 Widerständen eine Spannung von 3,034 V. Das müsste doch gehen für die Spannungsversorgung vom Display oder ? Noch ne Frage: Wieviel mA zieht das Display denn ? mfg Kay
So hab jetzt mein Display auch endlich mal bekommen, braune Leiterplatte LSxxx. 2,9V Versorgung über Spannungsregler, Level-Shifting über Widerstände. Die Lib hat auf Anhieb funktioniert. Vielen Dank nochma :) Kleine Frage am Rande: Warum ist der zweite Versorgungspin des Display 1V8 benannt, obwohl er auch an den 2,9V hängt? @Kay: Mit Spannungsteiler-Konstruktionen für die Versorgungsspannung wär ich vorsichtig, da eine solche Versorgung per Definition einen sehr hohen Innenwiderstand hat und daher die Spannung bei Lastwechseln stark schwankt (Es sei denn du willst mit dem Spannungsteiler auch gleich heizen). Hab noch nich gemessen wieviel das Display so aufnimmt und ob sich die Stromaufnahme stark ändert, aber ein Spannungsregler ist doch die bessere Wahl.
hi ape, welchen Spannungsteiler benutzt du denn für das display ? hast du das display schon ans laufen gebracht ? mfg Kay
mhh ich meine natürlich Spannungsregler ...
@ape Woher hast du das Display? Hast du 16 MHz, oder funktioniert die Ansteuerung auch bei niedrigeren Taktfrequenzen? MartinK
Ich hab das ganze im Moment auf dem Steckbrett laufen und benutze einen LM314 (einstellbarer Spg.regler), der is zwar etwas überdimensioniert, aber das macht ja nichts :) Ich hatte zunächst die Lib für 8MHz übersetzt und den Mega128 mit internen 8MHz laufen, das hat wunderbar funktioniert. Als nächstes habe ich die Lib für 16MHz kompiliert und einen 16MHz Quarz verwendet, damit geht das Display aber nicht an. Wenn ich aber erstmal mit einem langsamen Takt starte und dann auf 16MHz umstelle (Jumper auf dem STk500 von Board-Takt auf Quarz-Takt umstecke) läuft das Display auch problemlos. Erscheint mir merkwürdig, ich muss das nochmal genauer untersuchen.
@ape Mit Lib meinst du simple_display3 ? Gut, dass das bei dir läuft. Mit meinem 8 MHz Atmega128L hat das nicht funktioniert. Vielleicht habe ich beim Compilieren etwas falsch gemacht. Kannst du mir das fertige Hex-File für 8 MHz an meine E-Mail-Adresse martin-k@x-mail.net schicken oder hier posten? Wenn mein Display dann immer noch nicht funktioniert, dann ist es entweder kaputt oder inkompatibel. Mein Mega128L funktioniert einwandfrei, das habe ich überprüft. MartinK
@Fabian Super, endlich mal ein Erfolg :-) Die 1V8 Spannung heisst so, weil im Original hier 1.8V anliegen. Das ist die von Siemens benutzte Interface-Spannung. Bei allen mir bekannten Display Controllern ist diese allerdings sehr weit spezifiziert üblicherweise immer bis hin zur Display-Spannung. Darum habe ich sie auch an die 2.8V gehangen. 16MHz Problem: Hast du die neue Version mit den 3-Init Sequenzen benutzt? (die die aktuell unter download steht) Die läuft bei mir mit 16-MHz wirklich völlig problemlos. Allerdings ist das Timing am SPI-Bus mit den passiven Level-Shiftern bei 8MHz SPI-Clock schon nicht mehr optimal. Ich überlege schon, ob ich für das spätere Gerät nicht aktive Level-Shifter verwenden soll. Grüße Christian
Angehängte Dateien:
-
s65lcd.jpg
84 KB
Hallo ich hab jetzt nochmal die neueste Lib von deienr Seite runtergeladen aber das hat keine Änderung gebracht. Vielleicht kannst du in einer nächsten Version den SPI Clock fürs Init etwas runtersetzen und erst danach voll aufdrehen. Ich denke spätestens wenn ich ein Gerät mit dem Display baue, werde ich aktive Level-Shifter einsetzen, aber so fürs steckbrett wars erstmal die einfachste und schnellste Lösung :) Im Anhang mal nochn Bild, kommt auf dem Foto nicht gut rüber, aber ich bin positiv überrascht von der Bildqualität des LCDs, ist wirklich um Längen besser als das Nokia 6100... @Martin: Nein das simple_display hab ich nicht ausprobiert sondern gleich die portierte glcd Library verwendet. Ich hab dir mal das Hex File per Mail geschickt.
@ape Danke für das File. Leider funktioniert das Display immer noch nicht. Ich habe extra noch mal alle Kabel neu angelötet. Ich schätze, ich werde mir ein braunes Display bestellen. MartinK
Schaut euch mal dieses Angebot bei Ebay an: http://cgi.ebay.de/Original-Siemens-M65-M-65-Farb-LCD-DISPLAY-NEU_W0QQitemZ6444305427QQcategoryZ40578QQcmdZViewItem Laut Anbieter ist ein M65-Display nicht mit S65 kompatibel, während andere Händler keinen Unterschied machen. Vielleicht ist mein Display nur M65 kompatibel. MartinK
Für was genötigt man diese Levelshifter ? ich dachte, es reicht, eine 2,9V Spannung und die 10,4 V für die Hintergrundbeleuchtung ? mfg Kay
@Kay: Nix für ungut, aber du weißt schon was du tust? Die Level-Shifter brauch man um die Pegel auf der Schnittstelle zwischen Controller und Display anzupassen. Schließlich läuft der AVR bei 2,9V nicht mehr mit voller Taktrate (wenn man Glück hat schon, aber man ist dann schon sher weit außerhlab der Specs...). Die einfach-Lösung besteht darin mit Spannungsteilern die Signal-pegel runterzuteilen. Steht glaub ich auch irgendwo weiter oben im Thread. Jedenfalls sind aber durch die relativ hohen Widerstände die Signale bei hohen Frequenzen nicht mehr sehr schön. Ein aktiver Level-Shifter schafft da Abhilfe. @all: Für einen Einsatz im Querformat ist das Display übrigens nicht sehr gut geeignet, da der Blickwinkel für den Einsatz im Handy optimiert zu sein scheint. Der beste Kontrast ergibt sich, wenn man von unten leicht schräg auf das Display schaut. Bei senkrechtem Blickwinkel oder gar von der Seite leidet der Kontrast doch recht massiv.
So hab nun auch das Init Problem bei 16MHz behoben. Und zwar hab ich die init Routine so geändert das das Double Speed Bit erst nach der eigentlichen Initialisierung gesetzt wird. Also hier (glcd_init.asm):
1 | ; write initial screen command (i think not necessary...) |
2 | cbi LCD_PORT,LCD_CS ;select Display |
3 | |
4 | ldi T1,0xEF |
5 | rcall glcdDispCommand |
6 | ldi T1,0x90 |
7 | rcall glcdDispCommand |
8 | ldi T1,0x00 |
9 | rcall glcdDispCommand |
10 | ldi T1,0x00 |
11 | rcall glcdDispCommand |
12 | |
13 | ldi r24,1 ; double speed bit |
14 | out LCD_SPSR,r24 |
15 | |
16 | rcall lcd_clrscr |
17 | |
18 | pop r31 |
19 | pop r30 |
20 | ret
|
Hatten wir das gleiche Problem nicht auch schon beim Nokia Display ? Gruß Hagen
Naja zumindest ist der Blickwinkel beim Nokia auch nicht sehr groß. Das Problem beim Siemens Display lag aber zum Teil auch an mir :) Der Spannunsgregler war nich ganz richtig beschaltet das Display hatte nur 2V Versorgungsspannung... Jetzt kann man auch senkrecht aufs Display gucken, aber sonderlich groß is der Sichtbereich trotzdem nich. Ich denke mal mein Problem mit den 16MHz lag auch dadran, aber ein etwas langsameres Init kann denk ich trotzdem nich schaden :)
Hallo, schlechte Nachrichten für alle grünen und blauen... Ich habe gerade das grüne Display LPHxxx angeschlossen. Mit der aktuellen Software läuft es nicht! Ich habe auch bereits ein wenig am Timing gespielt, es aber nicht zum laufen gebracht. Vorher hatte ich es zum Test in das S65 eingesetzt und dort hat es funktioniert. (Daher glaube ich die Theorie mit dem M65 nicht) -> Vorerst als nur das LSxxx Display kaufen! (braun, rechts auf dem Bild)
@Christian: Wenn es im S65 funktioniert hat, aber mit Deiner eigenen Ansteuerung nicht, dann wird beim LPHxx vermutlich doch ein anderes Protokoll gefahren als beim LSxxx, d.h. in der Handysoftware wird erkannt, um welches Display es sich handelt, ähnlich wie beim Nokia 6100 Philips / Epson, z.B. durch Abfrage eines Identifikationsregisters. Wenn Du das Protokoll des Handys mit eingesetztem LPHxx nochmal aufzeichnen könntest, wäre das natürlich super. Ich weiss, ist viel Arbeit. Ich würde es auch selber machen, habe aber leider kein S65 und nur dafür eines kaufen ist mir dann dann doch etwws zu teuer... ;-) Gruß Michael
Von weiter oben: "Das grüne hatte ich nur einmal ganz kurz vor einiger Zeit im Betrieb. Nur um zu testen ob es funktioniert. (damals hatte ich die Displays übrigens parallel geschaltet, - beide zeigen dann das gleiche Bild...)" Die Ansteuersoftware hat sich danach noch geändert. Im wesentlichen "Weg-Optimierungen" von "überflüssigen" CS toggeln, Änderungen im Timing etc. Es besteht daher eine gewisse Wahrscheinlichkeit, dass das grüne Display mit der derzeitigen Ansteuerung nicht (mehr) funktioniert. Nach dem Motto was nicht getestet ist funktioniert meist auch nicht." Wenn ich das richtig verstehe hat es ja schonmal funktioniert :)
Ja, ich bin mir ziemlich sicher (ich werde schon vorsichtiger...), dass ich das grüne und das braune parallel in Betrieb hatte. Ich wollte ja wissen ob sie kompatibel sind... Darum sollten sie - wenigstens für init - einen ähnlichen Befehlssatz haben. Ich vermute, dass es eine blöde Kleinigkeit ist, die hier das grüne Display blockiert. Z.B. falsche Pegel auf RS/CS/CLK/DAT lines wärend der RESET Flanke... Ich habe jetzt schon einiges probiert, leider immer noch ohne Erfolg...
@ChristianK: auf Deiner Homepage steht 10,4V/20mA für die HB. Müßte die Gesamtspannung in "Schematic" dann nicht 14V sein (steht 15V drin)? 10,4+180Ohm*20mA = 14V. Wie ist das denn bei der HB, wenn die 5mA mehr Strom (immerhin 25%) bekommt? Grüße, AK
@Andre, ich kenne die Spezifikation der LED's nicht und habe mir den Aufbau der Hintergrundbeleuchtung auch noch nicht genau angeschaut. Im Moment gehe ich von drei in Reihe geschalteten LED's aus. D.h. bis zu max. 30mA Dauerstrom (je nach gewünschter Helligkeit/Batterie-Lebensdauer) sollte erlaubt sein. (sollten es 2x3 in Reihe geschaltete LED's sein müsste der Strom höher eingestellt werden...) Deine Rechnung stimmt. Aber der Messwert 10.4V@20mA gilt natürlich nur für dieses eine Display bei der damaligen Temperatur.
Hi, danke. Dann mach ich mich mal dran. Hab Deinen Code für einen ATmega8515 kompiliert (wegen DIP-Gehäuse und ein anderer war gerade nicht da). Werde einen 74HC573 als LevelShifter nötigen. Mal sehen ob mein LCD damit funzt ...
@Fabian Thiele könntest du eventuell mal deinen Code posten mit dem du die Bitmap ausgibst? Wo hast du die gespeichert ? Wenn ich richtig rechne hat das Display eine Auflösung von 132x176 Pixel also 23232 Bildpunkte bei 16 bit Farbtiefe sind das etwa 45kb?
Ich sende die Bilder über die serielle Schnittstelle vom PC. War nur nen einfaches Test-Programm ohne jegliches Protokoll oder so. Das ganze "Programm" sieht so aus:
1 | void recvPicture(void) { |
2 | uint8_t x=0, y=175; |
3 | glcdColor_t pix; |
4 | |
5 | for(uint16_t i=0; i<23232; i++) { |
6 | pix = get()<<8; |
7 | pix |= get(); |
8 | glcdSetPixel(x, y--, pix); |
9 | if(y == 255) { |
10 | y=175; |
11 | x++; |
12 | }
|
13 | }
|
14 | }
|
get() empfängt ein Byte übers UART, die Üebrtragung erfolgt mit 460kBaud, das Bild zu übertragen dauert ca. 1 Sekunde. Ich weiß auch das die Funktion glcdSetPixel() für diesen Zweck nicht optimal ist, da ja jedes Mal auch wieder die Position auf dem Display neu egsetzt wird, was jede Menge Overhead bedeutet, aber zum Testen reichts :)
Danke für die schnelle Antwort. Hast du ein speiziellen Programm mit dem du die Daten an den UART schickst oder verwedest du einfach das Hyperterminal und benutzt du die Funktion Datei schicken?
Ich hab mir ein kleines Java-Programm geschrieben, was die Bilder öffnet in die richtige Größe konvertiert, nach 16-Bit umrechnet und dann einfach die nackten Pixeldaten an den AVR sendet. Hyper-Terminal oder sowas funktioniert nicht, da das ja ein Protokoll zur Dateiübertragung verwenden würde, außerdem haben ja auch Bitmaps nen Header und auch nicht die passende Farbtiefe. Hab mein Programm mal angehangen, vielleicht kannst du ja was mit anfangen. Mit run.bat starten, Bild öffnen (gif, jpg oder png) Com-Port auswählen und senden. Baudrate ist fest auf 460kBaud, wenn das zu Viel ist musst dus im Quelltext anpassen udn neu kompilieren :). Wenn man ein Verzeichnis öffnet, werden alle enthaltenen Bilder im 15 Sekunden Takt als Slideshow angezeigt. Achja und du brauchst natürlich eine aktuelle Java Runtime Environment.
Das Programm scheint schon mal super zu sein. Leider hackt es auf dem Atmel noch etwas. Die Zeile "pix = get()<<8;" erzeugt beim Kompilieren den Fehler: undefined reference to `get'.
Ja klar, das is ja keine Library Funktion. Die Funktion empfängt einfach ein Byte übers UART. Hatte sie jetzt oben nicht mit gepostet weil ich das eigentlich für Trivial gehalten habe :) Im Anhang mal der Komplette Code für den AVR (mega128). Takt ist 18,432MHz. Wenn du einen anderen Takt verwendest, musst du den Wert für UBRR0L anpassen um die passende Baudrate zu behalten.
Schlechte Nachrichten für alle Besitzer von grünen Displays (LPH) und Epson (L2F) Displays. Ich habe - nachdem ich alle Variationen der Ansteuerung mit dem grünen Display erfolglos durchgefahren habe - den Parallel-Test wiederholt. D.h. ich habe ein Epson Display (L2F) (eingebaut) jeweils mit einem grünen (LPH) und dem braunen (LS0) ausserhalb und parallel am S65 betrieben. Leider ohne Erfolg. Es hat immer das externe Display gewonnen und den Inhalt angezeigt, wobei das interne L2F leer blieb. Ohne externes hat das interne funktioniert. -> Das S65 hat wohl eine Funktion um das Display zu erkennen -> Beim letzten mal muss ich wohl doch zwei gleiche Displays parallel geschaltet haben -> jedes Display wird seinen eigenen Befehlssatz haben Immerhin lässt das hoffen, dass das Epson kompatibel zu einem Epson Befehlssatz ist (d.h. mehr Addressierungsmodies, 0-Grad Betrieb mit glcd...)
Es gibt definitiv 2 verschiedene Controller: www.siediyer.com/Doc/x65SRD.pdf Seite 30
Hallo MarinK, toller Link - danke. Ich habe lange versucht das S65 repair manual zu finden, aber keiner der Links und Quellen hat funktioniert... Jetzt kennen wir zumindest schon die LED-Spec (15mA). Ich denke aber es gibt drei Hersteller (ich habe die drei Bilder auf meiner Web-Page). Eins kommt definitiv von EPSON (steht drauf). Wenn sie über die Widerstandswerte identifiziert werden kann man ja mal nachmessen...
Hi, > For the display two different sources are used, which > will be distinguished by the software via different > code resistor values. Bin ich noch zu müde? Hat jemand gefunden WIE man die LCDs erkennt? 'Resistor' scheint klar, aber welcher?
@ChristianK: > ich habe ein Epson Display (L2F) (eingebaut) jeweils mit einem grünen > (LPH) und dem braunen (LS0) ausserhalb und parallel am S65 betrieben. > Leider ohne Erfolg. Es hat immer das externe Display gewonnen und den > Inhalt angezeigt, wobei das interne L2F leer blieb. Ohne externes hat > das interne funktioniert. Ok. Heißt also L2F!=LPH und L2F!=LS0. Laut Datenblatt gibt es 2(!) verschiedene Typen. Wenn L2F!=LPH ist und L2F!=LS0, MUß LS0=LPH sein => Deine Routinen sollten auch mit dem LPH funktionieren. Allerdings befürchte ich noch eine andere Fehlerquelle: Die Widerstandskodierung dürfte nicht funktionieren bei 2 parallelen LCDs.
Hallo, Christian, du hast ja alle drei sorten displays, kannst du mal nachmessen: Widerstand zwischen masse und RESET: - L2F50xxx -> 52,46Kohm - LPH88xxx -> 20,1Mohm - LS020xxx -> ?? Widerstand zwischen masse und CS: - L2F50xxx -> 27,6Mohm - LPH88xxx -> 25,2Mohm - LS020xxx -> ?? Ich habe mit eine philips PM2525 (multimeter) gemessen und die com vom messgerät auch an die masse vom display gehalten. Nur der RESET und CS gehen zum ARM9 (SGold-Lite PM8875) controller, also können das meiner meinung nach die einzige pin zur display erkennung sein. Die andere pins (CLK, DAT, RS) gehen zum S1D13732, also keine möglichkeit zur erkennung. Grüße Mark,
Hi, das deckt sich ja mit meiner Theorie. Wenn das LS 20,1MOhm hat zwischen GND und RESET besauf ich mich heute abend ;-) Ich denke nicht, daß die 2MOhm Unterschied am CS relevant sind. Ich meß mal mein Display gleich nach.
@Christian: Hättest Du denn Zeit und Lust, das Protokoll des ans S65 angeschlossenen LPHxx nochmal mitzuloggen? Hab leider kein S65, sonst würde ich es selbst versuchen, aber falls mich jemand mit einem S65 sponsern möchte, jederzeit gerne... ;-) Gruß Michael
Hallo Alle, Kennt jemand das Siemens CXT65 ? Grüße Mark,
Hat sich erledigd, das CXT65 hat das gleiche display. Grüße Mark,
Hallo Freunde der grünen und blauen Display's, jetzt wartet Arbeit auf euch.... Hier ein C-Programm zur Ansteuerung des Displays. FillScreen() funktioniert tadellos aber ihr werdet sehen, dass die Textausgabe noch nicht ganz korrekt ist. Die Position und die Breite stimmt schon - aber die Höhe noch nicht... Die Zeichen sind ein wenig verschoben und nur halb ausgegeben. Also macht euch an die Arbeit und unterstützt beim Suchen der richtigen Ansteuerung.... Grüße Christian
Hallo Christian, Das sieht danach aus das der HD66766 Controller drauf ist. Grüße Mark,
Angehängte Dateien:
-
LPH_V01.jpg
120 KB
Das wäre natürlich super wenn es der HD66766 oder ein kompatibler wäre... Hier noch ein Bild zum obigen Program. Ich werde die nächsten Tage nicht unterstützen können also viel Erfolg. Grüße Christian
Hi, ich weiß nicht ob das mitten in diesen Thread gehört, aber: !!! EIN FETTES DANKE UND MERCI AN CHRISTIAN KRANZ FÜR SEINE MÜHEN UND UNTERSTÜTZUNG !!!
Angehängte Dateien:
-
IMG_0730.JPG
240 KB
@André Dem kann ich nur zustimmen! @Christian Die Ansteuerung hat geklappt, bis auf die Textausgabe. Zur Weiterentwicklung der Ansteuerung bin ich noch nicht gekommen, weil ich heute ein LS020-Display bekommen habe (Ebay, PID-Handy), das ich auf Anhieb auch zum Laufen bekommen habe. Mir ist aber aufgefallen, dass das LS020-Display wesentlich heller ist. Im Dateianhang ist ein Bild von beiden Displays, deren Hintergrundbeleuchtung mit je 12 mA betrieben wird (links LS020, rechts LPH88) Außerdem scheint das LS020-Display gleichmäßiger beleuchtet zu sein. MartinK
Hallo Alle, Ich arbeite gerade an eine platine für das Display. Ich will ein Platine machen mit: - +3.3volt oder +5 volt eingang. - Spannungs regler für 2.8 volt. - Spannungs regler für hintergrundbeleuchtung, PWM geregelt. - Level wandler für signale. - 10 polige stifleiste mit 2,54mm abstand. - etwas größer als das display. - größe 38.8mm x 60mm Soll noch etwas mit drauf? Grüße Mark,
O.k. nachdem das Datenblatt verfügbar ist (es handelt sich tatsächlich um einen HD66766 kompatiblen Controller :-) war es ja nur noch eine Sache von Minuten... Das LPH hat auch seine Vorteile: a) einfacher zu löten, da keine Folie b) Datenblatt verfügbar! D.h. mehr Möglichkeiten Jetzt muss ich mich aber um etwas anderes kümmern.
@Christian Hat das L2F50xxx-Display vielleicht auch einen HD66766? Wie hell ist dieses Display im Vergleich zu den anderen? MartinK
Hallo, mir ist kein gravierender Unterschied zwischen den Displays aufgefallen. Beim LPH ändern sich die Farben etwas, wenn man schräg draufschaut, dafür finde ich die Farben etwas satter. Ich habe auch keinen grossen Helligkeitsunterschied festgestellt. Die LPH LED forward-voltage ist ca. 0.5V höher (bei mir) als beim LS020. Ich betreibe die Displays aber auch mit etwas mehr als 20mA. @André: Danke, mache ich auch nur weil ich am Anfang irrtümlich versprochen habe die Displays sind kompatibel :-) @MartinK: Das L2F50 hat einen EPSON Controller. Die Ansteuerung liegt hier schon, brauche nur noch einmal 1-2h Zeit...
@Christian: Weisst Du welche EPSON controller drauf ist? Ich glaube es nicht der HD66766 sondern der HD66773, ich habe die register nochmal gecheckt. Grüße Mark,
Hallo, hab gerade eben diesen Thread entdeckt. Super sache! Ich hab mit die Seite von Christian angesehen, dabei ist mir folgende Frage eingefallen: Kann ich die 10,4V für die Hintergrundbeleuchtung aus dem Power-Booster des LCD-Controllers abziehen? Meint, hat der Booster reseven, sodaß er auch diesen Strom noch abzapfen läßt? Würd die Ansteuerplatine erheblich vereinfachen. abo Mario
@Mario Die Spannung vom Booster beträgt etwa 12,5 Volt (LPH Display). Wenn ich die LEDs daran anschließe, liefert dieser nur einen sehr geringen Strom von etwa 0.4 mA, also viel zu wenig. MartinK
@Mark Ich bin an einer solchen Platine interessiert und bitte um Info, sobald es Neuigkeiten in Bezug auf Preis und Lieferzeit gibt. Vielen Dank. Gruss, Ralf
Ist es nur die Platine oder mit Display? Ja und der Preis wäre gut.
Hallo Mark, --> Soll noch etwas mit drauf? - Joystick, siehe Butterfly Board - PS2-Tastatur Eingang - SD-Card Steckplatz
Vielleicht 7 Tasten zur Steuerung, es soll ja bezahlbar bleiben, verschiede Versionen mit Joystick und SD-Slot, gibts den auch als Bausatz? Vielleicht noch Version mit einen ATMEGA µC und SD-KArte.
@Mark, ich glaube an so einer Platine gibt's viele interessierte. Mit einer SD-Karte und der Java nanoVM hätte man dann ein richtig tolles und günstiges Kleincomputersystem, vorallem mit Farb-Display :)) Zudem gibt's dann sicher genügend freiwillige die fleißig daran herumbasteln. Ich habe mir jedenfalls soeben von Cellow ein so ein Display geordert. Mal sehen wann es da ist. Gruß Mario
Ich will ne Kaffeemaschine mit drauf haben!
@Mark ich wäre schon ganz zufrieden damit, wenn auf der Platine die Levelshifter und der Spannungsconverter für die 2,9V drauf wären. kannst dann mal bescheid sagen, was die platine kosten würde. mfg Kay
@Mark Denke auch, daß die nötigsten Komponenten reichen (2,9V-Regler, Levelshifter) vielleicht noch der Konverter für die HB. @ChristianK Mein LCD leuchtet zwar grün, aber kein Text ist zu sehen. Nur bunte Balken in der ersten Pixelreihe. Wird wohl noch ein Timing-Problem bei mir sein. Dein Quellcode definert kein F_CPU (wird für delay_ms() benötigt). Der Compiler setzt zwar als default 1000000UL, aber das klappt nicht immer. Wenn ich die Optimierung ausschalte (OPT=0), funktioniert das LCD nicht (kein Init). Auch ein wenig seltsam. Aber ich arbeite dran. Grüße, AK
@André Bei mir läuft die Ansteuerung (grünes Display) einwandfrei sowohl bei 1 Mhz als auch 8 MHz, obwohl ich Christians originale Hex-Datei (16 MHz) zum flashen genommen habe, ohne sie neu zu compilieren. MartinK
Hallo, Hat jemand schon das EPSON (L2F50126) display getestet? Das LS020B8UD06 hat glaube ich denn LR38826 controller drauf. Wenn mann sich seite 14 vom Datenblatt vom LQ022B8UD04 display ansieht, erkennt mann die kommandos wieder. Ich habe das Datenblatt vom LR38826 noch nicht gefunde, nur einen übersicht. Grüße Mark,
kurze frage: wo finde ich bei reichelt einen 2,9V regulator ? mfg Kay
Hallo Mark, einige Kommandos scheinen gleich zu sein -> Also ist Sharp der Hersteller :-) Nur die wichtigen Kommandos wie wie VRAM writing stimmen nicht. Aber: Du bist nahe dran, hast du noch mehr von Sharp?
Hallo Christian, Leider (noch) nicht, hast Du denn Epson schon getestet? Anfrage bei sharp hat noch nichts gebracht, anfrage bei epson lauft. Grüße Mark,
@Kay: versuchst mal mit LM317 kann man die Spannung mit 2 Widerständen einstellen. Datenblatt gibt bei reichlet
Hi, so. Mein LCD geht mit dem Code jetzt auch. Der Fehler war nicht in der Ansteuerung selbst, sondern mir scheint der AVR-GCC noch nicht ausgereift genug zu sein. Erklärung: - Sobald der Code mit 'OPT=0' kompiliert wird läuft er bei mir nicht. - Bei 'OPT=3' werden Warteschleifen wegoptimiert. Sind zwar simple for-schleifen ohne Inhalt, aber kein Grund es zu übertreiben. - Nur einige Zeichen gehen (wohl Zugriffsprobleme bei großen Arrays) Ich habe für die Änderung an den ATmega8515 nur die Portpins (funktioniert, da Ansteuerung geht) und das Compiler-Ziel (MCU) angepaßt. Zusätzlich hab ich noch ein F_CPU gesetzt, was aber wohl nicht unbedingt nötig ist (Wartezeiten sind da wohl nicht so kritisch). Entweder mach ich was falsch, oder das Teil ist für den ATmega8515 nicht zu gebrauchen. Grüße, André
Hallo Andre, der Code war nur als einfaches, sofort zu verstehendes Beispiel gedacht, daher liegen alle Daten (ASCII sowie Display) im RAM! (Denn dar AVR braucht spezifische (non ANSI) Befehle für den Zugriff auf den Program-Speicher. Ich kenne den ATmega8515 nicht, aber ich vermute, du hast zu wenig RAM. Daher solltest du die ganzen Arrays in den Program-Space verschieben. Wie das geht steht sehr gut hier im AVR-GCC Tutorial beschrieben. Vielleicht sollte ich den Beispielcode dementsprechend ändern....
Hi, danke aber nicht nötig. Denke Du hast Recht mit dem Problem. Das sollte aber vom AVR-GCC erkannt werden und - entweder Abbruch mit Fehler - oder die Daten ins .cseg und mit LPM zugreifen. Naja. Vielleicht lese ich erstmal ein wenig und übe, bevor ich den Thread mit Sachen zumülle die nichts mit der LCD-Ansteuerung zu tun haben ;-) Grüße, André
@Christian Betrifft LS020-Display Ich habe eine einfache Ansteuerung in Bascom geschrieben. Dabei habe ich festgestellt, dass ohne die beiden Befehle EF90 0000 nach der Initialisierungssequenz auf dem Bildschirm nichts erscheint. (in deinem Asm-File steht dazu: I think not necessary...) MartinK
@Christian Außerdem habe ich festgestellt, dass die Zeit zwischen Init2 und Init3 zwar eine Mindestzeit von etwa 7 ms haben muss, doch die Maximalzeit ist unbegrenzt (1 Sekunde funktioniert bei mir noch) MartinK
Hallo MartinK, zur Mindestzeit: ich könnte mir vorstellen, dass es daran liegt, das es jetzt 3-Init Sequenzen gibt (am Anfang hatte ich nur 2). Der Display reset 0xFDFD war vorher wohl noch nicht sauber gelaufen. Jetzt kannst du das ja mal ausprobieren :-)
Hallo Leute, hab das PDF ein bisschen erweitert. Falls irgendwo Fehler drinn sind bitte mir sagen. Gruss Lightning
Hallo Lightning, Der Controller ist der HD66773 und nicht der HD66766. Kannst du nocht die init für das LPH88 display hinzufügen? Grüße Mark,
Kann das sein das das LS020 am meisten bei Ebay verkauft wird ( gelbliche Platine ) und der LPH88 ein auslauf Modell ist das L2S50 sieht man auch ab und zu. Frage: Aber ich es jetzt richtig verstanden das , nur der LPH88 im Moment läuft? Wie weit seit Ihr mit den anderen? Ich ohne bedenken LS020 kaufen oder erstmal abwarten? Für welche Displays kann man verwenden. Bitte - gebt bei den Posts an welches Display ihr meint , sonst kommt man ja durcheinander. Gute Arbeits Jungs!!!!
@Mark de Jong Ist die INIT für das LPH88 Display die mit den 3 einzelnen Inits ?? ~ Lightning
@ Dirk: Den mehr oder weniger aktuellen Stand findest du hier: http://www.superkranz.de/christian/S65_Display/DisplayIndex.html Grüße Christian Im Moment ist das LPH88 und LS020 supported. Das L2F50 hoffentlich bald. Die GLCD gibt es derzeit nur für das LS020, ein gleichwertiger Port für das LPH88 ist einfach möglich. Für das L2F50 könnte es schwieriger werden, da es anscheinend keine Addressierungs-Modi unterstützt.
@Mark de Jong:
>HD66773 und nicht der HD66766
Wieso denkst du es ist das HD66773? Hast du die Specification davon?
Wenn ja würden mich die Grafik-Befehle interessieren bzw. ob sie sich
vom HD66766 unterscheiden.
Die Grafik-Befehle die ich benutze sind zum HD66766 kompatibel.
Grüße
Christian
Hallo Christian, Wenn mann die init anschaut schreib er auch zu register 0x0D und 0x0E beim init. Die gibt beim HD66766 nicht, aber beim HD66773 schon. Deshalb glaube ich das es der HD66773 ist. Grüße Mark,
@Mark de Jong Wenn ich die INIT für den LPH88 auch ins PDF reinschreiben soll muss ich wissen welche Init das ist. Jetzt sind auf der Homepage vom Christian Kranz da auf einmal 3 einzelne Inits. Warum ?? Hab ich was verpasst ?? Gruß Lightning
@Lightning: Am besten wartest du, bis alles 100% deutlich ist. Grüße Mark,
@Mark de Jong Ja ist wohl das beste. Wenns soweit ist poste ich dann das neue PDF. Gruß Lightning
Hallo, Ich schreibe gerade an meine software library die ich auch frei verfügbar machen werde (pre-beta, längst nicht alles ist drin). Ich schreibe sie für denn MSP430 (IAR Embedded Workbench), er soll aber auch für denn Atmel werden (brauche jemand der dabei hilft). Ich werde das font-tool von Ape benutzen. Der low-level treiber ist für pin toggle und SPI-hardware ausgelegd. Grüße Mark,
Hallo, Ich plane zwei Platinen: 1. Minimal platine (fertig für produktion): - mit oder ohne display lieferbar. - +3.3volt oder +5 volt eingang. - Spannungs regler für 2.8 volt. - Spannungs regler für hintergrundbeleuchtung, PWM geregelt. - Level wandler für signale. - 10 polige stifleiste mit 2,54mm abstand. - etwas größer als das display. - größe 40mm x 60mm 2. MMI platine (in arbeit) - nur mit display lieferbar. - 5 volt eingang. - MSP430F15x/MSP430F16x/MSP430F161x microcontroller. - JTAG anschluss. - I2C anschluss mit pegel anpassung. - RS232 V24 anschluss. - bis zu 64Kbytes EEPROM (smd) - Spannungs regler für 3.3 volt und 2.8 volt. - Spannungs regler für hintergrundbeleuchtung, PWM geregelt. - 2x 4 taster neben display. - 5 tasten unterhalb display (in kreuz). - größe 60mm x 90mm. Sobald ich preise und lieferzeiten weiss melde ich das auch hier, und auf meine homepage (www.mdejong.de) Die software library und alle iinformationen für die displays wird auch auf meine homepage zum download verfügbar sein. Grüße Mark,
Könnt Ihr in eure Programm Dateien auch reinschreiben für welchen Display damit man bescheidweis wenn man mal die Lib tauschen will. Ich bin mal gespannt auf die Preise :-/
Kurze Frage zur Spannungsversorgung: Weiter oben im Thread steht, dass der 1V8 Eingang auch 2V9 verträgt. Im Datenblatt zum HD-Controller hab ich gesehen, dass der alles im Bereich von 2.2 bis 3.3V verträgt. Ich vermute mal dass das für alle Controller die hier im Einsatz sind gilt. Ist der Level-Shifter + Spannungswandler überhaupt nötig, oder spielt da das LCD-Panel auch eine Rolle? Mario
@Mark: "Sobald ich preise und lieferzeiten weiss melde ich das auch hier, und auf meine homepage (www.mdejong.de)" Nicht, daß das so hängenbleibt wie andere unvollendete Projekte von Dir. Auf die LCD-Platine zum 640er warten wir bis heute trotz vollmundiger Ankündigung...
Hallo Andi, Wie du auf meine homepage sehen kannst ist der platine jetzt lieferbar. Ich mache das alles alleine und neben meine eigentliche arbeit deshalb dauert es manchmal länger. Die hardware entwicklung ansich ist nicht das Problem. Die testfase kostest viel zeit (Platinen machen lassen, bauteile besorgen, aufbauen, testen....) , ich biete keine ungetestet hardware an. Auch das schreiben von der doku nimmt viel zeit in anspruch. Ich möchte das meine Produkte für jeder zu benutzten sind, also keine "bastellösungen". Ich bin auch jederzeit bereit fragen zu beantworten (per email oder telefonisch). z.b. Das suchen welche controller auf die displays benutzt werden hat viele stunden gekostet, ich habe viele stunden verbracht im internet zu suchen und datenblätter zu lesen. Dies soll keine entschuldigung sein, sondern nur eine erklärung :-) Ich beschwere mich auch nicht, es ist eine hobby für mich. @Mario, Du hast recht das steht im datenblatt vom controller, aber wir haben kein datenblatt vom LCD-Panel, deshalb gehen wir auf nummer sicher und benutzten nur 2,9 volt. Der level-shifter is "notwendig" um die signale zum controller richtig zu haben (die flankensteilheit, etc.) Grüße Mark,
Hallo André Kronfeldt und den rest der Leser. Ich hab mal eine Frage an gerichtet André, du sagtest oben das du dein Display mit einem Levelshifter 74HC573 ansteuern wills, meine frage dazu hat dies Funktioniert und wie hast du diesen angeschlossen. Vielen Dank Holger
Ist es eigentlich möglich die Lib noch um eine Funktion zu erweitern um Dreiecke zu füllen? Damit könnte man dann beliebige Polygone zeichnen da sich ja jede Form in Dreiecke zerlgen lässt.
@Holger: Ich hab dann doch lieber 10 Widerstände genommen. Der 74HC573 hat entgegen seinem Dateblatt die Ausgänge auf 3,3V gelegt (angeblich maximal VCC+0,5V). Wurde extra mit 2,4V versorgt. Ging aber nicht. Ich hab das bislang aber nicht weiter verfolgt, werde mich aber mal bei Gelegenheit dran machen. Grüße, AK
@Andi, ich muss mich Mark anschließen. Es ist das Forum für Hobbyasten und Bastler, das ist weit weg vom Komerziellen. Da gibts andere Seiten, beipielsweise www.display300.com. Ich denke aber mal, dass Dir das sowieso klar ist und du Mark nur motivieren wolltest damit die hier interessierten daran auch zu der Platine kommen. ICh denke er tut in seinem Rahmen des möglichen das beste ... @Mark: Ich werde mich mal bzgl. LCD-Panels schlau machen. Ich denke die werden sowieso über den internen Booster angesteuert, der wiederum die Spannung über die interne Referenz erzeugt. Aber der "auf Nummer sicher" Ansatz klingt überzeugend :) Mario
@André ein normaler HC573 hat an seinen Eingängen ESD Schutz-Dioden, die dafür Sorgen das Überspannungen an den Eingängen auf die Versorgungsspannung abgeleitet werden. Wenn du nun an den Eingängen höhere Pegel hast als die Versorgungsspannung des ICs, wird die Versorgung über die Eingänge hoch gezogen. Da der AVR recht kräftige IOs hat stellt sich dann eine entsprechend höhere Spannung ein. Deshalb steht ja auch in den Absolute Maximum Ratings als Maximum Input Voltage VCC... Ein Level Shifter wie z.B. ein HC4050 ist dafür ausgelegt an den Eingängen höhere Pegel als die Versorgungsspannung zu haben.
@Fabian Danke. Das kommt davon, wenn man nur die Hälfte liest. Einen HC4050 hab ich wohl noch hier. Ich teste das mal. Grüße, André
@Fabian bei mir im Datenblatt ist für den HC4050 aber auch VI DC Input Voltage -0.5 to VCC + 0.5 V (Maximum) VI Input Voltage 0 to VCC V (RECOMMENDED) angegeben und in der CIRCUIT SCHEMATIC auch zwei Schutzdioden (allerdings gestrichelt).
Also bei TI steht im Datenblatt: "The HC4049 and HC4050 are fabricated with high-speed silicon gate technology. They have a modified input protection structure that enables these parts to be used as logic level translators which convert high-level logic to a lowlevel logic while operating off the low-level logic supply. For example, 15-V input pulse levels can be down-converted to 0-V to 5-V logic levels." Ausprobiert hab ich die aber auhc noch nie.
Hallo, Wegen die pegelwandler hier ist mein schaltplan für die Platine. Ich benutzte denn 74LVC1T45 und 74LVC2T45 von TI. Grüße Mark,
"Dies soll keine entschuldigung sein, sondern nur eine erklärung :-) Ich beschwere mich auch nicht, es ist eine hobby für mich." Wenn das ein Hobby ist, wieso dann eine Umsatzsteueridentnummer? Im Übrigen ist der Bestellvorgang nicht gesetzeskonform. Wenn man nämlich die AGB bei der Bestellung anklickt (Der Link hinter dem Haken), dann führt der ins Leere. Die AGB werden also nicht Bestandteil des Kaufvertrages. Wenn man die AGB links anklickt, so kommen hier nicht gesetzeskonforme AGB zu Tage. Portkosten sind nämlich ab einem Bestellwert von 40 Euro in jedem Fall vom Verkäufer zu erstatten. Auf jeden Fall solltest Du an der Webseite arbeiten, sonst kann das schnell teuer werden.
@Mark: > Wenn mann die init anschaut schreib er auch zu register 0x0D und 0x0E > beim init. Die gibt beim HD66766 nicht, aber beim HD66773 schon. Ich find die beim HD66773 aber auch nicht. R0Bh (Seite 35) ... R0Fh (Seite 37) ...
@Andre, Aber auf seite 27 :-) @Andi, Mann braucht einen Steuernummer zum verkaufen, Auch wenn es ein hobby ist. Auch ein gewerbe kann ein hobby sein, ich meine nur das ich nicht davon lebe (kann). Grüße Mark,
@Mark: Japanische Reihenfolge ist schon seltsam. BTW: Natürlich hab ich nach 'R0Ch' gesucht, ging aber nicht.
@Christian Habe gerade gesehen, dass du die Ansteuerung für das L2F50-Display fertig gestellt hast. Hast du vielleicht ein Datenblatt des Controllers gefunden, weil du so detailiert die Befehle beschrieben hast. Besonders interessant finde ich, dass es eine 18-Bit-Farbdarstellung gibt. Bedeutet das, dass dieses Display das Beste von allen Dreien ist? Oder welches Display würdest du empfehlen? (in Bezug auf Bildqualität, Helligkeit, Ansteuerbarkeit) MartinK
Hallo, Das ist ein Controller von EPSON, wie der S1D15G10 (132x132pixel). Jetzt brauchen wir nur noch das richtige datenblatt. Grüße Mark,
Hi, ich hab mal eine Frage zu der generellen SPI-Kommuniktation. Laut Datenblatt (S55) wird CS* auf low gezogen um das LCD zu selektieren. Dann werden die Daten (Kommando, Parameter) übertragen. Danach CS* wieder auf high. Laut dem Code von ChristianK ist CS* die ganze Zeit low und wird nur nach der Übertragung kurz auf high gezogen. Woran liegt das? Grüße, AK
"Mann braucht einen Steuernummer zum verkaufen, Auch wenn es ein hobby ist." Das ist falsch. Entscheidend ist die Gewinnerzielungsabsicht. "Auch ein gewerbe kann ein hobby sein, ich meine nur das ich nicht davon lebe (kann)." Das ist etwas anderes, wenn die Umsätze zu gering dafür sind. Entscheidend ist, wie gesagt, daß Du damit Gewinne erzielen möchtest.
@Jochen & Andi abgesehen davon, daß einem in diesem Land bestimmt sofort 'Gewinnerzielungsabsicht' vom Finanzamt unterstellt wird sobald man versucht einen alten Kaugummi loszuwerden, halte ich die Diskussion über den Shop in diesem Thread für unangebracht. Nicht bös sein, aber ich denke es geht hier um das S65-LCD und um die Ansteuerung (von mir aus auch um Bauteilbeschaffung). Grüße, André
@Andre: Da hast Du völlig recht, also ENDE. Grüße Mark,
Hallo Andre, >Laut dem Code von ChristianK ist CS* die ganze Zeit low und wird nur >nach der Übertragung kurz auf high gezogen. Das stimmt so nicht. Schau dir den Code nochmal genau an. Im übrigen unterscheidet sich die CS Steuerung bei jedem Display Typ. Es gibt aber auch bestimmt andere CS Steuerungen die zum Ziel führen, als die aus meinem Code. Allen Display's gemein ist (hoffentlich, noch nicht getestet) dass sie den SPI Bus ignorieren wenn CS=high ist. Grüsse Christian
@Christian, Hast Du das richtige datenblatt vom EPSON controller? Wenn Ja, kannst Du das Posten? Grüße Mark,
@Christian: Es geht hier um das LPH. Nach einem port_init() ist CS* low. Im lcd_init_c() wird erst ein Reset (CS*=1) durchgeführt und dann das LCD selektiert (CS*=0). Soweit okay. Dann kommen die Daten per comtype() oder comdat(). Nach dem Senden wird CS* auf high gezogen. Da komm ich noch mit. Aber warum geht es danach wieder auf low? Vor allem, weil Du es am Ende von lcd_init_c() wieder setzt. Das Setzen ist okay (LCD nicht selektiert), aber der zusätzlich Impuls scheint mir unnötig, oder? Kann aber auch sein, daß Du versuchst das LCD default-mäßig zu selektieren um mehrere Befehle hintereinander zu senden. Dann ist natürlich klar, daß du am Ende von put_char() und lcd_init_c() das LCD wieder abwählen mußt. Trickser ;-) Ich denke aber auch, daß der BUs ignoriert wird, wenn CS*=1 ist. Gruß, AK
@Mark: Nein, ich habe kein passendes Datenblatt zum Epson Controller. Wäre schön wenn du das irgendwie besorgen könntest ;-) Die Commands sind aber ähnlich zu anderen Controllern (z.B. der 132x132) und die die benutzt werden passen auch soweit. Andere, die bei mir noch in der #define Liste stehen, aber nicht benutzt werden, z.B. DISPINV, scheinen nicht zu funktionieren. Ich habe aber noch nicht alles (viel) ausprobiert. Hoffe das die SLEEP Commands funktionieren. Grüße Christian
@Andre, schau mal in das HITACHI Datenblatt. Da steht etwas zu den CS Flanken. Z.B. muss es zu Begin und Abschluss der commands gewisse Flanken geben. Grüße Christian
@Christian Hast die 18-Bit-Farbenzahl beim L2F50-Display schon ausprobiert? (bezieht sich auf deinen Kommentar im C-File) MartinK
Hallo, auch ich hab mal eine Frage in wie fern ist es möglich zwei Displays über einen Mikrocontroller zu steuern, muss man dazu im Code viel verändern? Mfg Thomas
@Thomas Wenn ich mich nicht täusch, sollte es reichen wenn man getrennte CS* Signale auf jedes Display legt. Der Code ist dann fast derselbe (bis auf die Anstuerung des CS*).
@MartinK könntest du mir bitte dein Beispiel in Bascom mal zukommen lassen ? mfg Kay
@MartinK: > Oder welches Display würdest du empfehlen? (in Bezug auf > Bildqualität, Helligkeit, Ansteuerbarkeit) Weiter oben im Thread findet man: >Mir ist aber aufgefallen, dass das LS020-Display wesentlich >heller ist.... Außerdem scheint das LS020-Display gleichmäßiger >beleuchtet zu sein. Aha, aber trotzdem würde ich die LPHxx Display (die grünen/blauen) aufkaufen wenn ihr sie los werden wollt.... Grüße Christian P.S: Die LPH's lassen sich nämlich laut Datenblatt (noch nicht probiert) erheblich flexiber programmieren. Es gibt praktisch alle Addressierungsarten, so dass z.B. ein Port der glcd in allen Rotationen einfach möglich sein wird. D.h. das LPH Display eignet sich dann sehr gut zum Quereinbau (längs). Bei den anderen beiden Displays ist dazu mehr Portierungsaufwand erforderlich. Die Bildqualität ist bei allen recht ähnlich, die Qualität der Beleuchtung wohl beim LPH am schlechtesten, L2FS und LS020 sind ähnlich. Meiner Meinung nach macht das L2FS Bildmässig overall den besten Eindruck, auch was die mechanische Qualität angeht - ist aber derzeit von der Programmierung her am wenigsten flexibel. Beim LPH kann man sich sogar noch ein Interface-Signal (RS) sparen. Also zusammengefasst derzeit meine private Rangliste: a) LPH b) LS020 c) L2FS
Christian, reagiert deine step-up 10V Quelle empfindlich auf die groesse der Induktivitaet ? Ich habe eigentlich KEINE Ahnung von dem analogen Gebimsel und habe hier noch ne 1mH Festinduktivitaet rumliegen und hoffe, man kann das mit einer Anpassung des PWM Signals ausgleichen. Ich gehe mal davon aus, dass der Transistor- und Dioden-Typ eher nebensaechlich sind, oder ? (dachte an BC546 + 1N4148). Daz
@The Daz Ich würde lieber bei einer Schottky-Diode bleiben.
Hallo, ich habe im eBay ein bischen herumgesucht und bin auf das SX1 gestoßen. Ich weiß, dass dass hier nicht so richtig passt. Aber ich vermute, dass dieses Display (ist etwas größer) ähnlich in der Ansteuerung ist wie dieses hier. Hat dazu schon jemand eine Idee. Hier die "Daten" vom Display: Display (genutzte Fläche) 35 x 44 mm (176 x 220 Pixel, 65.536 Farben) Das Teil gibts für ca. 15.- bei eBay. Zu meiner Level-shifter Frage von vorhin. Nachdem ich mich versucht habe so gut wie möglich schlau zu machen, bin ich auf folgende Versuchsanordnung gestoßen: Das Display anhängen und langsam die Spannung schrittweise von 2.9V bis 2.2V verringern. Ändert sich nichts (Kontrast etc.), so sollte dasselbe auch für höhere Spannungen gelten, d.h. das Display kann innerhalb der Controller-Spezifikation betrieben werden. Von der Theorie her (Flüssigkristalle etc.) sollte das auch für das Panel nicht kritisch sein. Desweiteren scheint der Controller seine LCD-Treiberspannungen von der (internen) Referenz zu erzeugen wie es das Blockschaltbild darstellt. Welche internen Spannungen hat das S65? Mario
Hallo Mario, Das SX1-display habe ich ach schon gesehen, aber das hat glaube ich einen 40 polige connector. Grüße Mark,
Soweit ich das auf den eBay Bildern erkennen konnte scheint der Connector 18 Pins zu haben... Das spricht jedenfalls für ne paralelle Schnittstelle. Macht auch Sinn, bei 176*220 Pixeln und 16 Bit ist ein Bild stolze 77440 Byte groß. Bei einer SPI Schnittstelle mit 8MBit würde man für ein Bild im Idealfall 74ms brauchen bzw. 13,5fps schaffen. In der Praxis wäre das ganze noch wesentlich langsamer, da die Daten ja erstmal generiert werden müssen. Überhaupt sind AVRs für diese Auflösungen meiner Meinung nach nicht mehr wirklich geeignet, und die hohe Auflösung ist denke ich auch einfach überflüssig. Zu JPEG- oder Video-Anzeige sind AVRs glaube ich selbst bei noch so effizienter Programmierung nicht mehr in der Lage :) und sonst wüsste ich nich wofür man die vielen Pixel noch gebrauchen kann. Für die größeren ARMs könnte so ein Display schon eher handhabbar sein, aber die Anwendung fehlt immernoch. Vielleicht ein selbstbau Video Player mit TI DaVinci :D
@Fabian Thiele Also mein Anwendungsfall wird ganz klar GinaSisters oder Tetris ;-) Mittlerweile kann mein LPH Hardware-Scrolling und am Wochenende werde ich die guten alten 'Sprites' oder 'Blobs' realisieren. Meine Frau fragt mich zwar nach dem Sinn, aber ich hoffe ich werde nicht entmutigt ;-) Der Code von ChristianK ist mittlerweile auch nach Assembler übersetzt und ein wenig optimiert. Die Datenaufbereitung fällt fast nicht mehr ins Gewicht. Ich hoffe nur, daß bald die bestellten ATmega128 kommen, der ATmega8515 wird langsam eng (SRAM-mäßig). Das momentan angebundene Dataflash ist zu langsam. Grüße, AK
Bascom-Ansteuerung für ein LS020...-Display http://www.xmail.net/martin-k/display.htm Benötigt wird eine neuere Bascom-Demo-Version, die auf 4 kB Codegröße limitiert ist. MartinK
@The Daz:
Der Supply Boost ist nicht sehr empfindlich. Kannst also ruhig mit der
1mH Spule starten. Empfehlung ist erstmal mit einer kleinen pulse-weite
anzufangen und dann langsam hochdrehen...
Weiterhin empfehle ich für's Lab/Bastellkeller einen
Überspannungsschutz vorzusehen. Wenn z.B. mal das Display - bei
anliegendem PWM Signal - nicht angeschlossen ist, wird sich der
Spulenstrom einen anderen Weg suchen. Der ist sonst vmtl. tödlich für
irgend ein anderes Bauteil. Ich habe zwei 5.6V Z-Dioden in Reihe
geschaltet.
Hier die Initialisierung des Timers 2 für die PWM Erzeugung (16MHz ->
62.5kHz PWM Frequenz). (Achtung, die die den PB7 for LCD_RS genutzt
haben - wie ich in meinen Code-Beispielen - müssen den verlegen z.B.
auf PB5) Puls-Weite ist OCR2/256. PWM Ausgangssignal ist OC2 (PB7)
// backlight PWM generation
// use timer 2 in fast PWM mode for this
PORTB &= ~_BV(PB7); // clear port before enable
DDRB |= _BV(PB7); // will be used for OC2, must be output
TCCR2 = _BV(WGM21) | _BV(WGM20) | _BV(COM21) | _BV(CS20);
TCNT2=0x00;
OCR2=120;
Zur Hardware:
Schottky Diode ist wegen besseren Wirkungsgrad (normale geht aber
auch).
Beim bipolaren Schalttransistor den Basis-Vorwiderstand nicht vergessen
;-)
Grüße
Christian
Hy Leute, Hab das PDF wiedermal auf den neusten Stand der Dinge gebracht. Falls Fehler auftauchen oder sonst was ist wie immer bitte melden. Gruß Lightning
@Christian, merci fuer die Info. Hab mir ein LS020 bestellt und werde demnaechst anfangen. @Lightning, daaaanke fuer den update. Endlich kenne ich die genauen Einbaumasse und es sieht so aus, als ob das Display in ein 1HE 19" Gehaeuse passen wuerde.
@Lightning: Denn Update beim PWM backlight hast du noch nicht mit aufgenommen. Wie erzeugst du das PDF? Von Hand? Grüße Christian
Such mal im netz nach PDF Drucker ;) evtl auch nach Ghostprint oder script hiess das tool meine ich Gruss
hi Lightning, wieso gibts das pdf nur in englisch. ich kann zwar englisch, aber in Deutsch würde ich es besser verstehen. gibt es dafür einen besonderen grund ? mfg Kay
Hy Leute, @ Christian Kranz Hab das PWM Update jetzt eingefügt. Zuerst schreibe ich das Zeug im Word und dann nehm ich den Acrobat 7.0 her und mache aus dem Word Dokument ein PDF. @ Kay Bin seit 2 Tagen drann das PDF nach Deutsch zu Übersetzen jedoch hab ich eher wenig zeit daher dauert das n bisschen. Wenn ich die Deutsche version fertig habe, poste ich sie natürlich auch hier im Forum. Danke nochmal an alle. Gruß Lightning
Leicht OT, aber dennoch passend: Verwendet man anstelle von Microsoft Word den OpenOffice Writer, dann hat man den PDF-Export gleich mit dabei. OpenOffice 2.0 (gibt es seit einigen Tagen) ist kostenlos und weitestgehend kompatibel zu den aktuellen Microsoft-Formaten. Von politischen oder religiösen Überzeugungen abgesehen kann ich wenig Gründe erkennen, die gegen eine Migration sprächen.
@Rufus T. Firefly Da ich mich mit Word schon sehr gut auskenne, geht es schneller wenn ich das ganze ein bisschen umständlicher mache, als wenn ich mich jetzt in OpenOffice einlerne. Gruß Lightning
Ich hab mir die Schaltung jetzt mal mit nem ATMega16 @ 16MHz und nem LS020 Display auf nem Steckbrett zusammengestrickt. Fuer die LED Voltage steht bei diesem uC ja nur 62,5kHz (anstatt 200kHz wie im PDF beschrieben) zur Verfuegung. Auf die benoetigten 10,4V komme ich bei mir erst mit ca. 5mH Spuleninduktivitaet und einem Puls/Pause-Verhaeltnis von 52%/48% (OCR2 = 134). Das kleine Demo-Programm (Hello World) scheint auch nicht zu funktionieren, der Hintergrund wird zwar eingefaerbt, aber es ist kein Text zu sehen. Aus diesem Grund habe ich erstmal nur versucht kleine Rechtecke aufs Display zu zaubern. Dabei hat sich herausgestellt, dass die X und Y Koordinaten vertauscht zu sein scheinen. Egal welchen Rotations-Wert ich einsetze, ich muss X und Y vertauschen. Sehr seltsam, werde das nochmal genauer untersuchen. Ansonsten bin ich bisher ganz zufrieden mit dem Ergebnis. Vielen Dank an Christian und Mark. Good job ! Daz
@Daz: Backlight: Ich benutze 820µH mit 62.5kHz mit n-channel FET und schottky diode. -> funktioniert tadellos, Helligkeit lässt sich über pulse weite sehr gut einstellen, auch extrem hell (und vmtl. weit ausserhalb der LED Spec.) Kann sein dass das an deinen nicht optimalen Bauteilen (bipolar Tr. 1n4148 liegt) Hello World: Schiebe mal die komplette ASCII Tabelle in den Flash Speicher. Ich vermute du hast ein SRAM Problem... (Als Beispiel kannst du dir den Code vom EPSON Display ansehen oder GCC tutorial oder du weisst das sowieso) Gruesse Christian
Christian, dachte ich zuerst auch. Habe deshalb auf FET und Shottky-Diode umgestellt und damit ueberhaupt erst ein braucgbares Ergebnis erziehlt. Die angegebenen Werte beziehen sich daher auf die FET/Shottky Kombination. Ich will nicht ausschliessen, dass der Aufbau auf dem Steckbrett seinen Teil dazu beitraegt. Die ASCII-Tabelle ins Flash zu schieben werde ich heute abend mal ausprobieren. Danke fuer den Tip. Daz
Jo, den Font ins Flash zu verlegen hat das Problem mit der Anzeige des 'Hello World' Strings gefixt. Bleibt nur noch die Sache mit den vertauschten Koordinaten. Aber da scheint es, als ob das Beispiel-Programm mehr weis als das PDF Dokument. Bei 0° Rotation vertauscht die put_char Routine nämlich auch die Koordinaten und schon stimmts wieder. Daz
Angehängte Dateien:
-
Display.jpg
77 KB
@MartinK hi, hab das display jetzt am laufen. hat sogar auf anhieb geklappt. wenn ich den AVR und das display mit Strom versorge, dann dauert es ca. 20 Sekunden bis das Display voll beschrieben ist. Ist das normal ? liegt es daran, das es keine SPI Ansteuerung ist ? mfg Kay
@Kay Bei mir dauert der Bildaufbau maximal 3 Sekunden bei einer Taktfrequenz von 8 MHz. Natürlich wäre eine Ansteuerung über SPI wesentlich!!! schneller. (Bascom unterstützt SPI-Befehle) Selbst ohne SPI läßt sich mein Code noch optimieren. Ich werde mal sehen, was ich da noch ändern kann. Der Vorteil einer Ansteuerung ohne SPI ist, dass sich jeder Portpin eignet. MartinK
@MartinK ok, habe meinen Fehler gefunden. war ja ein neuer mega8. Da ich mit den megas noch nicht so viel gemacht habe, habe ich vergessen, die FuseBits so umzustellen, das er auf externem Quarz läuft. jetzt dauert der Bildaufbau ca 1-2 Sekunden mit 16 Mhz. ja bascom kann SPI. man könnte ja auch SoftSPI benutzen, dann würde man auch jeden Port benutzen können. Müsste nur in Bascom die Ports für den SoftSPI Port definieren. mfg Kay
@MartinK ich habe mal ein wenig am programm rumgespielt, aber ich blicke nicht durch. ich möchte einfach nur den ganzen Screen Blau malen. Könntest Du mir bitte sagen, wie ich das anstelle ? ( Ich habe versucht, aus dem PDF schlau zu werde, nur dieses Englisch .... :-) ) mfg Kay
@Kay Auf meiner Seite http://www.xmail.net/martin-k/display.htm habe ich das Beispielprogramm aktualisiert. Ich benutze jetzt die Shiftout Funktion, die Ansteuerung läuft etwas schneller. Wenn du nur Blau malen willst, so gehst du folgendermaßen vor: (Code aus LS202-RGB.bas) 'Blau malen A = &HEF90 Gosub 16 A = &H0500 ' 00 => Bild wird von oben nach unten gemalt Gosub 16 A = &H0800 'x1 Gosub 16 A = &H092B 'x2 Gosub 16 A = &H0A00 'y1 Gosub 16 A = &H0B7F 'y2 Gosub 16 EF90, 0500, 08.. 09.. 0A.. 0B.. sind die Grafikbefehle zum Malen eines Punktes oder Ausschnittes. Du musst nur noch die Koordinaten einsetzen. In meinem Beispielprogramm beginnt der Ausschnitt bei x1,y1 = 0,0 und endet bei x2,y2 = 2B,7F (Hexadezimal) = 43,127 Diese Werte kannst du beliebig variieren, jedoch darf x nicht größer als 131 und y nicht größer als 175 sein (0 wird mitgerechnet) Als nächstes folgen dann die Farbwerte für die einzelnen Bildpunkte im 16-Bit-Format RRRRRGGGGGGBBBBB Wenn du also nur Blau malen willst, so hat jeder Punkt den Binärwert 0000000000011111 = 31 Für einen kompletten Bildschirm musst du 132*176 = 23232 mal den Wert 31 senden. Alternativ gibt es die folgende Befehlssequenz: EF90, 0500, 06x1, 07y1 Hier definierst du nur den Startpunkt, der Endpunkt liegt automatisch bei 131,175 MartinK
@MartinK also ich habe das neue Beispiel von Dir ausprobiert. Das Bild baut sich wesentlich schneller auf. Wenn ich das ganzen Screen Blau malen will, dann mache ich es, wie du geschrieben hast: 'Blau malen A = &HEF90 Gosub 16 A = &H0500 ' 00 => Bild wird von oben nach unten gemalt Gosub 16 A = &H0800 'Start 00 Gosub 16 A = &H0983 'Ende 131 Gosub 16 A = &H0A00 'Start 00 Gosub 16 A = &H0BAE 'Ende 174 Gosub 16 Das Display zeigt dann auf der ganzen Breite das Blaue, nur zeichnet es nur 1/4 von oben nach unten. ist an meinem code was falsch ? mfg Kay
@Kay Das letzte Kommando müßte korrekt A = &H0BAF (175) lauten, sonst hast du eine Leerzeile. Dein Problem mit dem 1/4 Bildschirm entsteht bestimmt durch eine falsche Schleife. Versuch mal folgende Schleife: Portc.0 = 0 ' RS auf low setzen für Bilddaten F = 31 'binär 0000000000011111 für Blau For R = 1 To 23232 A = F Gosub 16 Next R Portc.0 = 1 'RS high MartinK
@MartinK also mit der schleife gehts auch nicht. da kommt die Fehlermeldung : Value doesn´t fit into byte ---> bei For R = 1 to 23232 wenn ich keinen farbverlauf will, dann kann ich doch normalerweise nur die schleife nehmen, die du im obern Post geschrieben hast oder ? mfg Kay
@MartinK habs hinbekommen. musste R als Word definieren. jetzt habe ich einen wunderschönen blauen screen. sehr gut. denkst du es wäre auch machbar, Bilder auf dem Display mit Bascom darzustellen ? mfg Kay
@MartinK hast du vor, das display mit Bascom per SPI anzusteuern ? ich denke mir die geschwindigkeit des SoftSPI kann zwar nicht mit dem des Hardware SPI des AVR mithalten, sollte aber dennoch schnell genug sein, um einen kompletten Screen in sehr kurzer Zeit zu beschreiben. Und das gute an SoftSPI ist ja, das man jeden beliebigen PIN als SPI Interface konfigurieren kann. mfg Kay
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.