Guten Morgen, ich habe von Reichelt ein Grafik-LCD mit der Bezeichnung "LCD 64128A LED" ( http://www.reichelt.de/LCD-Module-Grafik/LCD-64128A-LED/3//index.html?ACTION=3&GROUPID=3008&ARTICLE=31672&SHOW=1&OFFSET=500&; ) und wundere mit gerade, daß die Ansteuerung wie im Datenblatt vom KS0108 kein richtiges Bild liefert. Weiß jemand, welcher Controller-IC dort eingesetzt wird? Vom Pinout paßt das Modul (fast) zum TG12864B-Footprint (bis auf die Bohrungen, die sind nur 2,5mm), und zwei unterschiedliche TG12864B funktionieren auch zuverlässig. Im Unterschied zu diesem scheint das LCD-64128A aber kein Busy-Signal auszugeben. Viele Grüße Nicolas
Hi >und wundere mit gerade, daß die Ansteuerung wie im Datenblatt vom >KS0108 kein richtiges Bild liefert. Was verstehst du unter 'kein richtiges Bild'? >Weiß jemand, welcher Controller-IC dort eingesetzt wird? Das Bustiming passt zu KS0108 und HD61202. MfG Spess
spess53 schrieb: > Was verstehst du unter 'kein richtiges Bild'? Unter "kein richtiges Bild" verstehe ich, da"s auf einer Displayseite teilweise Pixelmuster - die Teile eines Piktogrammes sind, das dargestellt werden soll - über den Bildschirm huschen und auf die andere Hälfte leer bleibt.
Hi >Unter "kein richtiges Bild" verstehe ich, da"s auf einer Displayseite >teilweise Pixelmuster - die Teile eines Piktogrammes sind, das >dargestellt werden soll - über den Bildschirm huschen und auf die andere >Hälfte leer bleibt. Da würde ich nochmal die Verkabelung überprüfen. Der Displaycontroller ist übrigens ein S6B0108 von Samsung. MfG Spess
spess53 schrieb: > Da würde ich nochmal die Verkabelung überprüfen Die Verkabelung ist in Ordnung. Das Display ist gesockelt und im gleichen Sockel läuft ein TG12864B (dann natürlich ohne Displaybeleuchtung) einwandfrei. spess53 schrieb: > Der Displaycontroller ist übrigens ein S6B0108 von Samsung Danke, das habe ich gesucht. Viele Grüße W.T.
Hmmm....die Timings laut Datenblatt sind absolut identisch. Und im Datenblatt des S6B0108 steht auch nichts von open drain, daß er im Gegensatz zum KS0108 vielleicht pull-ups benötigt. Es bleibt rätselhaft.
Ohne Deine Schaltung und Software zu kennen können wir Dir kaum weiterhelfen... Wartest Du 50ms, bevor das LCDInit loslegt?
Pete K. schrieb: > Ohne Deine Schaltung und Software zu kennen können wir Dir kaum > weiterhelfen... Kein Problem, ich habe ja auch erst einmal nur nach dem Datenblatt gefragt - weiter kann eh erst heute abend vorgegangen werden, wenn ich Schaltung, Quelltext und Oszilloskop vor mir habe. Pete K. schrieb: > Wartest Du 50ms, bevor das LCDInit loslegt? Woher kommen die 50ms? Im S6B0108-Datenblatt finde ich nirgendwo Zeitem im ms-Bereich. P.S.: Und ich habe gerade gesehen: die TG12864B haben auch einen S6B0108, keinen KS0108.
Walter Tarpan schrieb: > Woher kommen die 50ms? Im S6B0108-Datenblatt finde ich nirgendwo Zeitem > im ms-Bereich. Datenblatt bei Reichelt, Seite 13, Punkt 11.3
spess53 schrieb: > Der Displaycontroller ist übrigens ein S6B0108 von Samsung. Woher kommt eigentlich diese Information? Hast Du irgendein Datenblatt gefunden, was ich nicht gefunden habe?
Hi >Woher kommt eigentlich diese Information? Hast Du irgendein Datenblatt >gefunden, was ich nicht gefunden habe? Kein Datenblatt. Aber beim Hersteller http://www.edtc.com/edt/Products/graphic.asp?search=graphic&page=2 gibt es für das EW13B30 ein Outline Drawing: http://www.edtc.com/edt/Products/specs/EW13B30.pdf Im Block Diagram, unten rechtes, findet man den Hinweis. MfG Spess
Walter Tarpan schrieb: > die andere > Hälfte leer bleibt Das Teil hat zwei Controller (erkennbar auch an CS1 und CS2), d.h. Du musst das Bild in zwei Teile zerlegen.
Pete K. schrieb: > Das Teil hat zwei Controller (erkennbar auch an CS1 und CS2), d.h. Du > musst das Bild in zwei Teile zerlegen. Walter Tarpan schrieb: > Das Display ist gesockelt und im > gleichen Sockel läuft ein TG12864B [...] einwandfrei.
Pete K. schrieb: > Ohne Deine Schaltung und Software zu kennen können wir Dir kaum > weiterhelfen... ...und jetzt bin ich auch wieder an Quelltext, Schaltung und Oszi habe alles da. Nur am Timing kann es schon einmal nicht liegen, da mit CKDIV/8-Fuse (AVR) sich am Ergebnis nichts ändert. Pete K. schrieb: > Wartest Du 50ms, bevor das LCDInit loslegt? Daran kann es auch nicht liegen, weil ich den Soft-Reset über den ISP mache und das GLCD die ganze Zeit versorgt wird. P.S.: Pete K.: Das könnte sich jetzt so lesen, daß es gegen speziell gegen Deine Anmerkungen geht - geht es aber nicht. Ich schließe nur gerade diese Punkte systematisch aus.
:
Bearbeitet durch User
Walter Tarpan schrieb: > Nur am Timing kann es schon einmal nicht liegen, da mit > CKDIV/8-Fuse (AVR) sich am Ergebnis nichts ändert. Lass mal an den Spareports zur Probe eine LED mit delay_ms(500) blinken, dann siehst Du, ob der AVR richtig eingestellt ist. Schon mal eine andere KS00108 Lib ausprobiert? JTAG aus? Und vielleicht mal die 1k8 herausnehmen, das ist etwas viel, wie sehen die Flanken auf dem Oszi aus?
:
Bearbeitet durch User
Deine Init-Prozedur würde ich mal neuschreiben, ohne Waitbusy, sondern mit den Zeiten streng nach Datenblatt. Ich tippe auf falsche Initialisierung.
OK, waitbusy sieht jetzt so aus:
1 | static void glcd_waitWhileBusy(void) { |
2 | |
3 | _delay_ms(10); |
4 | return; |
und es geht. Extrem langsam, aber es geht. Also ist es (mal wieder) das kitzlige busy-Flag. Danke für die Hilfe und die Anregungen! Viele Grüße W.T.
:
Bearbeitet durch User
>Also ist es (mal wieder) das kitzlige busy-Flag.
Die Abfrage von Busy habe ich schon vor langer Zeit beim KS00108
aufgegeben;)
Du nimmst aber ziemlich lange Delays. 4us hat bei mir bisher gereicht.
Je nachdem mit welchem Takt das Display läuft.
#define KS108_E_DELAY 2 // Pollin Display TG12864B 596kHz FCLK
//#define KS108_E_DELAY 4 // Displaytech 64240A 395kHz FCLK.
holger schrieb: > Du nimmst aber ziemlich lange Delays. Da liegt wohl ein Mißverständlich vor: Mit 10ms Wartezeit läuft das Display sicher. Und jetzt geht es daran a) entweder die Busy-Flag-Geschichte wieder in den Griff zu bekommen oder b) durch eine passende Wartezeit, entsprechend dem vorausgehenden Befehl zu ersetzen. Alles vorher war Ursachensuche. holger schrieb: > Die Abfrage von Busy habe ich schon vor langer Zeit beim KS00108 > aufgegeben P.S.: Wir wissan ja jetzt: Es ist gar kein KS0108, sondern ein S6B0108 ;-)
:
Bearbeitet durch User
Hi
>P.S.: Wir wissan ja jetzt: Es ist gar kein KS0108, sondern ein S6B0108
Na und. Hast du mal die Datenblätter verglichen? Sämtliche Spannungen,
Ströme, das Timing (nicht nur Bus), ca. 95% der Texte der Datenblätter
und sogar der Hersteller sind identisch.
Für mich gibt es zwischen beiden Controllern keinen Unterschied.
MfG Spess
spess53 schrieb: > Für mich gibt es zwischen beiden Controllern keinen Unterschied. Für mich auch nicht. Deswegen ja auch der Smiley. Aber alles halb so wild: Es geht schon wieder alles. Mit der folgenden kleinen Modifikation:
1 | static void glcd_waitWhileBusy(void) { |
2 | |
3 | GLCD_DATA_DDR = 0x00; |
4 | GLCD_DATA_PORT= 0xFF; |
5 | |
6 | |
7 | GLCD_CTRL_PORT &= ~(1<<GLCD_DI); |
8 | GLCD_CTRL_PORT |= (1<<GLCD_RW); |
9 | |
10 | _delay_us(1); |
11 | |
12 | do { |
13 | GLCD_CTRL_PORT &= ~(1<<GLCD_ECLK); |
14 | _delay_us(0.450); |
15 | GLCD_CTRL_PORT |= (1<<GLCD_ECLK); |
16 | _delay_us(0.450); |
17 | } while((GLCD_DATA_PIN & 0x80)!=0); // poll busy flag |
18 | |
19 | GLCD_CTRL_PORT &= ~((1<<GLCD_ECLK)|(1<<GLCD_RW)); |
20 | GLCD_DATA_DDR = 0xFF; |
21 | }
|
Funktionieren jetzt alle Displays und die Abfrage ist sogar ein Stück schneller.
:
Bearbeitet durch User
>Aber alles halb so wild: Es geht schon wieder alles. Mit der folgenden >kleinen Modifikation: Irgendwann werde ich mal ausprobieren ob mein langsames Display auf diesen BusyCheck reagiert. Dann werden wir sehen ob es eine maximal umständliche Routine für _delay_us(2) ist;)
Das würde mich auch interessieren - bis auf den Reset habe ich nämlich keine garantierten Ausführungszeiten für die Befehle gefunden.
Kannst du das _delay_us(1); vor dem BusyCheck mal kürzer machen? Laut Datenblatt sollten 140ns reichen.
Hi >Das würde mich auch interessieren - bis auf den Reset habe ich nämlich >keine garantierten Ausführungszeiten für die Befehle gefunden. Weil das vom Takt des Controllers abhängt. Im zulässigen Bereich dieses Taktes liegt die Busy-Zeit zwischen 2,5 und 60µs. MfG Spess
holger schrieb: > Kannst du das _delay_us(1); vor dem BusyCheck > mal kürzer machen? Laut Datenblatt sollten 140ns reichen. Ich hab's mal gerade ausprobiert: Ich kann es ganz weglassen. Nur momentan nicht mehr mit mehreren Displays testen, da der Apparat schon wieder zusammengebaut ist (das GLCD war nur ein "mal eben" von einem ATmega32 bei 16 Mhz auf ATmega644 bei 20MHz wechseln, weil ich mehr SRAM brauchte und dann, wenn schon alles gerade aufgeschraubt ist ein Display mit mehr Kontrast einbauen). spess53 schrieb: > Weil das vom Takt des Controllers abhängt. Im zulässigen Bereich dieses > Taktes liegt die Busy-Zeit zwischen 2,5 und 60µs Das heißt er ist zumindest bei jedem Befehl gleich? Nicht, daß ich motiviert wäre, beim Zeit vertrödeln besonders effizient zu sein, aber dann wären Refresh-Zeiten plötzlich deterministisch.
>Das heißt er ist zumindest bei jedem Befehl gleich?
Sieht nicht so aus.
Laut Datenblatt müsstest du aber nach einer fallenden Flanke
von E pollen können ohne E zu toggeln.
Geht das?
1 | static void glcd_waitWhileBusy(void) { |
2 | |
3 | GLCD_DATA_DDR = 0x00; |
4 | GLCD_DATA_PORT= 0xFF; |
5 | |
6 | |
7 | GLCD_CTRL_PORT &= ~(1<<GLCD_DI); |
8 | GLCD_CTRL_PORT |= (1<<GLCD_RW); |
9 | |
10 | _delay_us(0.14); |
11 | GLCD_CTRL_PORT |= (1<<GLCD_ECLK); |
12 | _delay_us(0.450); |
13 | GLCD_CTRL_PORT &= ~(1<<GLCD_ECLK); |
14 | _delay_us(0.450); // ist das nötig? |
15 | |
16 | do { |
17 | } while((GLCD_DATA_PIN & 0x80)!=0); // poll busy flag |
18 | |
19 | GLCD_CTRL_PORT &= ~(1<<GLCD_RW); |
20 | GLCD_DATA_DDR = 0xFF; |
21 | }
|
Hi
>Das heißt er ist zumindest bei jedem Befehl gleich?
Nein. Die Busy-Zeit wird mit 1/fCLK <= T Busy <= 3/fCLK angegeben.
MfG Spess
holger schrieb: > Laut Datenblatt müsstest du aber nach einer fallenden Flanke > von E pollen können ohne E zu toggeln Stimmt. War auch mein erster Versuch. Hat nur nicht funktioniert. Mit Weitertakten funktioniert es. spess53 schrieb: > Die Busy-Zeit wird mit 1/fCLK <= T Busy <= 3/fCLK angegeben. Ah, ich habe mich immer gefragt, wie dieses "Diagramm" zu lesen ist. Andersherum heißt das, daß ich bei einer Messung von fCLK das Warten sehr genau einstellen kann. Hmmm....mal sehen. Ein Controllerpin ist dazu noch frei. CLK1 und CLK2 sind im S6B0108 Eingänge. Wer stellt den Takt bereit?
:
Bearbeitet durch User
kurze Frage zum Thema:
> _delay_us(0.450);
Als C-Hobbyprogrammierer stellt sich mir folgende Frage:
ich kenne _delay_us nur mit ganzen Zahlen (_delay_us(10);). Was passiert
(im Listing), wenn man der _delay_us "0.450" übegibt? Sieht mir nach
"float" aus? Dauert float nicht immer übelst lange? Am Ende länger, als
die 0.45µs?
Danke
Klaus
Da "0.450" eine Konstante im Quelltext ist: Nein, das wird schon zur Compilezeit in eine Schleife und ein paar "nop"-Instruktionen umgewandelt.
Klaus auffa Arbeit schrieb: > Dauert float nicht immer übelst lange? Wenn denn mit float/double gerechnet würde, ja. Aber bei _delay_us muss man den Optimierer einschalten und die Takt-Frequenz kennen. Dann wird ein Aufruf mit Konstanten Wartezeiten in eine entsprechend lange Code-Sequenz "ausgerollt" (z.B. 437 * "NOP" o.ä.) Sie die Doku zu der Funktion:http://nongnu.org/avr-libc/user-manual/group__util__delay.html
Hi
>CLK1 und CLK2 sind im S6B0108 Eingänge. Wer stellt den Takt bereit?
Auf dem Display ist noch ein KS1070/S6B0107. Der hat einen RC-Oszillator
und erzeugt die beiden Takte.
MfG Spess
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.