Busy Flag bei LCD mit mit ST7036i?

[Mike (Gast)]

Hallo,

ich versuche gerade, ein alphanumerisches LCD der Firma Newhaven an 
einem ARM Cortex M0+ (SAMD20) in Betrieb zu nehmen. Das LCD wird über 
I2C bedient und besitzt einen Controller vom Typ ST7036i. Ich habe schon 
viel mit I2C gearbeitet, aber eine derartig verkorkste 
I2C-Implementierung ist mit bisher noch nicht untergekommen. Die 
Initialiserungsroutine habe ich sinngemäß aus dem Datenblatt übernommen:

void init_LCD()
{
I2C_Start();
I2C_out(Slave);//Slave=0x78
I2C_out(Comsend);//Comsend = 0x00
I2C_out(0x38);
delay(10);
I2C_out(0x39);
delay(10);
I2C_out(0x14);
I2C_out(0x78);
I2C_out(0x5E);
I2C_out(0x6D);
I2C_out(0x0C);
I2C_out(0x01);
I2C_out(0x06);
delay(10);
I2C_Stop();

Für die Kommunikation verwende ich das interne SERCOM-Modul und kein 
Bit-banging wie im Datenblatt. Die I2C-Routinen funktionieren mit 
anderen Bauteilen wie einem 24C256-EEPROM problemlos, deshalb nehm ich 
an, dass sie korrekt sind.

Leider läuft die Kommunkation mit dem LCD nicht durch:
Die Adresse und die ersten beiden Bytes werden korrekt übertragen (der 
Slave antwortet mit ACK), beim Kommando 0x39 hängt er sich dann auf 
(NAK).

Ich vermute einen Zusammenhang mit dem Befehl "delay(10)", dessen 
Bedeutung mir nicht ganz klar ist. Ich denke dass der Slave hier etwas 
länger braucht und per Clock-Stretching um etwas mehr Zeit bittet. Ein 
solches Clock-stretching kann ich im Oszilloskop aber nicht erkennen. 
Als Umgehungslösung
sende ich jetzt jedes Kommando in einem einzelnen Buszyklus, natürlich 
jeweils mit dem Kommandobyte 0x00 davor. Damit funktioniert die 
Initialsierung, allerdings nur bei 100kHz Taktfrequenz. Bei den nach 
Datenblatt erlaubten 400kHz kommt es weiterhin zu gelegentlichen NAKs.

Ein weiteres Problem bringt mich zum Verzweifeln: Wie lese ich das 
Busy-Flag aus? Laut Datenblatt muss ich dazu das RS-bit auf 0 und R/W 
auf 1 setzen. Sende ich aber das Adressbyte mit gesetztem R/W-bit, 
verweigert das Display die Antwort.
Mir ist vor allem aber nicht klar, wie ich das RS-bit dem Display 
mitteilen soll. Dazu muss ich doch erst einmal ein Kommandowort 
schicken, also R/W auf 0 setzen. Wie mache ich das? Ich habe schon 
folgendes Schema in Analogie zum Lesezugriff auf ein 24C256 versucht, 
jedoch ebenso ohne Erfolg:

I2C_Start();
I2C_out(Slave);//Slave=0x78, R/W = 0
I2C_out(Comsend);//Comsend = 0x00
I2C_Start();  //repeated start condition
I2C_out(Slave+1); //Slave  = 0x78, R/W=1
byte = I2C_in();
I2C_Stop();

Die Dokumentation des Displays liefert hier kein Beispiel. Leider 
schweigt sich auch das Datenblatt des St7036i über die Leseprozedur aus. 
Ich bin inzwischen mit meinem Latein am Ende und vermute einen Fehler im 
St7036i-Controller oder in der Dokumentation. Oder habe ich etwas 
Grundlegendes übersehen?
Deshalb meine Frage hier im Forum: Kennt sich jemand mit dem Teil aus 
und kann mir einen Tipp geben?

Vielen Dank

[pegel (Gast)]

Moin

In der pdf die im Dokument angegeben ist:

http://www.newhavendisplay.com/app_notes/ST7036.pdf

findest du ab Seite 41 das bei I2C erwartete Timing.

[pegel (Gast)]

Ein Beispiel Projekt findest du hier:

https://github.com/jbwright80/st7036i

[Mike (Gast)]

pegel schrieb:
> Ein Beispiel Projekt findest du hier:
>
> https://github.com/jbwright80/st7036i

Danke für den Link!
Die hängen an jeden Befehl 10ms Wartezeit dran und nicht nur 28us wie im 
Datenblatt angegeben. Eine Abfrage für das Busy-Flag ist leider auch 
nicht dabei.

[pegel (Gast)]

Nachdem in mir das Github Projekt noch mal angesehen habe, würde ich 
sagen, dass das Timing nicht für I2C, sondern für parallel Modus passt.
Scheint aber auch so zu funktionieren.

Ich würde sagen, über I2C ist die Abfrage des Busy Flag auch nicht 
möglich.

Siehe Seite 14 in der von mir gezeigten pdf:


It just only could write Data or Instruction to ST7036 by the IIC 
Interface.
It could not read Data or Instruction from ST7036 (except Acknowledge 
signal).

[Jacko (Gast)]

I2C ist ein schön resourcensparendes Modell, die Implementation
und Dokumetation bei den verschiedenen Slave-Chip-Herstellern ist
leider oft nicht sofort richtig brauchbar. Manchmal braucht es
undokumentierte "Rituale", um den Chip nutzen zu können.

Ging mir bei einem ADC-Chip ähnlich.

Kommst du jetzt mit 10 ms zwischen jedem Initialisierungsschritt
weiter?

[Mike (Gast)]

Jacko schrieb:
> I2C ist ein schön resourcensparendes Modell, die Implementation
> und Dokumetation bei den verschiedenen Slave-Chip-Herstellern ist
> leider oft nicht sofort richtig brauchbar. Manchmal braucht es
> undokumentierte "Rituale", um den Chip nutzen zu können.

Ich habe mal ine Serviceanfrage bei Newhaven Displays gestellt, man hat 
mich auf das Forum verwiesen. Dort steht tatsächlich, dass das Display 
keine Lesezugriffe erlaubt:

"Yes, unfortunately with the serial interface the controller's serial 
data pin is an input only. You would not be able to read from this 
display."

Ans busy flag kommt also grundsätzlich nicht heran, was soll dann dessen 
Erwähnung in der Dokumentation?


Ebenso, was die Taktfrequenz angeht (im Datenblatt sind max. 300kHz 
angegeben):

"There is a known issue on our serial LCD modules which affects its 
operation when used in I2C mode. When using the module’s I2C interface 
at a clock rate of 100KHz NACKs/bit errors/hanging, may occur. 
Therefore, if using the I2C interface of these serial LCD modules, a MAX 
clock rate of 50KHz should be used."

Mit 50 kHz scheint es tatsächlich zu funktionieren, auch ohne 
zusätzliche Wartezeit. Die 10ms Delay will ich vermeiden. Das ist für 
den Cortex eine halbe Ewigkeit, so dass eine simple Warteschleife nicht 
in Frage kommt. Ansonsten würde das schnarchlangsame Display meinen 
Controller ausbremsen.

Insgesamt bin ich ziemlich verärgert wegen der umsonst aufgewandten 
Arbeitszeit.
Da kauft man für teures Geld bei einem amerikanischen Markenhersteller, 
und der macht sich noch nicht einmal die Mühe, ein ordentliches 
Datenblatt zu schreiben. Noch nicht mal ein Errata-Sheet gibt es. Da 
hätte ich auch beim Billigchinesen kaufen können.