Hallo, seit einiger Zeit beschäftige ich mich nun mit µCs (mikrocontroller.net ist zum Lernen auch eine super Seite). Nun wollte ich mal ein monochromes Handy-LCD ansteuern. Allerdings ergeben sich da ziemliche Probleme: Nachdem ich versucht habe 2 verschiedene LCDs manuell mithilfe der Timing-Diagramme aus den Datenblättern der jeweiligen LCD-Controller anzusteuern und gescheitert bin, habe ich gelesen, dass es über SPI gehen müsste. Es gibt dafür auch einige Beispiele im Netz. Das Problem ist aber, dass ich einen ATTiny2313 verwende, der kein reines SPI, sondern ein USI hat. Also habe ich mich durch das Datenblatt gewühlt, um irgendwie das USI für SPI zu benutzen. Das Programm hat aber wieder nicht gefunzt und das LCD blieb wieder leer. Hier mal ein paar Zeilen Code: ;SPI initialisieren (temp1 = r16) ldi temp1, (0<<USIWM1)|(1<<USIWM0)|(1<<USICS1)|(1<<USICLK)|(1<<USITC) out USICR, temp1 . . . ;Senden (ausgang = r20) out USIDR, ausgang Der LCD-Controller müsste doch aus dem USIDR die Daten entnehmen oder sehe ich das falsch? Nach langem Debuggen bin ich zu dem Schluss gekommen, dass die Daten anscheinend nicht gesendet werden. Nun meine Frage: Was mache ich falsch? Kennt jemand entsprechende Routinen? MfG Kristian
Hi Ich habe mal schnell das Datenblatt überflogen. So wie es aussieht musst du dich um den Takt kümmern. Im Datenblatt sind einige Programmbeispiele. MfG Spess
Kristian schrieb: > Nachdem ich versucht habe 2 verschiedene LCDs manuell mithilfe der > Timing-Diagramme aus den Datenblättern der jeweiligen LCD-Controller > anzusteuern und gescheitert bin, habe ich gelesen, dass es über SPI > gehen müsste. Wenn etwas nicht geht und Du weißt nicht warum, dann ist es falsch, planlos rumzuprobieren. Umgekehrt wird ein Schuh draus: Erst wenn es funktioniert, kann man den Code optimieren. Händisch bist Du deutlich flexibler (Timing, Reihenfolge, Bitanzahl), als mit dem SPI. Du solltest dann aber das Bitmacro SBIT verwenden, das erhöht die Lesbarkeit und verringert die Fehlermöglichkeiten drastisch. Das Bitmacro findest Du in fast jedem Code von mir, z.B.: http://www.mikrocontroller.net/attachment/30300/lcd_drv.zip Peter
Danke für eure schnellen Bemühungen. Es ist eine verzwickte Sache, weil ich halt nicht weiß, ob es am LCD liegt (Anschlüsse) oder halt an der Software. Ich habe mir aber verschiedene Tutorials zum LPH7366-1 angeschaut und bin mir auch sehr sicher, dass es richtig angeschlossen ist. Aber ich habe keine Ansteuerung für den ATtiny gefunden. MfG Kristian
Ich habe jetzt nochmal alle Verbindungen überprüft und das Programm zur manuellen Ansteuerung (ohne SPI) im Simulator getestet. Allerdings tut sich auf dem Display nix. Vielleicht seht Ihr ja im angehängten Programm einen Fehler. Da ich mit Tabs eingerückt habe, könnte es in einem anderen Editor (verwende AVR Studio) etwas durcheinander aussehen.
Kristian schrieb:
> Vielleicht seht Ihr ja im angehängten Programm einen Fehler.
Dazu müßte man erstmal das Datenblatt Deine Displays kennen.
Du mußt schon nen Link drauf posten oder das PDF anhängen.
Oftmals brauchen LCDs Wartezeiten (je nach Befehl unterschiedliche!).
Und an das SPI gibts auch minimale Timinganforderungen (Clockdauer,
Datenhaltezeit usw.).
Vermutlich bist Du einfach viel zu schnell. Du hast da nirgends Delays
drin und Deinen MC-Takt kennt auch niemand.
Peter
Das Datenblatt habe ich dummerweise vergessen. Sorry. http://www.datasheetcatalog.org/datasheet/philips/PCD8544U.pdf Ich scheine tatsächlich zu schnell zu sein, wenn ich mir die Zeiten so anschaue. Ich habe zwar nur einen µC-Takt von 1,8432 MHz aber trotzdem werden wohl die Befehle zu schnell ausgeführt. Ich bin es von Schieberegistern gewohnt, dass kein Warten notwendig ist ;) Ich werde mal entsprechende Delays einbauen. VIELEN DANK FÜR DEN TIPP. Dieser Satz macht mir allerdings etwas Sorgen: "Attention should be paid to the possibility that the device may be damaged if not properly reset." Ich kann mir zwar nicht erklären, wieso das Display beschädigt werden kann, wenn ich nicht resette, aber vielleicht ist es bei mir schon passiert. Na mal schauen.
Also trotz Delays von mind. 3ms gibt es keine Ausgabe. Ich habe nochmal den veränderten Code angehängt.
Hi Der PCD8544 kann 4MHz. Das sollte schon passen. Was mir aber aufgefallen ist: Im Datenblatt liegt die positive Taktflanke in Bitmitte. In deinem Programm aber die negative. MfG Spess
Ich habe meiner Meinung nach schon eine positive Taktflanke während ich das Bit sende. folgendermaßen ist mein Ablauf: - mit cbi PORTD, DIN bzw. sbi PORTD, DIN lege ich das Bit auf den Ausgang - warten - mit sbi PORTD, CLK setze ich eine positive Taktflanke - warten (gesendetes Bit müsste vom LCD-Controller empfangen werden) - mit cbi PORTD, CLK setze ich eine negative Taktflanke - warten - und wieder von vorne Mein Timing-Diagramm müsste also so aussehen (101 übertragen): CS \______________________________/ CLK ____/---\____/---\____/---\____ DIN __/-------\_________/-------\__
>Ausgeben: > cbi PORTD, CS Such in deinem Programm mal die Stelle wo CS wieder hochgeht ;)
Also ich bin davon ausgegangen, dass es egal ist, ob CS dann wieder hochgeht oder nicht, da ich ja nur ein LCD ansteuer. Aber ich habe jetzt trotzdem CS am Ende der Ausgabe-Routine wieder auf HIGH gesetzt. Nur leider hat es daran auch nicht gelegen. So langsam könnte man davon ausgehen, dass das LCD defekt ist, aber es ist aus einem Handy, das bis zuletzt funktioniert hat. Der Akku ist halt nur defekt gewesen. Aber super, dass sich doch einige mit meinem Problem beschäftigen.
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.