Announcement: there is an English version of this forum on @Kay: Schreibst Du unter 2 Nicks, oder wieso kenn ich Deinen letzten Post schon: http://www.mikrocontroller.net/forum/read-4-243641.html#257716 ??? Zu Deiner letzten Frage: > denkst du es wäre auch machbar, Bilder auf dem Display mit > Bascom darzustellen ? Was sollte dagegen sprechen? Das ist fast schon wie: Denkst Du ich kann mit dem Messer ein Brot schneiden? Meinst Du Luft ist zum atmen da? War die Frage ernst gemeint, oder rhetorisch? Meinst Du, ob es für DICH machbar wäre? Verlier den Mut nicht, aber ließ bitte ein wenig im Datenblatt. Grüße, -- Outstanding ---
@Kay SoftSPI dürfte das gleiche wie Shiftout sein. Mit Bascom werde ich mich sehr wahrscheinlich nicht weiter beschäftigen, weil ich momentan einen M32C (Renesas) programmiere, und da ist nur C angesagt (obwohl ich Basic eigentlich ganz gut finde) Bilder auf dem Display darzustellen ist kein Problem, schau dir mal in diesem Thread die Artikel von Fabian Thiele (ape) an. Bascom unterstützt ja auch die serielle Schnittstelle. MartinK
@MartinK ich werde mal sehen, ob ich das display mittels C ans laufen bekomme. danke für Deine Hilfe @all habe das Display an einen Mega16 mit 16Mhz folgendermaßen angeschlossen: LCD --------- AVR DAT MOSI PB5 CLK SCK PB7 CS SS PB4 RESET OC1B PD4 RS OC2 PD7 da ich mit C noch nicht viel gemacht habe, würde ich gerne wissen, ob es reicht in der lcd.h die Definierung der Ports zu ändern und in der makefile den mega16 zu konfigurieren ? mfg Kay
@ Kay: Nein das reicht nicht. Die Sourcen gehen davon aus, dass alle LCD Signale an den gleichen Port angeschlossen sind. Also warum nutzt du nicht auch Port B für RESET und RS? Ansonsten musst du die Port-Zugriffe umschreiben
@Simone: habe jetzt den PortB für das Display genommen. DAT = PB5 CLK = PB7 CS = PB4 RESET = PB3 RS = PB2 hab dann in der lcd.h die Pins so konfiguriert und den mega16 im makefile eingetragen. nur leider geht garnichts. ich denke, ich werde den mega16 mal tauschen. mfg Kay
@The Daz: könntest Du mir bitte deinen Mega16 Code für das display zukommen lassen ? mfg Kay
@Kay, Obacht ! Beim Mega16 liegt der PWM (OC2) Ausgang auf PortD Pin 7. Daz
@The Daz, danke für den code. hab meinen mega16 nun genauso beschaltet, wie in der lcd.h beschrieben ( bis auf PWM ). Hab alle Leitungen überprüft. Aber auf dem Display erscheint nichts. Das Display muss aber in Ordnung sein, denn wenn ich das Display mit Bascom programmiere, funktioniert es ( bei Bascom benutz ich nur keinen SPI Port ). mfg Kay
@all wieso wird in der lcd.h MISO definiert ? ich dachte, man benötigt nur MOSI für die Dat Leitung. mfg Kay
MISO ist nur der Vollstaendigkeit halber da, wird aber tatsaechlich nicht gebraucht (Zumindest nicht in diesem Fall). Ich hab selbst hin und wieder Probleme, weil die LCD-Initialisierung nicht hinhaut. Vor allem, nachdem ich den assembler code aus Christians Beispiel noch ein bischen auf performance getrimmt hatte. Das scheint eine enorm Empfindliche Sache zu sein. Vielleicht reichen ein paar zusaetzliche NOPs um das Display bei dir ans Laufen zu kriegen. Nimm vielleicht mal Christians Original-Code, verschiebe den Font ins Flash (PROGMEM) und probiers nochmal.
@The Daz danke für die hilfe. aber ich glaube, ich muss mich jetzt erstmal intensiv mit C beschäftigen, weil ich davon nämlich so gut wie garnichts verstehe. Hab zwar im Tutorial was zu Progmem gefunden, weiß aber immer noch nicht, wie ich den Font ins Flash schieben soll. Sollte es dann doch irgendwann klappen, melde ich mich. mfg Kay
So, wenn ich den SPI double speed mode waehrend der LCD Initialisierung abschalte und hinterher wieder ein, klappt die Sache wunderbar. Der Testaufbau auf nem Steckbrett scheint nicht das Gelbe vom Ei zu sein.
Hallo, ich habe nun endlich auch mein Display (LS020) bekommen. Nachdem ich aber mehr bei den PIC zuhause bin, habe ich Christians *.asm Code versucht zu portieren. Leider hakt es an irgend einer Stelle und ich bin an der Fehlersuche. Dabei bin ich auf ein paar offene Fragen gestoßen. Zum einen erlaubt es der PIC die Clock-Polarität einzustellen (Idle = Low/High), d.h. Invertierung. Zum anderen muss ich angeben, wann die Daten an SDO angelegt werden (Fallende/Steigende Flanke). Desweiteren habe ich nirgendwo gefunden, ob MSB first oder LSB-first gesendet werden muss (vielleicht bin ich auch blind :)). Beides konnte ich aus dem Code und ermangels an AVR-Kenntnissen nicht herausfinden. Auch Martins BASCOM-code hält sich zurück. Sein Shiftout sieht so aus: Shiftout portx.x, porty.y, A, A Dabei sollte lt. Dokumentation gerade der vierte Parameter festlegen wie gesendet werden sollte, der Dritte die Daten, also ?? Ich habe meinen PIC-code (Auszug aus einem größeren Projekt) als Attachment angehängt. Kann mir jemand von Euch helfen? Gruß Mario
Hallo Mario, das SPI musst du beim AVR auch entsprechend konfigurieren -> Datenblatt könnte dir helfen. Aber am besten schaust du dir die Screen-Shots auf der Reengineering Seite an. Da kannst du folgendes sehen: a) MSB first b) Daten anlegen mit der fallenden Clock Flanke (übernahme im Display mit der steigenden) Achte auf die CS Ansteuerung. Die ist kriegsentscheidend. Ist ganz schön blöd vor so einem leeren Display zu sitzen....
Hallo Superuser, danke für die Antwort, damit sind schopn mal einige meiner Fragen geklärt. Das langwierige Durchstöbern der AVR Datenblätter wollte ich mir sparen, das Wissen sollte wohl da sein. Ich habe mich auch an dem Screenshot vom Reengineering orientiert, demach ist die clock-polarity auch festgelegt, nur leider wusste ich nicht ob da eine Invertierung zwischengeschalten ist, bzw. was welcher Leitung entspricht ... (RS/RESET/CS) Der Sarkasmuss am Ende motiviert mich leider nicht, aber stimmt, Fehlersuche ist so ziemlich das nervigste .... Aber eigentlich bin ich auf der Suche nach jemandem der mal schnell einen Blick auf den Source-wirft. Vier Augen sehen mehr als zwei, etc. Und vielleicht gibts auch noch einen anderen, der ausser am AVR auch an einem PIC-code interessiert ist. Mario
Hallo, wie steure ich dieses S65 Siemens Display an? Geht dies über I2C Bus oder SPI Bus? Woher bekomme ich ein Beispiel wie man so was ansteuert? Brauche ich da noch andere Spannungen?
HscH fang am besten mal oben an zu lesen, all deine fragen wurden schon zich mal beantwortet
um zu sehen wie man sowas ansteuert kann man sich die alte glcd library für das Nokia 6100 Display anschauen die war noch in C. Die hatte ich auch mal nach Codevision portiert, aber dann doch mit Winavr angefangen wegen der besseren neuen Library. Ich hab auch mal 3 Displays bestellt und werd mich wohl dran machen die glcd Library in Codevision bzw. ANSI-C kompatiblen C-Code umzuwandeln. Sowas in Assembler programmieren macht kaum noch Sinn, da die Compiler heutzutage doch recht Codeeffizient sind. Die Ansteuerung selbst gibts sowieso keine Geschwindigkeitsprobleme, wenn man icht grade 3D-Ballerspiele programmieren will. Problematischer ist eher der hohe Speicherbedarf für die Fonts. Allein zum Testen reicht normalerweise glcdinit da sollte das Display schon die Farbe wechseln, wenn es erfolgreich war, so zumindest beim Nokia Display
Hi, > Sowas in Assembler programmieren macht kaum noch Sinn, > da die Compiler heutzutage doch recht Codeeffizient sind. Täusch Dich mal nicht. Da der GCC ein Allrounder ist und nicht für den AVR optimiert, produziert er manchmal Code, der ein erblassen läßt. Ein PORTD|=0xFF generiert bei O3 z.B.: in R24, PORTD ldi R24, 0xff out PORTD, 0xff Da haut's einen schon um. Zudem ist gerade sowas wie Scrolling und schneller Bildwechsel sehr empfindlich (Ruckler). Wieso sollte man die GLCD wieder nach C übersetzten? Ich denke die läßt sich problemlos gegen ein C-Programm linken? Grüße, André
Es gab 3 wichtige Gründe warum ich die GCLD in Assembler portiert habe: 1.) ich wollte eine echte Link Library bauen. Das wäre auch in C gegangen, aber wenn man es eh einmal macht dann möchte man ja auch gleich mehrere Vorteile haben, und so kommen wir zu den 2 anderen Vorteilen 2.) die ASM GLCD benötigt für mehr Funktionalität ca. nur 50% an Flash ! Es zeigte sich also sehr wohl das der Mensch bei weitem besser optimiert als der Compiler. Und gerade beim WinAVR GCC sind einige Stellen die er bei weitem besser hätte optimieren können. Ich habe in den letzten 20 Jahren einiges an Compiler benutzt und muß sagen das der GCC bei weitem einer derjenigen ist die nicht so gut optimieren. Diese Aussage soll den WinAVR GCC nicht diskretitieren, denn als eine freie Alternative entwickelt von Enthustiasten ist der GCC eine sehr stabile Entwicklungsumgebung. Die letzendlichen Resultate sind: 4500 Bytes an Code für die alte C Version 2800 Bytes an Code für die neue ASM Version, wobei diese aber auch mehr Funktionalität besitzt. 4500 Byte an Code in der C Version, egal welche Funktionen man benutzt. 600 Bytes an Code in ASM Version wenn man nur die nötigsten Funktionen braucht. 3.) die Performance der ASM Version ist ebenfalls bis zu 5 mal besser. Dies hat 3 Gründe: a) die ASM Version geht mit den Registern und Paramatern wesentlich optimaler um. In C sind defakto alle Parameter immer 16 Bit breit auch wenn man nur uint8_t benutzt. Die Asm Version benutzt nun die unbenutzten Register die durch die Aufrufkonventionen vorgeschrieben sind als lokale Variablen. b) die ASM Version ist so konstruiert das die meisten Aufrufenden Funktionen wissen welche Register in den aufgerufenen Funktionen benutzt werden. Ich habe die Register also so verteilt das zb. sehr wichtige Funktionen immer die gleichen Register benutzen und die übergeodneten Funktionen diese Register nicht benutzen. Ergo: es werden wesentlich weniger PUSH/POPs benötigt. c) viele grafik Funktionen wie Linien/Kreise/Ellipsen und Fonts können in Assembler ganz bestimmte Möglichkeiten der CPU benutzen die so in C garnicht verfügbar sind. So zum Beispiel rechnet die Linienfunktion mit 24Bit Integer statt mit 32 Bit Integern in C. Es macht also aus Sicht der Performance und Resourcenverbrauch sehr wohl einen gewaltigen Unterschied aus. Es gibt aber auch Nachteile: 1.) C ist portabler, und gerade die GCLD wurde nun schon auf den PIC, MSP etc. portiert. 2.) Assembler ist wesentlich schlechter wartbar 3.) Erweiterungen von neueren Displays sind in der C Version viel schneller umzusetzen. 4.) die Trennung von HAL und TopLevel Schnittstellen ist in C einfacher. Gruß Hagen
@Hagen genau ähnliche Argumente sehe ich auch. Der AVR-GCC wird von mir nur für das eigentliche Programm benutzt. Die Libraries (MMC, LCD, ...) sind meistens in ASM und werden gegen den C-Hauptteil gelinkt. So kann man den Vorteil beider Welten nutzen. - Höhere Geschwindigkeit. - Minimaler Code (gerade für kleine AVRs). - Dank des Linkers nur Code, der auch benötigt wird. - Schnelle Entwicklung und einfache Wartbarkeit des C-Hauptteils. Ebenso wie Hagen versuche ich PUSH und POP zu vermeiden, indem die Register optimal ausgenutzt werden. Sind ja genug da ;-) Einer der großen Nachteile ist allerdings die schlechte Portierbarkeit. Da ich mich aber nur bei den AVRs wohlfühle (und selbst die mit ihrem IO-Zugriff etwas konfus sind - Historie?) trifft mich das nicht so. Ein anderes LCD? Einfach eine andere (sowas ist relativ schnell portiert) LCD-Lib linken und gut ist - vorrausgesetzt die Funktionen sind gleich. Zudem frag ich mich, warum der AVR-GCC mit O0 fehlerhaften Code (bezogen auf IO-Funktionen) erzeugt. Aber das steht wohl auf einem anderen Blatt. Er ist jedenfalls für Entwickler der beste Freeware-Compiler (wohl auch der Einzigste, oder?). Wenn man erstmal gechecked hat, daß O2(?) mindestens Pflicht ist, geht der Rest relativ locker von der Hand. Grüße, André
>> Ein anderes LCD? Einfach eine andere (sowas ist relativ schnell >> portiert) LCD-Lib linken und gut ist - vorrausgesetzt die >> Funktionen sind gleich. Tja, wenn man die Libs komplett austauschen kann dann ist das noch ok. Aber im Falle der GLCD entsteht ein spezielles Problem. Die sagen wir mal HighLevel Funktionen wie Fonts, Linien, Kreise etc.pp. graifen optimiert auf spezielle HAL-Funktionen zu. Leider stelen diese eben auch eine Funktionalität extra zugeschnitten auf den Display Controller zu Verfügung und sind in der ASM Version eben nicht strikt von den HighLevel Funktionen getrennt. Das wieder auseinanderzuklabüsern ist doch recht schwierig. Ansonsten ist der WinAVR GCC eine recht passable Alternative zu purem ASM oder eben teueren Compilern. Gruß Hagen
Naja, ich hab auch eigentlich einen richtigen Compiler gemeint. :-) Was da rauskommt ist oft nicht mehr viel zu optimieren. Der Assembler Code ist halt immer schwierig zu portieren.
@Hagen > C ist portabler, und gerade die GCLD wurde nun schon auf den PIC, > MSP etc. portiert. Hast du für den MSP430 einen Link? MartinK
@MartinK: Nein habe ich nicht, ich weis halt durch EMails das einer es portiert hat und wegen par Problemen bei mir nachfragte. Gruß Hagen
Hallo, ich habe gesehen, dass mein Hilferuf bzgl. des PIC-codes zwar noch keinen Hinweis auf einen Fehler gebracht hat, aber vielleicht hat ja einer der den Code heruntergeladen hat das Display zum laufen gebracht damit. Würde heissen, meins ist kaputt, bzw. eine Leitung ist nicht durchkontaktiert (Habs zwar schon geprüft, aber ...). Also Erfolgsmeldungen auch hier posten - schließt für mich eine Fehlerquelle aus - Danke! @Martin: Warum schaut Dein BACOM Shiftout so aus? Shiftout portx.x, porty.y, A, A Vierter Parameter sollte aus {0,1,2,3} sein. A sind aber die Daten? Gruß Mario
Hallo, Nachtrag zu meinem vorangegangenen Post. Ich habe nun die Sourcen nach einer Woche nochmals durchgesehen und entsprechend dem Kommentar von SuperUser angepasst. Die Leitungen (CS, RESET, RS) sollten nun auch soweit alle richtig sein- vorausgesetzt ich kann die *.asm Befehler für den AVR richtig deuten. Auch das SPI-Timing sollte passen. Ein paar andere dumme Fehler sollten nun auch draussen sein. Leider funzts nachwievor nicht. Anbei die neuen Sourcen. Vielleicht funktionieren sie bei jemandem anderen, dann wirds eng für mein Display - also vielleicht doch "tot"? Gruß Mario
Hallo zusammen! Super, endlich hat es geklappt! CKE-war falsch gesetzt. Zusätzlich hab ich noch ein sauberes RESET nach Martin's BASCOM-source eingebaut. Manchmal hilft es einfach zu schreiben das es hakt, dann bekommt man die Idee wo's noch haken könnte. So jetzt überflute ich das Forum nicht mehr mit meinen Problemchen. Gruß Mario
Poste doch mal dein Programm, dann haben alle was davon
Hi, verkauft jemand so ein Grafikdisplay von SIEMENS S65?
Hi, ein gewisser Herr 'eBay' hat sowas von viele. Der gibt bestimmt welche ab: http://search.ebay.de/search/search.dll?sofocus=bs&sbrftog=1&catref=C6&from=R10&sbrbin=t&satitle=s65+%28LCD%2CDisplay%29+-Folie+-Schutz*&sacat=48187%26catref%3DC6&bs=Finden&fsop=3%26fsoo%3D1&coaction=compare&copagenum=1&coentrypage=search&sargn=-1%26saslc%3D3&sadis=200&fpos=Postleitza&sascs=2&ga10244=10425&ftrt=1&ftrv=1
DEAR SALES, I WOULD LIKE TO REQUEST YOUR BEST PRICE AND LEAD TIME TO ORDER 4100PCS LS020 COLOR DISPLAY SIEMENS PLEASE ANSWER ME BACK AS SOON AS YOU CAN. THANK YOU SO MCUH HELLEN PAGANI hellen@netcondigy.com.br 55 11 4996-7205 5511 4996-7203 www.netcondigy.com.br
Das ist mir schon klar, dass ich bei Ebay diese Displays erwerben kann. Aber dort erhalte ich nur Displays ohne Anschlusskabel oder Stecker die zur Platine führen. Ich weiss halt nicht wie ich an dem flachen Kabel was anlöten kann. Deshalb frage ich hier in diesem Forum ob jemand ein Display verkauft, mit dem ich gleich loslegen kann.
An den Displays sind Kontakte im 1,27mm Raster ist ja wohl kein Problem da nen paar Drähte dran zu löten...
@DerMax Doch... es soll ja Leute geben, die SMD per Dachrinnenloeter versuchen zu loeten ;) Gruss
@DerMax, Der abstand ist 1,5mm, nicht 1,27mm @Hsch: Eine Platine(oder Fertiges Modul) wird ab übernächste verfügbar sein. Grüße Mark,
Hi Mark, ja was soll denn dieses Modul kosten? Ist es ein Modul ohne Coontroller?
Hallo, ich habe heute ein LS20xx Display bekommen, wie sieht das mit der Spannungsversorgung aus? Sind 3,3V zuviel oder noch gerade so in ordnung?
Hallo Freaks, Ich habe mal ein bischen recharchiert und da ein Datenblatt von einem TFT Display gefunden was bestimmt den gleichen controller (LR38825+LH169C) drauf hat wie das LS020. Für Cellular Phones werden diese oder aber der LR38826 eingesetzt, die zu dem LS020 passen würden. Nu aber zum Eigentlichen... Versucht mal folgende shut down sequence: 0xEF00,0x1B04,0xFEFE,0xFEFE,0x7E04,0xE304,0xE404,0xE201,0x8000,0xE001,0x 7F01 5µS (MIN) 0xE000,0x7F01 5µs (MIN) 0x0101 Nach der Sequence werden bei meinem Display alle Pixel weiß, und nach Abschalten der Spannungsversorgung bleibt es unverändert (Kein Verschwimmen der Pixel oder so zu erkennn). Scheint also zu funktionieren. Ihr könnt ja mal die Pegel etc. checken ob die Abschaltung auch elektrisch am Interface ok ist. Ich hab dazu jetzt keine Nerven. Ich habe nen Kumpel der bei Sharp arbeitet, vielleicht bekomm ich noch mehr raus. Viel Spaß beim probieren :D Gruß Joedi
@Jens, ich hab mein LS020 gemiiensamt mit dem PIC an eine Lithium-Knopfzelle gelegt - direkt ohne Pegelwandler etc.. Lt. Multimeter (ist nicht sehr genau) ist die Spannung 3,3V. Funktioniert prima. Es gibt da aber ohnehin zwei Spannungen. Der Logik-Pegel wird auch in Christians Schaltung von 1V8 auf 2V9 gelegt. Die meisten Controller Vertragen aber bis 3.3/3.6V. Den 2V9 sollte man nicht über 3.3V anheben (lt. Kommentar in Martin's BASOM Source). Warum, wieso?? @ThJoedi, danke. Werde mal ausprobieren ob es funktioniert. Kannst Du die Datenblätter zu den Controllern ins Forum stellen? Gruß Mario
sollte natuürlich "gemeinsam" heissen und nicht ... ja was auch immer.
Hallo! Kennt einer einen Seriösen eBay oder normalen Shop? Suche schon seit zwei Wochen nach einer guten Quelle. Habe aber nur abzocker gefunden. Brauche 8x Stück für mein Mischpult. www.ucapps.de mfg KennyOswald
MartinK >>EF90 0000 nach der Initialisierungssequenz auf dem Bildschirm >>nichts erscheint. (in deinem Asm-File steht dazu: I think not >>necessary...) Genau dieser Fehler hat mich auch ein paar Stunden Fehlersuche gebracht!!! Mein Display ist ein LS020B8UD05 (braun) und hat ohne EF90 0000 am ende der Init auch nichts angezeigt. ##################################### Könnt man im PDF mal drauf hinweisen. ##################################### Nebenbei nutze ich das Display an einem MSP430 bei 3V, noch per Soft-SPI. Vielen Dank allen die es mir ermöglicht haben dieses Display zu nutzen, besonders Christian!
@Rainer Verstehe ich nicht. Meinst du den original Code? Da steht zwar der Kommentar, aber die Sequenz wird trotzdem zum Display gesendet. Wie kommt es zu diesem Fehler?
@Superuser ich habe meinen eigenen Code für den MSP430 geschrieben und zwar nach dieser Seite: http://www.superkranz.de/christian/S65_Display/DisplayProgramming.html Dort fehlt hinter INIT3 das "EF90 0000", ebenso in dem PDF das ich hier mal runtergeladen habe.
@ThJoedi Die shut down sequence funktioniert bei mir. Allerdings liegt danach der Stromverbrauch noch bei etwa 50 uA. MartinK
Hy Leute, Hab das PDF Upgedatet also es ist jetzt wieder auf dem neusten Stand. Auch das mit dem "EF90 0000" am Ende der INIT3 wurde korrigiert. Mfg. Lightning
Hallo, kann mal einer die Dicke des Displays ausmessen? (inkl. Kunststoff-Teil). Die Gesamtmaße habe ich aus dem Bild auf Christians Seite rausgemessen: Über alles: 39 * 56mm Aktives LCD-Feld: 31 * 42mm Vielen Dank, Stefan
@Stefan Kleinwort Die genauen Maße stehen ja im PDF. Die Dicke ist 3,60 mm Mfg. Lightning
@Lightning: Vielen Dank! Ich hatte natürlich nur im alten pdf geschaut ... oh mann ... Gruß, Stefan
@MartinK: Mit der Power down sequence wird ja bestimmt nicht der ganze controller abgeschaltet sondern nur die LCD glass driver. @All: Der Controller des LS020 ist ein Sharp LR38826. Die power off sequence ist vom LR38825+LH169C. Es könnte sein dass einige register miteinander komatibel sind. Ich bleibe dran.....
Hab mal angefangen mit der Initialisierung mit dem AT91SAM7 aus dem Oszi Ist das korrekt, daß RS während der ganzen Initialisierung high ist? Welcher SPI-Mode ist der beste 0,1,2 oder 3? Verändert sich das Display während/nach der Initialisierung wie auch das Nokia Display, so daß man sieht, ob man erfolgreich war? Liefert das Display auch igendwelche Daten zurück?
irgendwie fehlt was. wollt schreiben auf dem Oszi siehts schonmal ganz gut aus aber Display tut nichts
Nach der Initialisierung zeigt es beim ersten mal normalerweise bunte Zufallsmuster. Am besten du machst noch einen clear-screen mit einer nicht weissen Farbe, dann siehst sicher du ob es geht.
Hallo Smartie, hatte zunächst auch Probleme, da ich den Code auf den PIC portiert habe (Code siehe weiter oben im Thread). Schau am besten in Martin's BASCOM-Basic Source. Der ist weitgehendst selbsterklärend. Aber Achtung beim Nachbau. Das CS-Signal ist entscheidendend, also vorerst nicht "optimieren" !! Das hat mich einiges an Zeit gekostet :( Gruß Mario
das CS macht der ARM ja alleine. Das Nokia Display ändert die Farbe nach der Initialisierung da kann man gleich sehen daß man erfolgreich war, deswegen meine Frage, ob das Siemens das auch macht. Wann genau zeigt das Display die Zufallsmuster, erst nach allen drei Init-Sequenzen oder schon vorher?
Für die controller gibt es doch datasheets zum runter laden, oder? Kann man die restlichen Funktionen nicht aus den datasheets entnehmen? (z.B. power down)
Von Sharp hab ich was gefunden steht aber nicht viel drin: http://sharp-world.com/products/device/ic/pdf/lr38826_e.pdf Epson hab ich nur einen TFT Controller gefunden das ist der S1D19105 http://www.epson-electronics.de/upload/PresidioIndustries/product/Semiconductors/LCDController-Driver/SingleChipTFTLCDDriver/S1D19105_TM_rev1_1.pdf der S1D15G10 hat nur 132x132 und ist kein TFT http://www.epson-electronics.de/upload/PresidioIndustries/product/Semiconductors/LCDController-Driver/SingleChipPassiveLCDDriver/S1D15G10D08BE_TM_MF1493_03.pdf aber komplettes Service Manual vom S6 hab ich gefunden: http://www.siediyer.com/Doc/x65SRD.pdf Da steht drin daß die verschiedenen Displays Hardwarecodiert sind also irgendwo wohl Brücken gesetzt und die Software demensprechend das Display nimmt. Dann dürften die aber auch im Handy nicht untereinander tauschbar sein.
Natürlich kann man nicht mehr verlangen, dass man sich den ganzen Thread hier durchliest... Aber neues habt ihr bis jetzt leider noch nicht ausgegraben :-( Die verschiedenen Display's werden an Pull's in den Display's unterschieden. Die SW findet so heraus welches Display angeschlossen ist und benutzt dann den entsprechenden Treiber. D.h. ein Phone unterstützt jedes der Displays.
Naja wird halt auch schnell unübersichtlichg so ein Thread. Hab mal in das Datenblatt von dem Hitachi-Chip reingeschaut, das scheint eine komplett andere Kommunikation zu sein. Kommt immer erst ein Startbyte, wo auch das RS mit drinsteckt und dann Daten und alles 8-Bit-Weise.
Den Treiber Code kannst du ja runterladen und dir anschauen. In diesem Fall reiner C-Code
Nochmal eine frage, Kay Pohl hat geschrieben das der Bildaufbau 2-3 sekunden dauert bei 16 mhz - ist das normal oder ist das nur bei basic so? :P Das ist ja für eine echte Anwendung unzumutbar, was für "framerates" haben die anderen denn so hin bekommen? Ich hab mir überlegt das Display in verbindung mit einem ARM für flüssige Animationen zu verwenden, der ARM wäre ja schnell genug - könnte das gehen oder soll ich das lieber sein lassen? Ansonten ist mir noch das display von http://www.shop.display3000.com/ aufgefallen, ich hab zwar erst gedacht das wäre ein nokia 6100 display aber das scheint ja 16 bit anstatt 12 bit farbe zu haben... hmm
@Lupin: bei display3000 sind doch Nokia 6100 Displays - Mit Epson Chipset.
Hi, ich will ein scrollbares menü machen deshalb interessiert mich die benötigten Bit/s vom µC auch. 16 bit 132 rows 176 cols = 371712 bit pro frame. Wenn der maximale SPI Takt des Displays 13 MHz ist ist die max. Bildfrequenz 13e6/371712= 34,97 Frames/s Mit nem schnellen Controller kein Problem mit nem ATMEGA wirds schwierig da SPI max 10 MHz
"mit einem 16MHz AVR (8 MHz SPI) kann man den kompletten Bildschirm in ca. 50ms schreiben" schon aber du hast ja auch noch andere Aktivitäten des µC. Ausser du hast schon die ganzen Bildinhalte in einem externen Speicher und schaufelst sie nur noch ins Display.
Controller mit mindestens 371712/8=46464 Byte RAM gibts von Atmel nur als ARM. Ob das Sinn macht, den spärlichen RAM-Speicher so zu mißbrauchen, da kann man sich drüber streiten. Scroll-Menüs kann man auch textbasiert realisieren, hab ich bei dem Nokia-Display auch gemacht mit nem 16-MHz-AVR. Oder alles aus einzelnen Bitmaps zusammenbauen, die man im Flash ablegen kann. Außerdem kann man sich bei der Grafikausgabe auf einen Frame beschränken, der kleiner ist als das eigentliche Display.
Am besten ist es wenn man sich auf klassische Konsolen-methoden wie Hintergründe, die aus einzelnen Blöcken zusammen gesetzt sind, beschränkt und nur in Ausnahmefällen sprites zeichnet, das könnte man dann doch alles direkt ins display zeichnen und die grafiken vom flash laden, oder? Wenn man es dann dynamischer braucht muss man sich halt Speicher reservieren. Nun frag ich mich aber wie die 2-3 sekunden für den Bildaufbau zustande gekommen sind.
So, habe mein Display bekommen und es hat sofort funktioniert. Also vielen Dank an Christian für die tolle Arbeit die du geleistet hast!!!
Hat jemand funktionierenden Quelltext für Hardware-SPI, MSP430 und LS020? Bis jetzt klappt es bei mir immer noch nur per Software-SPI, habe alles ausprobiert und stehe auf dem Schlauch...
Salve, zuerst mal herzlichen Dank an Christian. Wirklich tolle Arbeit! Hab gestern von Cellow mein Display bekommen (LPH88, steht direkt drauf). Ich glaube aber, es hat durch den Versand was wegbekommen. Eine Ecke ist angeknickt (war auch nur in Luftpolsterfolie verpackt, ohne Knickschutz). Dummerweise hab ich das erst gemerkt, nachdem ich es angelötet und getestet hatte. Folgender Defekt tritt auf: In der unteren Displayhälfte ist jede Zweite Zeile weiß, egal welche Daten ich dort in den GRAM schreibe. Mir fiel auch auf, daß die erst noch etwas bunt sind, und erst dann richtig weiß werden (nach 1-2 Sekunden Betrieb). Ich vermute ganz stark, daß durch den Knick die Treiberleitungen beschädigt wurden. Die init-Routinen hab ich von Christian übernommen, und auch schon verändert. Die defekten Zeilen sehen so aus wie wenn ein Teil des Displays nicht gescannt wird (kann man in der Init ja festlegen). Falls jemand schonmal etwas ähnliches erlebt hat, wäre eine kurze Nachricht sehr nett. Ansonsten muß ich sehen, ob Cellow das Display mit Lötzinn dran zurücknimmt. ;( Danke schonmal für Tips, Mark
Hi, im Anhang ein kleines Tool zum erstellen von 16 bit Farb defines aus der Windows Farbpalette. Man kann nur die Grundfarben oder die erste custom color zur Liste hinzufügen.
Zum Thema Hardware-SPI hatte ich auch mein Problem. Die Lösung: ich hatte nur gesendet und nicht gewartet bzw. abgefragt ob fertig. Hab dann nach jedem Word 15µs gewartet und dann hats auf Anhieb funktioniert.
Hab eine Platine gemacht, auf die genau das Sharp-Display passt, zwei Spannungsregler für 2,9V und LED-Spannung damit das Display mit 12-15V betrieben werden kann und Spannungsteiler für 5V Ansteuerung und Schalttransistor zum Ein- und Ausschalten der LEDs. Die Bauteile sitzen alle direkt in den Aussparungen des Displays, so daß die Rückseite plan ist. Anbei die Eagle-Dateien, Fotos (leider nur mit Webcam) und meine Demo auf dem Arm7 von Atmel AT91SAM7S256
Ich steuere das Display mit dem R8C an. Ich habe folgendes festgestellt: Wenn ich einen Bereich mit 0xef90 0x0504 auswähle, dann muss ich nun y1,y2,x1,x2 angeben und nicht x1,x2,y1,y2 wie im PDF steht. Ich gebe auch die Pixeldaten von links oben an zeilenweise nach unten an, im PDF ist es von links unten zeilenweise nach oben angegeben. Hat das auch schon jemand bemerkt ?
hab jetzt noch ein bischen das Timing optimiert und festgestellt, daß man bei der Initialisierung nach bestimmten Sequenzen dem Display ein paar µs Zeit geben muß sonst klappts nicht. Die Wartezeit nach SPI send hab ich jetzt bis auf 2 µs runtergeschraubt. Bin jetzt noch am überlegen, wie man die SPI noch optimieren könnte, weil ja immer 2µs gewartet werden muß. Ginge eigentlich nur über einen Software FIFO und ein Interrupt, der die SPI bedient, der müßte dann aber auch mit 1-2µs laufen. Hab noch schnell zwei kleine Routinen fillrect und rect geschrieben, kann ich mal posten falls es jemanden interessiert, ist aber nichts dolles. Verwende die embedded Workbench von IAR, war bei dem Bundle von MSC mit dabei für 149 Euro, ist aber auf 32KB Code beschränkt. Finde die zwar lange nicht so gut wie Codevision für den AVR aber man kann mit arbeiten.
@Smartie: schau mal im Datenblatt unter 29.6.3.4, Figure 29.7: die SPI_Schnittstelle des SAM kann selbstständig Delays erzeugen. Viele Grüße, Stefan
ich will ja grad keine delays. Ein Fillscreen hat fast 45 KBytes. Bei 2µs sind das bei 16 Bit SPI fast 100ms, die die CPU nur wartet.
ahhh ... ich hatte verstanden, dass das Display die 2us braucht, um korrekt die Daten annehmen zu können. Warum schreibst Du die Daten nicht in einen Out-Puffer und startest dann den DMA des SPI? Die Daten werden dann völlig selbstständig ausgegeben. Währenddessen kannst Du die nächsten Daten vorbereiten, in einem anderen Datenblock. Viele Grüße, Stefan
werd mir das mit dem DMA mal anschauen, bin halt noch ganz am Anfang mit dem Arm. Die 2µs braucht es nur bei der Initialisierung, beim Daten schreiben nicht. Hab auch grad nochwas rausgefunden: nach lcd_wrcmd(0xEF90); lcd_wrcmd(0x0504); lcd_wrcmd(0x0800+y1); lcd_wrcmd(0x0A00+x1); lcd_wrcmd(0x0900+y2); lcd_wrcmd(0x0B00+x2); funktioniert lcd_wrcmd(0x0504); lcd_wrcmd(0x0600+y1); lcd_wrcmd(0x0700+x1); nicht mehr richtig, es wird durch den Frame von vorher begrenzt, läuft also über. d.h mit der ersten Befehlsfolge wird definitif ein Clipping-Fenster gesetzt, was für alle weiteren Schreibbefehle gilt.
Hallo Freunde des LS020 Displays... Nachdem ich nun mehrere Display's in Betrieb genommen habe, musste ich noch einmal die INIT-Sequence ändern. Sonst scheinen einige Displays nicht stabil zu starten. Ich hatte erst Wackelkontakt vermutet bzw. Display beim Löten beschädigt. Allerdings hat sich mal wieder die Software als nicht perfekt erwiesen. Ich habe die Web-Page und die glcd upgedated. For den letzten Command (bedeutet vmtl. Display On) muss noch eine Wartezeit eingehalten werden. Tschüss und guten Rutsch Christian
Hallo täusch ich mich oder muss in LCD.asm in der send window write start sequence: nicht r24 stehen? Im orginal ist dort r30 angegeben.
da hast du wohl recht... Fällt hier aber nicht auf, da die Funktion nur einmal benutzt wird und beim init das window schon richtig gesetzt wird.
das LS020 ist wirklich ganz schön zickig... Im Prinzip läuft jetzt zwar alles bei mir, auch Hardware-SPI am MSP430, aber wenn ich was ändere dann klappt meistens nichts mehr. Software-SPI geht, Hardware-SPI mit 4Mhz geht auch, Hardware mit 2Mhz aber NICHT. Kann ja auch sein das ich irgendwo einen blöden Bug in meiner Software habe, aber so komisch hat sich bis jetzt noch kein Display angestellt. Trotzdem, wenn es klappt, dann ist es klasse. Nur eine Anwendung habe ich immer noch nicht gefunden :)
Angehängte Dateien:
-
board_V1.0.jpg
91 KB
Hallo Rainer, als Anregung (und 300'te Post in diesem Thread) hier mal ein Beispiel was ich gerade mit dem Display mache. Im grunde handelt es sich um eine mobiles universelles Gerät, z.B. zur Datenerfassung. Es unterstützt verschiedene Möglichkeiten zum Datenaustausch. Als User-Interface gibt es einen Drehgeber mit push-Taste, sowie zwei Tasten und/oder einem Ziffernblock (z.B. als Folientastatur) Visuell hat es das S65-Display sowie zwei LED's und einen kleinen Lautsprecher oder pieco. Das Gerät wird mit Akkus (LiIon/NiMh) betrieben, mit kompletter Ladeelektronik (für software gesteuertes Laden). Das Gerät lässt sich über eine Taste ein- und ausschalten. Im ausgeschalteten Zustand hat es einen sehr geringen Stromverbrauch, über eine externe RTC (mit Batteriespannung) läuft Zeit&Datum weiter. Das aufwändigste ist (wie immer) die Software Entwicklung. Insbesondere das User-Interface verschlingt sehr viel Zeit (und ich habe noch fast alles vor mir....) Daher ein Vorschlag: Ein grafisch-gesteuertes User-Interface wird wohl jeder brauchen, der mit höher auflösenden grafischen Displays arbeitet. Könnte man das nicht gemeinsam entwickelnt? Grüße und frohes neues Jahr 2006 Christian
Hallo Christian, Güte Idee, bin dafür ein standart library zu machen. Ich schreibe gerade mein grafik libraries, für alle displays. alles in standard C, also portierbar. nur die low-level routinen sind naturlich abhängig von der hardware. Meine HW targets sind: -Keil C167 -Keil C51 -Keil ARM -IAR MSP430 Hast Du einen vorschlag für ein algmeines interface? Grüße Mark de Jong,
Vielleicht etwas in der Art:
Steuerung über Drehgeber (drehen hoch/runter bzw. links/rechts
Auswahl push-Taste)
- Eine Display-Text Zeile als Menu (obere oder untere)
-> 1-4 Auswahlmöglichkeiten (li/re) (aktuelles invers dargestellt)
-> push-Taste wählt das Menu
- Ein Frame des Displays wird als Menue-Fläche definiert
-> Die Applikation muss diesen Frame immer neuzeichnen können, da
Display Inhalt ja mangels Speicher nicht gesichert werden kann
- In diesem Frame kann man ein Menu-Window (single select) öffnen
-> Anfangs rein textbasiertes Menu (hoch/runter)
-> natürlich sind sub-menues möglich
- oder in diesem Frame kann man ein Eingabe-Window öffnen
-> Zahleneingabe (mit Drehgeber support) Texteingabe?
.....
Moin Christian, eigentlich arbeite ich an etwas ähnlichem. Zur Zeit befasse ich mich hauptsächlich mit Grafik-Dateiformaten um Icons usw darstellen zu können. Habe mir ein Tool geschrieben das aus einer BMP-Datei ein Headerfile mit Farbtabelle für das LS020 und Bilddaten macht. Dadurch habe ich zwar nur 256 Farben pro Icon, brauche aber auch nur 1 Byte pro Pixel. Je nach Grafik bringt RLE-Codierung auch noch Platz. Dieses kann man dann leicht in seinen Quelltext einbinden. Für Zeichensätze benutze ich das XBM-Format da dieses eh C-Quelltext ist und sich leicht mit Gimp oder Editor bearbeiten lässt. Würde mich interessieren welche Wege ihr da geht.
Christian, habe mit gerade nochmal dein Board angesehen. Ist eigentlich genau das was ich auch brauche, nur mit einem MSP430 drauf :) Als nächstes wollte ich mich mit der SD-Karte usw beschäftigen. Eine Anwendung hätte ich auch dafür, nennt sich "Tagesgradzähler" und muß über mehrere Monate eine Wassertemperatur aufzeichnen und einen Tagesdurchschnittswert addieren. Ist eigentlich kein Problem, aber irgendwie bisher immer am Gehäuse und der Stromversorgung gescheitert. Mit einem AVR hatte ich es mal so gut wie fertig, aber dann wollte ich doch lieber ein Grafikdisplay anstelle von Text, bin auf MSP430 umgestiegen usw. Jetzt will ich Farbe und wahrscheinlich kommt dann doch noch etwas anderes...
Ich hab mir auch ein S65 display bestellt, ich habe vorgehabt JPEGs zu laden... das soll später mal teil eines kleinen Projektes werden. Die JPEGs liegen dann auf einer MMC karte. Den code zur Dekomprimierung hab ich schonmal auf einem GBA laufen gesehen, sollte also mit einen ARM mikrocontroller nicht so schwer sein.
Angehängte Dateien:
-
Display_S65.jpg
940 KB
Ich Experimentiere gerade am Ls020... mit dem TEST.C rum:
#include <inttypes.h>
#include "../glcd/glcd.h"
#include "../glcd/lfsr.h"
#include "../font/nums.h"
#include "../font/f9x14.h"
#include "../font/f15x22.h"
#include "../font/f8x11.h"
#include "../font/f8x8.h"
void demoScreen(void){
glcdSetOrientation(0);
glcdSetColor(0, SCREEN_COLOR);
glcdSetColor(1, BLACK);
glcdSetColor(2, GOLD);
glcdSetColor(3, RED);
glcdClearScreen(BLACK);
glcdSetFgColor(BLACK);
glcdSetBkColor(WHITE);
glcdFrame(0,0,130,175);
glcdFillRect(110,110,130,130,SCREEN_COLOR);
glcdMoveTo(10,10);
glcdSelectFont(f9x14, 0); // font is stored in FLASH,
demontrate read callback
glcdPrint("Siemens S65 LS020... \n geb 13.04.1966\n", 0);
glcdSelectFont(f9x14, 0);
glcdSetFgColor(BLUE);
glcdMoveTo(11,100);
glcdPrint("12345678901234567890",0);
glcdSetBkColor(RED);
glcdCircle( 80,80,10);
glcdLine(90,80,100,100);
}
int main(void) {
#define cnt 1
#ifndef USE_AUTOINIT
glcdDisplayInit();
#endif
glcdClearScreen(1);
// glcdDisplayOn();
uint8_t o = 0;
demoScreen();
while (1) {
}
}
Jetzt habe ich in der GLCD.inc
define ORIENTATION_DEFAULT ORIENTATION_270 or _90
#ifndef SCREEN_WIDTH
#define SCREEN_WIDTH 175 // Siemens S65
#endif
#ifndef SCREEN_HEIGHT
#define SCREEN_HEIGHT 131 // to (0,0,131,175) to
support hardware scrolling and splitting of display
#endif
#ifndef SCREEN_LEFT
#define SCREEN_LEFT 0
#endif
#ifndef SCREEN_TOP
#define SCREEN_TOP 0
#endif
#ifndef SCREEN_RIGHT
#define SCREEN_RIGHT (SCREEN_WIDTH -1)
#endif
#ifndef SCREEN_BOTTOM
#define SCREEN_BOTTOM (SCREEN_HEIGHT -1)
#endif
eingestellt und bekomme siehe Anhang , alles Spiegelverkehrt angezeigt.
Habe ich was vergessen ?
Und bei glcdSetOrientation(0); kann ich 1, 2,3 etc einstellen und
passiert. Ich wollte die Anzeige Quer verwenden.
Und was ich nicht verstehe -> glcdPrint("12345678901234567890",0);
wenn anstatt eine 0 -> eine 1 reimache wird das Bild immer wieder
aufgebaut. Warum?
Da ich nur wenig mit C - Gemacht habe, habe mit Bascom gearbeitet.
Sind Tips immer gut. Ein gutes Projekt!!
Hallo Rainer, dann könnte dieser Link für dich interessant sein... http://focus.ti.com/lit/an/slaa281/slaa281.pdf Heute würde ich den Atmega 128 auch nicht mehr nehmen, sondern einen ARM7. Mittlerweile ist aber zuviel Zeit in das Projekt geflossen um noch den µC zu wechseln. Ausserdem reicht er. Vorteile vom ARM sind: - mehr Performance - mehr Speicher - weniger Stromverbrauch - niedrigere Versorgungsspannung - nahezu gleicher Preis Den AVR habe ich genommen, weil es dafür soviel Software im Netz gibt. Und das ist immer noch ein gutes Argument für den AVR. Hallo Dirk, die glcd unterstützt derzeit nur eine Orientierung. Das liegt daran, dass der Display Controller lange nicht so flexible Addressierungs modi des Display-RAM's unterstützt wie der Philips Controller für die die GLCD ursprünglich geschrieben wurde. Zumindest sind mir bis heute nur die dokumentierten Modi bekannt. Also wenn du Lust hast, kannst du ja mal versuchen eine andere Orientierung einzubauen. Wenn ich mich richtig erinnere, gibt der letzte Parameter von glcdPrint an, ob die Daten aus dem Program-Flash oder dem RAM gelesen werden. Wenn du aus dem Flash lesen möchtest, musst du die Daten auch dort speichern, sonst ist nicht definiert was passiert...
ich finde das Board auch interessant,hab auch schon was ähnliches im Eagle angefangen. Würde es aber auch mit einem Arm7 machen, das Ding hat massig Speicher, RAM, USB und gibts auch mit Ethernet. Die Programmierung ist auch nicht so kompliziert. Da aber irgendwie jeder seinen Lieblingsprozessor hat, ist es vielleicht besser, entweder verschiedene Boards entwickeln oder ein Universal-Board mit aufsteckbaren Prozessoren machen, dann wäre jedem geholfen. Bei der Softwareentwicklung sollte alles modular sein, und möglichst universell für alle CPUs verwendbar. Mit nem ATMEGA und dem Nokia-Display hab ich mal nen Tempomat/Bordcomputer gebaut, der nur über einen Drehencoder mit Button programmiert und eingestellt wird. Da hatte ich zum Beispiel kurz Drücken für on/off, länger Drücken Geschwindigkeit übernehmen, ganz lang Drücken Menü.
Hello! Ich suche seit Lange ein gutes LCD-Display für mein GPS-Project, aber die S65-LCD wäre für mich die beste Lösung. In Ungarn kostet es etwa 30 EUR, aber es ist noch immer billig und leicht einholbar. Ich habe die Archive dieses Forums durchgelesen, aber ich hätte noch ein paar Frage, und ich bitte euere Hilfe bei diesen. 1. Wenn ich es gut verstanden hatte, Siemens herstellt S65 handys mit drei verschiedene LCD-Kontroller: das LS020xxx hat einen nicht gut bekannten Sharp-Kontroller, das LPH88xxxx hat den gut dokumentiert Hitachi HD66773 Kontroller, und L2F50xxx enthaltet einen Epson Kontroller, dieser letzter hat kein Datenblatt publiziert im Internet, aber Christian hat diesen an besten analysiert und dokumentiert. Wenn ich alle diese Type einholen könnte, sollte ich den Hitachi oder den Epson kaufen? Und wenn ich durch z.B. eBay kaufen möchte, und ich weiss nicht, welche ankriege, ist es 100%, dass ich es unabhängig von Kontroller benutzen kann? (Anders gefragt: Werden die Dokumentationen im Internet (forum, Christian's doc) genug z.B den Sharp-Kontroller zu Arbeit zu vermögen?) 2. Ich habe in Christian's doc gesehen, dass er 2,9V zum 1,8 und 2,9V pins bindet. Ist es gesund die 1,8V pin mit 2,9V zuliefern? In meinem Project gibt es ein 1,8V und ein 3,3V Spannungsquelle (TI TMS470R1B1M ARM7TDMI core prozessor). Wäre es tödlich, das Display mit 1,8V und 3,3V zu quellen? 3. Wenn ich gut denke, ich soll 15V zum Pin LED+ nur dann binden, wenn ich Background-Light möchte. Ist es so richtig? Wenn ja, hat schon jemand die Spannung-Storm Charakteristik dieser LED ausgemessen? Es wäre wichtig, wenn man einen Helligkeitregler aufbauen will. Danke für eure Hilfe vornüber und ich möchte vorwigend Christian und natürlich allen Lesern dieses Forums für die Forschung gratulieren die er und euch für die Erkenntnis der Functionalitäten dieses Displays gemacht haben. Grüsse Tamas aus Ungarn
Hallo Es wurde öfter in diesem Thread darüber gesprochen eine Platine für das Display zu entwerfen. Wollte mich erkundigen, ob daraus was geworden ist. LG Michael
Hallo Michael, Ich erwarte die Platinen Morgen. Sobald ich Sie getestet haben werde ich mich melden. Grüße Mark,
ich hab mir jetzt auch mal das display besorgt, ist ein LPH. die 2.9v sind bei mir 2.94 und die 1.8v sind 1.86 - also noch im grünen bereich oder? Beide spannungen werden aus 3.3v geteilt (einmal mit R1=10k und R2=7.5k und einmal mit R1=10k und R2=1k) Das ganze funktioniert natürlich nicht... ich benutze einen LPC2106 und bin mit dem SPI takt schon auf einen halben mhz runter gegangen aber das display zeigt rein gar nix an. In den Kommentaren bei der init sequenz steht zb sowas wie // start at 240ms Aber ich kann da nirgends einen delay aufruf über 240 ms finden - woher kommt diese zeit? Hab nochmal meine abgeänderte disp.c angehangen, ist fast genau so wie im Beispiel. Mein SPI ist übrigens als Master eingestellt, kein CPOL oder sonstige Einstellungen.
Im Beispiel sind der 2,9V und der 1,8V Anschluss beide an 2,9V gehaengt worden.
ja das ist aber bestimmt nicht so gut... werds trotzdem mal probieren
Hat nicht funktioniert, ich hab mal mein messgerät dazwischen gehangen (zwischen 2.9v und den versorgungs-anschluss am display) und der zeigt 0mA an - ist das teil kaputt? Ich war auch so schlau und hab mit meinem (billig)-multimeter gemessen ob es zwischen den pads am display einen Kontakt gibt... war vielleicht keine gute Idee :(
Noe, das ist kein Problem. Aber 0mA ist nicht gut. Ich finde deinen Spannungsteiler im kOhm Bereich aber ziemlich verdaechtig. Versuch doch mal das gleiche mit einem Teiler im wenigen 100 Ohm Bereich.
Mit welcher Spannung laeuft der uC ? Die Signale von dort sollten den 2,9V Level auch nicht uebersteigen. Hatte das zuerst bei meine LS Display vergessen, hat aber keine Schaeden hinterlassen.
hab nun einen mit 270 und 33 ohm gemacht - hat sich nix verändert
meine IO spannung ist 3.3v da habe ich keine Teiler... in der beispielschaltung wird auf 1.8v geteilt aber das sollte ja auch so gehen weil der IC ja mit 2.9v betrieben wird... oder?
Im Beispiel reduziert der Spannungsteiler die 5V Ausgaenge des AVR auf 2,9V. Wie gesagt, ich wuerde mal Spannungsteiler in die uC-Signale einhaegen. Probieren schadet ja nicht.
Hallo Lupin, das Display verträgt auch problemlos 3.3V denke ich. Ich hatte mal - versehentlich - es einige Tage mit 4.2V laufen ohne Probleme. Die Kommentare zu den delays in der Init-Sequence kannst du ignorieren. Also mein Vorschlag: Schliess es an die 3.3V ohne irgendwelche Teiler an und bringe die Software in Ordnung. Wenn es dann läuft kannst du dich um die Versorgungsspannung kümmern.
Hallo Lupin, kann das von Superuser nur bestätigen. Hatte es auch weiter oben im Thread schonmal geschrieben. Hab das Display am PIC direkt angeschlossen (LF-Typ). Betrieben wird alles mit einer Lithium Knopfzelle - die eigentlich 3.0Volt haben sollte. Mit meinem billigheimer Multimeter nachgemessen ergab 3.3V. Funktioniert wunderbar. Ich denke Du hast ein SW-Problem - war bei mir auch so. Du hast ähnlich wie ich Wahrscheinlich das Problem mit dem CS-Signal. Programmier das mal exakt nach der Vorlage nach! CS=SELECT, SPI_send, CS=DESELECT.
ich hab es sogar 1:1 übernommen, nur ein paar wenige Änderungen durchgeführt. zB hab ich das hier: lcd_comdat(cd1[j++],cd1[j++]); ... nach ... lcd_comdat(cd1[j],cd1[j+1]); j+=2; ...geändert weil die erste schreibweise undeutlich ist und compiler warnungen generiert. Das dumme ist ja, dass das Display überhaupt keine Antwort geben kann und man somit keine debug informationen haben kann. Ich hatte gehofft das man bei dem display den speicher irgendwie noch auslesen könnte oder so...
alles direkt an 3.3v - lief sofort :D Jetzt muss ich mir nur noch die Stromversorgung für LED beleuchtung basteln ;(
Hallo mario! Kannst Du Dein programm veröffentlichen? Wäre echt nett. Ich bastell noch an meiner Platine mit pic18f4550, es würde mir einiges an Arbeit sparen. mfg KennyOswald
Hi Lupin, wenn dein Controller PWM generieren kann empfehle ich die Schaltung von der web-page. Funktioniert super, Helligkeit kann per Software eingestellt werden etc.. Spule sollte natürlich etwas Strom können bzw. nicht zu grossen Widerstand haben.
Kenny, anbei der PIC-Port zum 16LF876. Hatte ich schon vorher in dem Thread gepostet, allerdings noch nicht die komplett fehlerfreie Version (siehe oben). Jetzt ist auch der Code für die Zeichenausgabe dabei. Ich hab den Code aus einem größeren Projekt herausgenommen, kann sein dass sich noch wo ein Fehler eingeschlichen hat. MPLAB simulierts jedenfalls anstandslos. Init, CLRSCR, shut_down sollten aber funzen (musste nichts verändern). Gruß Mario
Ja die Teile für die 15V habe ich mir schon bei reichelt bestellt, hab mir als Spule "09P 1,0M" geholt, ich hoffe die passt dafür... Ich weiss das conrad so blaue hat die gut zum strom erzeugen sind.
Hab gerade gemerkt, dass das LPH display auch ohne Versorgungs-spannung auskommt... ist mir aufgefallen als ich doch noch 2.9v spannung einbauen wollte - das display lief weiter und das bild sah sogar besser aus (bei 3.3v gab es schlieren...) Ich kann mir das nicht so ganz erklären, wird vielleicht durch RS eingespeißt, vielleicht hat der pin eine andere funktion? wenn ich meinen controller resete und den bootloader starte geht das display ausserdem aus, deswegen wird wohl irgendein port pin strom liefern.
Lieber nicht nach machen, eben wurde der controller warm und das display ist ausgefallen und wollte auch eine weile nicht mehr... :(
folgende Beobachtungen hab ich jetzt beim LPH display gemacht: - Display läuft auch ohne das die 2.9v und 1.8v pins verbunden sind und liefert ein gutes Bild - allerdings wird der controller irgendwie warm wenn man zu schnell reset-ed oder so - Bei 3.3v läuft das Display zwar gut aber wenn man einen harten reset durchführt sieht das Bild dann wieder schlecht aus. Erst wenn man die Spannung wieder weg nimmt ist das Bild wieder ok. - Bei 2.9v läuft alles optimal, die spannung für den 1.8v pin kann auch 3.3v sein
Das hört sich komisch an. Hat vmtl. mit deiner Schaltung und nicht mit dem Display zu tun... Könnte es sein, dass du das Display über die Interface-Leitungen versorgst (z.B. der RESET pin)? Den RS pin brauchst du bei diesem Display übrigens nicht anschliessen...
Ich bin gerade dabei die Hintergrundbeleuchtung zu versorgen... in der Schaltung ist die Diode BAT54 als ganz normale diode abgebildet, die hat aber 3 pins... wo genau muss ich die pins anschließen? bin zu doof dafür... Im datenblatt steht 2x Cathode und 1x Anode
Welche Ausführung hast du? Wenn du dir nicht sicher bist am besten nachmessen. BAT54 z.B. 1 Anode, 3 Cathode (eine Diode) BAT54A 1 Cathode, 3 gemeinsame Andode, 2 Cathode 2'te Diode (doppel-Diode= BAT54C wie BAT54A aber Dioden gedreht BAT54S jetzt sind Cathode und Andode zusammen an Pin3 -> Nachmessen!!!!
Can anyone help me? I try start LCD (L2F50) from ATMega16 but can't :( I don't understand German language :( May be exist work example?
@Spider84 Just follow Christian's link : http://www.superkranz.de/christian/S65_Display/DisplaySoftware.html When trying to use the code examples be aware the ATMega16 doesn't have enough RAM to hold the complete character set so you'll have to move it into the flash memory (PROGMEM).
This is the complete guide including schematics as PDF document. http://www.mikrocontroller.net/attachment.php/271299/Using+the+Siemens+S65+Display.pdf It's written in english so there shouldn't be a problem for you getting it done.
I already use this and tried to build. I tried to remove ASCII table and text output from code, leave only init functions and fill_screen(); I tried to use HelloWorldMega16 ASM code from this forum... DON'T WORK :( L2F50xxx has same pins name as "http://www.superkranz.de/christian/S65_Display/pics/Display_connect_small.jpg";?
Can't help without knowing a thing about your code. Please append and let's have a look. Did you check all voltage levels and connections allready ?
At last I tried to use http://www.mikrocontroller.net/attachment.php/259277/HelloWorldMega16.zip code. 0 = 0.00..+0.01 V 1 = +2.77..+2.80 V connected as: #define LCD_CS PB2 #define LCD_RESET PB3 #define LCD_RS PB4 #define LCD_MOSI PB5 #define LCD_MISO PB6 //Not Connected #define LCD_SCK PB7
I up level voltage and power of LCD to +2.85..+2.95 by changing resistors and for 1-2 sec LCD show diferent colour lines, pixels and other noise.
Hmm, you're not using the latest code release (still got an lcd.asm), right ? I recommend to download the latest version (no assembler code anymore) and change the makefile to compile the stuff for your ATMega16 first to make sure you're not missing any late updates. The pictures you've taken don't help debugging either. In case you didn't follow the reference design (is your uC truely running with 16MHz or is it using the internal oscillator ? please check your fuse settings), please try to draw a schematic and append it to your answer. Thanks.
Hi Spider84, i looked at your photos: Using such long wires it might be an option to reduce the clock speed on the spi interface. If you have seen something on the screen already (also if only for a few seconds), than you are very close to success. The diplay shows only something if the intitalisation was o.k. Try to reduce the speed/wire length. Also you can increase the supply voltage because the display is proven to run with 3.3V Regards SU
excuse me, my first sentence in the previous post is a little bit confused... to make it more clear: Your wires to the display are very long. That might yield to timing problems. Therefore i recommend to a) either reduce the SPI clock speed b) reduce the wire length In addition i agree with The Daz, use the latest code. The init-sequence has recently been changed to be more robust with different displays. It's o.k. if you exchange the lcd.asm file only. Regards SU
Angehängte Dateien:
-
LCDx65.jpg
160 KB
TD>I recommend to download the latest version (no assembler code TD>anymore) and change the makefile to compile the stuff for your TD>ATMega16 first to make sure you're not missing any late updates. Can you give URL or file name? I already download and many files and diferent versions. fuses = SUT=11 (No checks on PonyProg), CSEL=1111 (No checks on PonyProg), CKOPT = 1, JTAGEN = 1 SU>a) either reduce the SPI clock speed How? SU>b) reduce the wire length how long? 1 cm, 5 cm, 10 cm? thx. for help! (I got new Siemens S65 phone, phone stil work :) I'll extract LCD from him for tests )
@Spider84 a) i would not build the power supply out of a resistive voltage divider. Your supply voltage depends very much on the load current. For current peaks your voltage will drop. -> either use a LDO or at least a big buffer - Cap at the 2.9V b) your connecter looks different compared to the display connector should be LED_GND LED+ 1V8 GND 2V9 DAT CLK CS RESET RS
a) I can't find LDO in our shops :( I get +5V power from PC "AT" power (my old computer). Alsow I have LM317. b) my LCD have same connector, just so showed. Did you see? http://www.mobile-files.ru/forum/attachment.php?attachmentid=27771&d=1138024678
Hi Spider84, than add a buffer-cap 100µF or something like this in parallel to the display supply. Your link needs somehow a login... I did not understand the following :-) Вы ввели неправильн&# 1086;е имя или пароль. Пожалуйста, вернитесь назад, введите правильные данные и попробуйте еще раз. Не забудьте, что пароль чувствител&# 1077;н к регистру. Забыли пароль? Нажмите здесь!
Angehängte Dateien:
-
disp.jpg
26 KB
Heh. Learn Russian :) (look like UNICODE, but this cp1251) look attach. Why I see all other codepages correctly? :) cap 100uF betwen 6 and 7 pins. Right?
Spider, add the capacitors to the voltage supply lines only. Otherwise you'll put in low-pass filters further degrading your data signals.
Angehängte Dateien:
-
LCDx65v2.jpg
120 KB
Levels (AT LCD connector): 0 = 0,00..+0,10V 1 = 2,95..+3,10V LCD VCC = +3,12V ATMega VCC = +5,26V +12V = +12,46V NOT WORK! :( HELP!!! I setup this LCD to work phone - LCD is work. (Phone is Siemens S65) I tried connect my LCD wires to phone - work. (wires ~10cm)
I tried diferent software: a) http://www.superkranz.de/christian/S65_Display/data/L2F50_display4_V01.zip b) http://www.mikrocontroller.net/attachment.php/259277/HelloWorldMega16.zip tried diferent Mhz: a) 16Mhz (#define F_CPU 16000000) b) 8Mhz (#define F_CPU 8000000) Not work :(
Hi Spider84, are you sure having the L2F50 display? Because software a) is for this type of display, software b) for the LS020. If you have the L2F50 display, this software is already using the ASCII table from Flash and should work without any modification (beside Port changes). Summary: If you now have a clean supply at coreect level, correct I/O level and correct timing i have no idea what is going wrong :-( Can you check the interface signals with Osci, logic analyzer?
Angehängte Dateien:
-
Image_06_.jpg
21 KB
Is this L2F50? (see attach) at last I use L2F50_display4_V01.zip, just change defines of pins. Ths is good levels? Levels (AT LCD connector): 0 = 0,00..+0,10V 1 = 2,95..+3,10V LCD VCC = +3,12V ATMega VCC = +5,26V +12V = +12,46V Some times after power ON I see on LCD many horisontal colour lines... I have Osci but I don't know how to use them. Manual to Osci on Italian :) What kindof signal I must view by Osci?
Hi! Zuersteinmal: Danke Christian fürs zur Verfügung stellen der Infos ! So, nun zu meiner Frage: Ich wollte das Display an einem 3.3V DSP betreiben. Spricht etwas dagegen das Display direkt an 3.3V zu hängen (2V9 und 1V8 an 3,3Volt) ? Hat das jemand schon länger so in Betrieb ? Dann könnte ich nämlich auf die Levelshifter verzichten und das direkt an den SPI port hängen. Btw lässt sich aus der Platine aus diesem Thread: http://www.mikrocontroller.net/forum/read-3-271856.html#new sehr einfach ein kleiner 17,6Volt stepup regler zusammenbauen wenn man nicht die portpin,fet+spule lösung zurückgreifen will (R vor LED anpassen!) Gruss, Simon
Ich hatte das L2F50 schon tagelang - aus versehen - mit 4.2V in Betrieb. Lief ohne Probleme. Ich vermute, dass der Display-Controller für die üblichen 2.7V ... 3.6V ausgelegt ist. Im Mobile Phone nimmt man gerne die 2.8V, damit man mit LiIon Batterien + LDO arbeiten kann. Die 1.8V ist im S65 eine der Interface Spannungen (u.a. für Memory). Bei den mir bekannten Display-Controllern ist die Interface Spannung auch bis 3.6V spezifiziert. -> ich glaube (halt one Spec.), dass das 3.3V ohne Einschränkung der Lebensdauer gehen sollte.
Spider, please try to reduce the SPI speed by not setting the double-sped bit. Just changing the F_CPU define to 8Mhz ends in reducing the programms wait loops to half which is just the opposite of what you wanted to achieve if this action is not accompanied by exchanging the crystal oscillator with the corresponding value as well. Disabling the SPI double speed mode can be done by commenting out line 146 in disp.c of the LF package. This helped me getting my LS020 display working when using a prototyping board like you do.
With changing the F_CPU define I have change fuses bits to 8Mhz internal oscillator (SUT=10, CKSEL=0100).
Removing of SPSR = 1; // double speed bit don't help. Not work :( Strange...
@Spider: if you see horizontal color lines sometimes, that means in that cases your display is initialized and running and the final display on command was sent by your software. -> basically your hardware is running, perhaps not stable or the SW timing is not correct for your display. I propose that you play a little bit with the delays in the code. E.g. increase the reset time from 10ms to >50ms etc. Or remove comments from this line: // _delay_ms(7); As far as i know you are the second one using the L2F50 display. The inital timing was only tested one time. Maybe it is not perfect...
Ok. Thx, I'll try this. I tried find other models of LCD, but all phones that I diassemble has L2F50xxxx display :( I can't bay LCD (can't find in shops), but I can get many x65 phones - I work in GSM Service.
Line 215: _delay_ms(10); tried _delay_ms(50); or _delay_ms(60); Line 258: _delay_ms(7); not work.
AAAAAAAAAAAAAAAAAAAAAA It is work!!! I has down SPI speed to CPU/128 on 16Mhz and all work.
Hi! Sagt mal, sehe ich das richtig dass beim LS020 Display 1V8 überhaupt keine Verbindung hat ? Fällt mir nur gerade mal so beim verkabeln auf 8)
Spider, glad to here that. It probably means you can watch the individual pixels being drawn :P
yes :) it is look like XP on i386 PC :) Trying to speed up :)
Angehängte Dateien:
-
s65_defekt_p1263507.jpg
87 KB
Hi! Super, der Code funktionierte nach ein paar kleinen Änderungen auch auf einem mega8. Habe die Zeichentabelle zum testen rausgeworfen und schreibe nur "#" statt Buchstaben. Morgen wird der code auf nen dsp portiert! Danke !! Btw lief mein Display auch wenn ich 4 mhz Quarz eingestellt hatte in der lcd.asm und 8mhz dranhatte ... Nun aber leider die schlechte Nachricht: Mein Display ist defekt grrr Siehe Anhang. Jedenfalls zeigt er im obersten Teil nichts an und unten sind deutlich glassplitter zu sehen.... Erkennt man nicht so gut aufm Foto, ist nur mit Digicam geknipst. Direkt mal dem Ebayer schreiben ;( Gruss, Simon
Hallo Simon Ich würde das Display auch gerne auf einem Dsp verwenden. Für welchen DSP portierst Du denn? Ich plane es an einem Freescale DSP 56309 zu verwenden. LG Michael
(leider) für einen Ti TMS320f2812... leider wegen dem dollen compiler den man verwenden muss :-X
Hi Spider, now you have to implement unicode driver (for russian) ...
:-\ I don't want UNICODE it is to hard. cp1251 or cp866 best way. I'll make graphic api for this lcd based on "glcd". Did you know how to put "transparent" pixel, ho to step for 1 pixel with out drawing?
Hi! Nach einigen Stunden Debuggen und Fehlersuche habe ich es nun auch auf dem DSP ans laufen bekommen (stellte sich als einen saublöden copy n paste fehler heraus) Jedenfalls läuft das Display nun stabil bei mir: - 1V8 und 2V9 hängen direkt an 3.3V - alle IOs sind direkt mit dem DSP verbunden (3.3V) - Display hängt an gut 15-20cm SMT Flachbandkabel (0.8mm Abstand) - Taktrate war auch relativ hoch, gab kaum Probleme (auch wenn die Taktflanken aufm Oszi grausam aussehen nach 20cm Kabel und etlichen mhz g) - Framerate muss ich nochmal messen, liegt aber deutlich über 2fps. Montag werde ich das nochmal überarbeiten und dann den C-Code der Displayansteuerung hier posten. Ist dann einfach portierbar, man muss bei Prozessorwechsel nur die spi_tx16() routine austauschen 8) Nochmal Danke ;) Wenn ich dran denke mach ich Montag auch mal Fotos oder nen Video im Betrieb. Funktioniert echt super :) Gruss, Simon
Angehängte Dateien:
-
companion2b-up2.png
440 KB
Hi! Habt Ihr zufällig einen passenden LDO 5V nach 3V mit 200mA, den ich irgendwo um die Ecke (z.B. Reichelt) bekommen kann. Will meine Platine fertigstellen und viel fehlt nicht mehr. Als Pegelwandler will ich den 74LVX4245 verwenden, den habe ich aber auch noch nirgendwo gefunden. KennyOswald
Da du SMD verwendest, kannst du z.B. den http://www1.conrad.de/scripts/wgate/zcop_b2c/~flNlc3Npb249UDkwV0dBVEU6Q19BR0FURTAyOjAwMDEuMDMxMi5kNmUxNzFkZSZ+aHR0cF9jb250ZW50X2NoYXJzZXQ9aXNvLTg4NTktMSZ+U3RhdGU9ODI0MzczNTEw====?~template=PCAT_AREA_S_BROWSE&p_selected_area=%24ROOT&perform_special_action=&glb_user_js=Y&shop=B2C&product_show_id=&p_page_to_display=DirektSearch&~cookies=1&zhmmh_lfo=&zhmmh_area_kz=&s_haupt_kategorie=&p_searchstring=IRUT205&r3_matn=&insert_kz=&area_s_url=&area_url=&direkt_aufriss_area=&p_countdown=&p_80=&p_80_category=&p_80_article=&p_next_template_after_login=&mindestbestellwert=&login=&password=&bpemail=&bpid=&url=&show_wk=&use_search=3&p_back_template=&template=&kna_news=&p_status_scenario=&documentselector=&p_load_area=$ROOT&p_artikelbilder_mode=&p_sortopt=&page=&p_catalog_max_results=10 gibt's bei conrad... Als Pegelwandler nehme ich den 74HC4050
Danke für die Antwort! Auf Conrad wäre ich nie gekommen. (Das letzte mal vor 5 Jahren.) @Pegelwandler Möchte beim 74LVX4245 bleiben, habe damit gute Erfahrungen gemacht. Nur möchte ich nicht jedesmal Samples bestellen, um an die Teile ranzukommen.
I don't speak Germat at all. Could you tell mi whitch controlles does ls020xx uses?
Hi! Heute habe ich rausgefunden dass man die CE=0/CE=1 nicht unbedingt jedesmal setzen/löschen muss. Beim schreiben der gesamten Bilddaten kann man das Signal konstant auf low lassen. Dadurch spart man eine Menge Zeit wenn man einen SPI FIFO (DPS) hat. Lediglich vorm setzen des Zeichenfensters muss man das CE einmal toggeln. (und ich lasse es bei jedem write_cmd toggeln, evtl auch optional) (bezieht sich auf das LS050) Gruss, Simon
Hi! Meinte natürlich das LS020 ;) Habe heute auch die die Textausgabe portiert. Hat wunderbar geklappt ;) Bin echt begeistert von dem Display :) Hier noch ein kleines Testvideo 8) http://avr.auctionant.de/misc/p2013538.mov.small.divx.avi (die Streifenmuster kommen nur vom filmen mit der Digicam ;) ) Gruss, Simon
Hallo Simon, was ist das für eine Textausgabe? Ähnlich wie bei der glcd mit verschiedenen Fonts etc? Grüße SU
Da hab ich nur Christians Ascii Ausgabe umgeschrieben und auch seine 8x14font benutzt. Hab eigentlich nur immer 2 Byte zu einem 16Bit wert zugeordnet und die Ausgabe umgeschrieben. Benutzt wird es wie folgt: sprintf(txt, "%02.2f fps", fps); display_puts(x,y,txt,length(txt)); Also nichts dolles ;)
nice, wo kommt denn das video her? von ner kamera? Echt schick!
Hi! Danke ;) Jepp, kommt direkt von nem VGA Kameramodul (naja nicht direkt, das video geht erst über nen fpga in ein sram, dann wieder über den fpga zum dsp und von dort dann zum display g) Das display ist aber nur zum debuggen, Bildverarbeitung ohne direkt zu sehen was passiert ist irgendwie ätzend. Vorallem die Bugsuche 8) Gruss, Simon
Das mit dem Video ist ja genial, kannst du vielleicht genauer sagen wie du das gemacht hast? oder was wo mans nachlesen kann? ich hab mir jetzt fast den ganzen thread durchgelesen. bei den ganzen fehlern und bugs, ist die hompeage denn jetzt auf den aktuellen stand? Oder lieber die pdf nehmen? mfg computaholic
wenn du das grüne display hast holst du dir am besten das datenblatt und versuchst die Ansteuerung anhand des Datenblattes zu verstehen und zu "debuggen" bzw ergänzen. Das ist was ich machen werde, sobald ich genug geld habe um mir was zusammenbasteln zu können ;( Simon welches Modul hast du denn benutzt? Ich bin echt begeistert, da hast du schon fast ne ganze digitalkamera (nur noch MMC karte dran).
Wo gibt es denn das Datenblatt? Also auf der Hompage gibt es ja C-Graphicroutinen für die drei Displaytypen LS020xxx LPH88xxxx L2F50xxx. Funktionieren die Funktionen da drin soweit, das man darauf aufbauen kann? GLCD gibts ja im moment nur fürs LS020xxx, oder hat sich da schon wa getan? Welches Display ist eiurer Meinung nach das beste in bezug auf a)ansteuerbarkeit und b)bildqualität? Ich hab mir den C-code jetzt nicht genau angeschaut, aber gibt es da ne möglichkeit "bitmap-code" an display weiterzugeben? Viele Fragen, ein noob, trotzdem danke an die, die antworten;) mfg computaholic
Hi! wegen dem Video: Das ganze ist für meine Diplomarbeit, wird ein Bildverarbeitungssytem für unsere Fussballroboter an der Uni. Dementsprechend klein muss das ganze werden (Platinen max 7.1x7.1cm). Als Kameras benutze ich Agilent adcm2700 VGA Kameramodule. Sind leider sehr Bastlerungeeignet, als normalsterblicher kommt man nciht an die Datenblätter ;) Wir haben sie an der Uni, wir mussten aber ein NDA unterschhreiben. Normalerweise sind die Kameramodule in Motorola Handys drin. Aber vorsicht, motorola verbaut 3 verschiedene: Phillips, Micron und Agilent (zu den ersten beiden bekommt man aber die Datenblätter im Netz). Nachlesen kann man das (noch) nirgends ;) Gruss, Simon
@computaholic Die Web-Page ist up-to date (und so viele Bug's waren das doch gar nicht...) Bitmap's kannst du auf allen Displays ohne Probleme mit 65k Farben ausgeben. Für das grüne Display LPH88 gibt es ein kompatibeles Datenblatt (hier im Thread gepostet) Es hat auch die flexibelsten Addressierungsmodies für das Grafik-RAM. Für das LS020 gibt es den GLCD port, dass heisst schöne Grafik- und Textausgabe mit allen möglichen Font's Das Epson Display L2F50 kann bisher nur die Bitmap-Ausgabe. Grüsse SU
Kann man die displays eigentlich auch am pc am parallel-port betreiben? mit lcdhype oder ja lcd oder mit einem eigenen Programm? In wiefern müsste der programmcode geändert werden? mfg computaholic
Hab mir jetzt auch mal ein LCD besorgt. Ist ein LS020 Mit SimpleDisplay3 funktioniert es probremlos! Mit der Lib bringt mir das LCD aber rein gar nichts :-( Zur Hardware Ich hab nen Mega32 mit 16MHz und einen 74HC4050 als Level-Shifter das Display wird mit 3.04V versorgt In der glcd.inc hab ich die pins auch geändert so das sie passen. Hat jemand ne Idee warum es nicht will?
Hat sich erledigt :-) Ich habe in der glcd.inc die ganzen defines für die anderen mcu´s rausgeworfen und schon funktioniert es damit :-)
hallo, tolle sache dass mit dem display. Ich habe einige fragen, da ich gerade (vor 30min meine erste blinkende led) mit AVR anfange ist mir etwas naebelig, wie das gance mit dem compiliren von den beispiele die hier gepostet sind. Also... Frage 1: Welcher compiler bzw. welche ide benutzt ihr fuer das project (habe bis jetzt ccs fuer PIC's benutzt) Frage 2: Hat jemand ein fertiges project fuer ein atmega16 und 16mhz ext quartz, wenn ja, kan es der jenige hier posten und mir zagen mit welcher ide das gemach wurde...
hmmmm, es gibt einige tipp und sprachfehler bei mein post, aber da ich kein deutscher bin, hoofe dass ihr verstanden habt was meine...
Der Compiler ist Winavr eine IDE gibt es da keine (soweit ich weiß) Für den Mega16 war hier schon mal was im Thread
winavr hat programmers notepad mit drin, ich glaube eclipse ist aber etwas weiter entwickelt.
AVRStudio arbeitet auch mit WinAVR zusammen (mal mehr und mal weniger. Siehe: http://www.mikrocontroller.net/forum/read-2-306070.html#new)
@Mark: Gibt es schon Neuigkeiten bezgl. der Platine ? Gruss, Ralf
Hallo, ich habe das LPH-Display an einem AVR mit 3V Spannungsversorgung angeschlossen, hat problemlos funktioniert. Jetzt wollte ich das LCD an einen ST10-Controller anschließen, der mit 5V Versorgt, also auch 5V-Pegel an den I/O-Pins liefert. Ich habe Spannungsteiler mit 3k3 und 2k2 versucht, allerdings bekomme ich das LCD nicht ans laufen. Auf dem Oszi sehen die Pegel allerdings recht vernünftig aus. Sind die Widerstände evtl. zu hochohmig? Hat schon jemand Probleme mit zu hochohmigen Spannungsteilern gehabt? Welche Werte verwendet ihr? Die Werte, die im PDF angegeben sind, sind relativ niederohmig, das können die Portpins des ST10 evtl. schon gar nicht mehr treiben. Gruß Mike
wenn sie zu hochohmig sein sollten könnte es helfen den Takt runter zu setzen.
Die Widerstandswerte hängen von der SPI Geschwindigkeit ab. Die ursprünglich vorgeschlagenen Werte gehen von 8MHz aus, da braucht man schon niederohmige Werte. Das ist mit den 3k3/2k2 sicher nicht mehr vernünftig machbar. Hängt natürlich auch von der Kabellänge ab... Hast du mit dem Osci am Display gemessen?
Den Takt habe ich schon runtergenommen, liegt bei ca. 500 kHz. Die Leitungen zum LCD sind ca. 10cm lang. Mit dem Oszi habe ich direkt am Spannungsteiler gemessen. Gruß Mike
Hi! Wollte mal fragen ob irgendjemand schon die Graphiklibrary auch für die LPH und L2F Displays umgeschrieben hat. Leider reichen meine Kenntnisse dafür nicht aus.... mfg Fasti
@Mike: mit 500kHz sollte das mit 3k3/2k2 wohl noch klappen. Wirst wohl noch ein anderes Problem haben. Vergleich doch mal die Phase von Clock und Daten...
Thread beobachten
Seitenaufteilung abschalten![http://www.superkranz.de/christian/S65_Display/pics/Display_connect_small.jpg"](http://www.superkranz.de/christian/S65_Display/pics/Display_connect_small.jpg"){kind=link}
Bitte 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.