Komische Timingprobleme mit DOGM162 Display

21/06/2015 - 18:10 von Manuel Reimer | Report spam
Hallo,

ich habe im Betreff genanntes Display an einem Raspberry Pi hàngen.

Ich nutze den Hardware-SPI vom Raspberry über /dev/spidev*

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);

Ich sende zunàchst eine Init-Sequenz:

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.

Was mache ich falsch und wie wird das ganze zuverlàssig?

Danke im Voraus

Gruß

Manuel
 

Lesen sie die antworten

#1 Christian Zietz
21/06/2015 - 18:44 | Warnen spam
Manuel Reimer schrieb:

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.

Was mache ich falsch und wie wird das ganze zuverlàssig?



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
natürlich kann der Kerneltreiber nicht wissen, wie lange der
Displaycontroller intern benötigt, um das Kommando zu verarbeiten. So
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

Ähnliche fragen