Hallo,
Ich bin seid längerem mal wieder zum Basteln gekommen. Zum wieder
Einarbeiten in die 8Bit AVRs wollte ich eines von meinen 240*128px LCDs
mit LC7981 Controllern ansteuern. Eigentlich klappt soweit auch alles,
bis darauf, dass das Display nicht mag gelöscht zu werden :D -> Sprich
wenn ich im Grafikmodus eine 0x00 schreibe, stürzt das Display ab und es
zeigt wackelnde zeilen an (wie vor der Initialisierung). Schreibe ich
nun aber einen anderen Wert in diesem Zustand hinterher z.B. 0x01 -
läuft das Display wieder normal und Zeichnet auch korrekt weiter. Dachte
es liegt evtl daran, dass das Display die 0x00 als Register Befehl
interpretiert und das Display ausschaltet. Leider komme ich aber bei dem
Problem nicht weiter - egal was ich mache, bei 0x00 spinnt er :). Im
Textmodus ist es sogar noch merkwürdiger - lösche ich das Display mit
0x00 (for schleife) dann ist das Display interessanterweise auch leer
und der cursor wird - wie in meinem Programm geschrieben auf
Homeposition (0, 0) gesetzt und blinkt dort. Allerdings wenn ich nun
0xFF an diese Position schreibe - was auch funktioniert, erscheint
gleichzeitig an Pos (0, 29) ein Sonderzeichen, welches ich dort nicht
geschrieben habe.
Dieses Problem tritt allerdings nur beim löschen mit 0x00 auf, wenn ich
per 0x20 (ASCII Leerzeichen) das Display im Textmodus leermache,
funktioniert alles wunderbar?!
Ein defektes Display kann es eigentlich auch nicht sein, da ich schon
tesweise andere Versucht habe, mit dem gleichen Ergebnis.
Hoffe es hat hier eventuell jemand eine Idee parat, die mir helfen
könnte! Falls Code gebraucht wird, kann ich natürlich auch etwas
einstellen. Weiß aber nicht ob das wirklich was bringen würde, da ich
echt schon viel geändert habe und es leider trotzdem nichts bewirkt hat
:(.
MFG Hannes
EDIT:
Meine Schreibroutine schaut vom Ablauf so aus, falls das hilft
(eben aus dem Kopf aufgeschrieben):
1
DDR_DATA=0x00;// Alle Datenport Pins als eingänge definieren
2
PORT_DATA&=~BUSY_PIN;//Falls Pullup auf Busy Pin vorhanden - entfernen
Mich hat der Controller auch vor einige Rätsel gestellt, bis ich auf die
Library von Vanya A. Sergeev gestossen bin, der das Dings recht gut
bedient, wenn auch ausschliesslich im Grafik Modus.
https://github.com/AriZuu/embedded-drivers
Selbst wenn du nicht die komplette Library einbindest, ist das Studieren
der Routinen mit Sicherheit hilfreich.
Als Hardware benutze ich übrigens dieses Pollin Display mit Touchscreen,
wobei ich das Glück hatte, das der Touch bei meinem Exemplar in Ordnung
ist.
Hallo Matthias,
erst einmal vielen Dank für deine Antwort!
Ich habe mir die Lib die du verlinkt hast mal angeschaut und habe sie
auch Testweise einmal auf meinen Atmega geladen um zu testen ob es zu
meinem Programm eventuell wirklich Änderungen gibt, die das Problem
lösen.
Leider funktioniert die Lib auf meinem Display genauso schlecht/gut wie
meine eigenes Programm :(.
So langsam stehe ich auch aufm Schlauch, warum das so ist...
Es kann doch nicht sein, dass ich hier 12 Defekte Displays mit einem und
dem selben Fehler liegen habe?!
Beim Rumprobieren hab ich noch 3 Merkwürdige Dinge bemerkt:
- Beim 1. löschen des Displays (nach der Initialisierung) scheint es zu
Funktionieren -> ich kann sehen wie nach und nach vorhandene Pixel die
beim Starten von dem Display gesetzt waren verschwinden.
- Nach dem 1. löschen, wird der Cursor wieder an Adresse 0 gesetzt (bei
diesem Befehl passiert es das 1. Mal das sich das Display komisch
verhält -> Linien über die komplette Zeile laufen wild umher, bis ich
den nächsten Schreib-Befehl ausführe - ist dieser 0x01 oder 0xFF als
BSP, ist das Display wieder im normalen Betrieb und er schreib dann auch
die Daten an Pos 0 (Also hat das setzen des Cursors doch irgendwie,
trotz der Fehlfunktion der Anzeige funktioniert)
- Der Atmega162 der in der Schaltung im Einsatz ist hat komischerweise -
auch wenn nichts angeschlossen ist (selbst ohne LCD), an den Output Pins
lediglich 3,6-3,8V, obwohl er selbst mit 5,2V lt Oszilloskop betrieben
wird. 1,4-1,6V Voltage Drop im Atmega? etwas viel oder?
PS: Display ist übrigends ein Powertip PG240128ERS (240*128Px LCD)
und der Atmega162 läuft auf 8MHz internem Takt.
Hannes M. schrieb:> Der Atmega162 der in der Schaltung im Einsatz ist hat(...)an den Output Pins> lediglich 3,6-3,8V, obwohl er selbst mit 5,2V lt Oszilloskop betrieben> wird.
Klingt so, als hättest du dir die Ausgänge zerschossen... Hast du
zufällig noch einen anderen µC zum Testen?
Hab ich, ja.
Werd es mal versuchen...
aber würde denn der Atmega bei defekten Ausgängen trotzdem noch sauber
arbeiten? -> die 3,6-3,8 V werden sauber geschaltet - auch mit sauberen
Flanken. Hätte vermutet, dass bei defekten Ausgängen die Signale sich da
auch anders verhalten würden ?!.
Werde mich nach den Tests noch einmal melden und Ergebnisse posten :).
Hallo holger,
erst einmal auch vielen Dank für deinen Tip...
JTAG war zwar durch die Fuses aktiviert, aber leider hat das
deaktivieren keine Änderung hervorgerufen :(...
Ich wollte darauf den ersatz ATMEGA162 einmal einsetzen, musste aber
feststellen, dass ich diesen anscheinend schon einmal gekillt haben
musste - keine Reaktion auf das brennen von daher kann ich zur Zeit
leider nicht testen, ob es am Atmega selbst liegt. Fände es dennoch
merkwürdig, das sich ja alle IO Pins gleich verhalten und sich der uC ja
noch normal Brennen lässt?!
Ich habe aber nun zumindest schon einmal 3 Fotos gemacht (1x das
Testprogramm das auf dem ATMEGA läuft und 2x die Oszilloskop ausgabe von
der Versorgungsspannung und von einem Ausgang des ATMEGA (2.5ms/DIV +
250ns/DIV).
Vielleicht hilft das ja um das Problem einzugrenzen (oder ist der
Voltage drop am IO Pin vielleicht doch normal?!.
Hannes M. schrieb:> (oder ist der> Voltage drop am IO Pin vielleicht doch normal?
Nur, wenn du deutlich mehr als 20mA aus dem Port ziehst. Das Mega162
Datenblatt behauptet, das bei 20mA am Port immer noch minimal 4,2V
geliefert werden können (das ist bei nahezu allen Atmel 8-Bittern so).
Entweder ist also deine Vcc tatsächlich zu niedrig, die Ausgänge werden
zu stark belastet oder der MC hat 'ne Macke.
Halt, es kann noch sein, das du das Display mit zu niedriger Spannung
betreibst, dann könnte es sein, das die Klemmdioden am Eingang des
LC7981 den Ausgang des MC auf diese Spannung clippen.
Hallo Matthias,
An dem LC7981 kann es nicht liegen, da ich für den Output test, den ich
oben gepostet hatte, das Display garnicht angeschlossen hatte.
Es wäre natürlich ärgerlich wenn der uC defekt sein sollte.
Kurioser Weise habe ich heute noch einmal etwas rumprobiert und bin zu
einem merkwürdigen Ergebnis gekommen:
Als erstes wollte ich testen ob mit meiner Testplatine eventuell etwas
nicht stimmt, also habe ich den uC einmal auf einem Steckbrett montiert
mit lediglich VCC, GND, Pullup an RST, und eine Messleitung an einem
Ausgang.
Das Ergebnis sah leider genau so aus wie oben bereits gepostet :(.
Hab anschließend noch etwas mit den Fuses gespielt und siehe da - wenn
CKDIV8 aktiviert, habe ich an den Ausgängen 4,7V (lt. Oszi ~500mV VDrop
zur Versorgung - siehe Bild). Testweise hab ich auch einmal die Fuse
aktiviert den Internen Takt nach aussen zu geben und was da ankommt, ist
kein 8MHz Rechteck, sondern eher ein 8MHz Sinus?!.
Ich denke ich werde Testweise einmal ein externes 12MHz Quarz
anschließen und schauen, wie der uC dann reagiert.
PS: Hab nocheinmal die 3 Oszi Messungen angehängt. Frequenz passt nun
natürlich nicht mehr, da ich das Programm nicht weiter angepasst habe,
sondern nur die CKDIV8 Fuse gesetzt habe.
Hannes M. schrieb:> Hab anschließend noch etwas mit den Fuses gespielt und siehe da - wenn> CKDIV8 aktiviert, habe ich an den Ausgängen 4,7V
Hmm, ich denke, es ist an der Zeit, das du mal deine Tastköpfe
untersuchst bzw. mal mit einfachen Drähten in den BNC Buchsen mal die
Spannungs- und Frequenztreue des Oszis untersuchst. Möglicherweise hast
du einen defekten Tastkopf (ich habe mir in den Röhren-TV Zeiten einige
durch Hochspannung zermanscht, die dann lustige Frequenzgänge und andere
Seiteneffekte hatten).
Es kann auch sein, das der Tastkopf einen Masseschluss bzw. -widerstand
hat, miss ihn mal mit deinem Ohmmeter durch.
Ein AVR, dem du in einer simplen Schleife mal alle Beinchen high und
dann low setzt, sollte das auch nahezu bis an die
Betriebsspannungsgrenzen tun (0V - Vcc).
Thread beobachten
Seitenaufteilung abschalten