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.
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?
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.
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?
>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
;-)
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
staticvoidglcd_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.
>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;)
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?
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?
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
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
