Ich habe folgendes GLCD von R... verbaut: LCD 128SW DIP
Angeschlossen an ein Atmega16, 8MHz intern
Programmiert mit Hilfe von glcdKS108.lib unter Bascom. Das ganze zum Test mit laufend wechselnden Displayinhalten (Text, Graphik, .bgf)
Nach kurzem hin und her lief das Display auch. Nach einiger Zeit zeigten sich allerdings im linken Teils des Displays erste Pixelfehler, sowie verschobene Bildbereiche. Im Laufe der Zeit wurden die Fehler immer häufiger. Reset brachte keine Besserung. Nach längerem Ausschalten war es zunächtst ok, dann kamen die Fehler erneut.
Ich vermutete also 2 mögliche Ursachen:
1. Thermischer Fehler im Displaycontroller, der den linken Bereich steuert.
2. EMV-Problem bei der Ansteuerung von Ce auf Grund von ca. 15cm langen Verbindungsdrähten.
Da ich nicht lange rumsuchen wollte Reklamation an R.... Von dort Meldung das Display geht an Hersteller zur Kontrolle.
Jetzt bekam ich ein Display zurück mit folgender Meldung: Das eingesannte Display sei getestet und für gut befunden worden (24h Test). Trotzdem Austausch aus Kulanz.
Also neues Display eingesetzt und der Fehler war jetzt sowohl im linken, als auch im rechten Displaybereich und zwar sofort und erheblich stärker.
Also offensichtlich ein systematischer Fehler.
Da ich ein EMV-Problem vermutete habe ich zunächst die Taktfrequenz auf 4MHz gesenkt. Fehler waren jetzt echte Ausnahme. Also doch EMV?
Bei 1 und 2MHz überhaupt keine Fehler.
Also interen Takt wieder auf 8MHz erhöht. Fehler erneut da. Jetzt dem Kompiler gesagt der Chip laufe mit 8.1MHz: Fehlerrate erheblich gesenkt.
Jetzt dem Compiler 8.5MHz vorgegaukelt. $crystal = 8500000
Also das Display läuft seitdem über 24h ohne das ich bisher Fehler gesehen habe. Handelt es sich um einen Timingfehler in der GLCD-Datei oder bei den Displays?
Da ich das Display auch mal in zeitkritischen Anwendungen einsetzen möchte ist eine so starke Differenz zwischen "Compilertakt" und tatsächlichem Takt nicht akzeptabel.
Hatte schon mal jemand ähnliche Erfahrungen
Schöne Grüße
Hackyber
Angeschlossen an ein Atmega16, 8MHz intern
Programmiert mit Hilfe von glcdKS108.lib unter Bascom. Das ganze zum Test mit laufend wechselnden Displayinhalten (Text, Graphik, .bgf)
Nach kurzem hin und her lief das Display auch. Nach einiger Zeit zeigten sich allerdings im linken Teils des Displays erste Pixelfehler, sowie verschobene Bildbereiche. Im Laufe der Zeit wurden die Fehler immer häufiger. Reset brachte keine Besserung. Nach längerem Ausschalten war es zunächtst ok, dann kamen die Fehler erneut.
Ich vermutete also 2 mögliche Ursachen:
1. Thermischer Fehler im Displaycontroller, der den linken Bereich steuert.
2. EMV-Problem bei der Ansteuerung von Ce auf Grund von ca. 15cm langen Verbindungsdrähten.
Da ich nicht lange rumsuchen wollte Reklamation an R.... Von dort Meldung das Display geht an Hersteller zur Kontrolle.
Jetzt bekam ich ein Display zurück mit folgender Meldung: Das eingesannte Display sei getestet und für gut befunden worden (24h Test). Trotzdem Austausch aus Kulanz.
Also neues Display eingesetzt und der Fehler war jetzt sowohl im linken, als auch im rechten Displaybereich und zwar sofort und erheblich stärker.
Also offensichtlich ein systematischer Fehler.
Da ich ein EMV-Problem vermutete habe ich zunächst die Taktfrequenz auf 4MHz gesenkt. Fehler waren jetzt echte Ausnahme. Also doch EMV?
Bei 1 und 2MHz überhaupt keine Fehler.
Also interen Takt wieder auf 8MHz erhöht. Fehler erneut da. Jetzt dem Kompiler gesagt der Chip laufe mit 8.1MHz: Fehlerrate erheblich gesenkt.
Jetzt dem Compiler 8.5MHz vorgegaukelt. $crystal = 8500000
Also das Display läuft seitdem über 24h ohne das ich bisher Fehler gesehen habe. Handelt es sich um einen Timingfehler in der GLCD-Datei oder bei den Displays?
Da ich das Display auch mal in zeitkritischen Anwendungen einsetzen möchte ist eine so starke Differenz zwischen "Compilertakt" und tatsächlichem Takt nicht akzeptabel.
Hatte schon mal jemand ähnliche Erfahrungen
Schöne Grüße
Hackyber
