1. Home
  2. Electronics (German)
  3. Komische Timingprobleme mit DOGM162 Display

Komische Timingprobleme mit DOGM162 Display

Hallo,

Zum Senden verwende ich folgendes Konstrukt:

struct spi_ioc_transfer xfer; xfer.tx_buf = (unsigned long)buffer; xfer.len = len; xfer.rx_buf = 0; xfer.delay_usecs = 0; xfer.speed_hz = 100000; xfer.bits_per_word = 8; int status = ioctl(fileno(file), SPI_IOC_MESSAGE(1), &xfer);

SPISend(0x39, 0x14, 0x55, 0x6D, 0x78, 0x38, 0x0C, 0x01, 0x06);

Um in die zweite Zeile zu kommen folgt ein:

SPISend(192);

Gefolgt von den Zeichen als Bytes mit "RS" auf "High".

Das Problem ist nun, dass ich nicht in die zweite Zeile komme.

Es reicht bereits wenn ich ein "printf" nach das "Init" setze und schon komme ich in die zweite Zeile. Ganz offensichtlich also ein Timing-Problem.

Scheinbar muss ich nach dem Senden des Init etwas warten bis wieder Befehle angenommen werden. Eigentlich habe ich erwartet, dass dieser ioctl-Aufruf solange blockiert bis die Befehle alle raus sind.

Danke im Voraus

Manuel

Reply to
Manuel Reimer
Loading thread data ...

Manuel Reimer schrieb:

Vorab: Ich kenne weder das genannte Display noch den verwendeten Controller ST7036 und habe mir mein Wissen nur gerade eben aus dem Datenblatt angelesen.

Ja, ioctl blockiert, bis das SPI-Kommando verschickt wurde. Aber

braucht z.B. das Kommando "Clear Display", das Du im Rahmen Deiner Init-Sequenz sendest, offenbar gut 1 ms.

Deshalb hat der Controller ein Busy-Flag, das man laut Datenblatt auch immer abfragen soll: "Be sure the ST7036 is not in the busy state (BF =

0) before sending an instruction from the MPU to the ST7036."

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net 
WWW: http://www.chzsoft.de/ 
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA
Reply to
Christian Zietz

formatting link

Mich wundert nur, dass die Init-Sequenz selber ohne Murren raus geht und

Datenpaket raus.

fest auf GND und DB7 fest auf +3,3V...

"sleep" nach jedem Befehl?

Manuel

Reply to
Manuel Reimer

Das ist eine schlechte Idee.

Nein, die korrekte Idee ist es das Status-Flag auszulesen bevor man loslegt. Spart auch einiges an Zeit wenn man nur solange warten muss bis

State-machine solange stillstand bis man das Statusregister gelesen hat! Soll heissen, hast du das Register nicht nach jeder Aktion ausgelesen stand der gesamte SCSI-Bus.

Gerrit

Reply to
Gerrit Heitsch

Manuel Reimer schrieb:

Das lange dauernde "Clear Display"-Kommando kommt auch als vorletzter Befehl der Init-Sequenz. Vielleicht passt bis dahin das Timing und dass

hat der Controller auch einen FIFO und kann (maximal) einen Befehl

Mir wird aus dem Datenblatt ohnehin nicht ganz klar, wie man das

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net 
WWW: http://www.chzsoft.de/ 
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA
Reply to
Christian Zietz

Hallo Gerrit,

Du schriebst am Sun, 21 Jun 2015 21:04:38 +0200:

aktuell

Schrieb er nicht was von Ansteuerung per SPI? Dann frag' ich mich zwar, was

ne,

it haben. Aber evtl. ist das bei dem benutzten ja anders.

sung ein 2ms

das nicht nach _jedem_ Befehl sein, aber auch nicht immer "nur" 2ms-

--
--  


----------------------------------------------------------- 

-----------------------------------------------------------
Reply to
Sieghard Schicktanz

Manuel Reimer schrieb:

Manche Quellen, die ich wg. DOGL128x64 gesichtet habe, machen ein paar ms Pause nach dem Init, bei Befehlen danach eher nicht.

deinem Display auch zutrifft.

void DOG_init() {

SPI_DDR = (1

Reply to
Marc Santhoff

Ich steuere Displays immer mit Delay. Das hat den Vorteil dass du nicht

Alle anderen Befehle brauchen nur 29us.

R/W hast du im SPI Modus sowiso nicht. miso werte ich nicht aus.

Gernot

Reply to
Gernot Fink

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.