Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #187497 > unrolled thread

Komische Timingprobleme mit DOGM162 Display

Started byManuel Reimer <Manuel.Nulldevice@nurfuerspam.de>
First post2015-06-21 18:10 +0200
Last post2015-06-22 21:40 +0200
Articles 4 — 4 participants

Back to article view | Back to de.sci.electronics

Contents

  Komische Timingprobleme mit DOGM162 Display Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> - 2015-06-21 18:10 +0200
    Re: Komische Timingprobleme mit DOGM162 Display Christian Zietz <newsgroup.1001@chz.xyz> - 2015-06-21 18:44 +0200
      Re: Komische Timingprobleme mit DOGM162 Display Marc Santhoff <m.santhoff@t-online.de> - 2015-06-22 04:30 +0200
      Re: Komische Timingprobleme mit DOGM162 Display Gernot Fink <g.fink@gmx.net> - 2015-06-22 21:40 +0200

#187497 — Komische Timingprobleme mit DOGM162 Display

FromManuel Reimer <Manuel.Nulldevice@nurfuerspam.de>
Date2015-06-21 18:10 +0200
SubjectKomische Timingprobleme mit DOGM162 Display
Message-ID<mm6nm1$7e3$1@news.albasani.net>
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

[toc] | [next] | [standalone]

#187499

FromChristian Zietz <newsgroup.1001@chz.xyz>
Date2015-06-21 18:44 +0200
Message-ID<cuo7vvFklsbU1@mid.individual.net>
In reply to#187497
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

[toc] | [prev] | [next] | [standalone]

#187535

FromMarc Santhoff <m.santhoff@t-online.de>
Date2015-06-22 04:30 +0200
Message-ID<20150622043013.74f3b6a2@puma.das.netz>
In reply to#187499
Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> schrieb:

> On 06/21/2015 06:44 PM, Christian Zietz wrote:
> > Vorab: Ich kenne weder das genannte Display noch den verwendeten
> > Controller ST7036 und habe mir mein Wissen nur gerade eben aus dem
> > Datenblatt angelesen.
> 
> Danke für den Tipp. Ich hatte das Datenblatt:
> http://www.lcd-module.de/pdf/doma/dog-m.pdf
> 
> > 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.
> 
> Mich wundert nur, dass die Init-Sequenz selber ohne Murren raus geht
> und wohl auch ausgeführt wird. Die sende ich mit "Full-Speed"
> komplett als Datenpaket raus.

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

Aber es gibt einen Bug, der bewirkt, daß man ein doppeltes
Reset-Kommando als erstes senden muß. Weiß jetzt nicht, ob das bei
deinem Display auch zutrifft.

Beispiel von µC.net (für AVR):

void DOG_init()
{
// Der Timer2 für die LED wird in DOG_dimm_led() konfiguriert

SPI_DDR   = (1<<SPI_Clock) | (1<<SPI_DO) | (1<<SPI_SS) | (1<<SPI_RESET)
| (1<<SPI_A0); SPI_PORT |= (1<<SPI_SS)   | (1<<SPI_A0) | (1<<SPI_RESET);
SPCR = (1<<SPE)|(1<<MSTR); 				// Enable
SPI, SPI in Master Mode

SPI_PORT  = ~(1<<SPI_RESET);       		// Reset the Display
Controller asm volatile ("nop");
SPI_PORT |=  (1<<SPI_RESET);

SPSR =
1<<SPI2X; // Takt Verdoppelung SPCR = 1<<SPE | 1<<MSTR | 0<<SPR1 |
0<<SPR0; // 1/ CPU Takt * 2

DOG_write_cmd(DISPLAY_SCAN_DIR_REVERSE);		// C8
DOG_write_cmd(DISPLAY_BOTTOMVIEW);				// A0
DOG_write_cmd(DISPLAY_NORMAL);					//
A6
DOG_write_cmd(DISPLAY_BIAS_1_9);					//
A2 DOG_write_cmd(DISPLAY_POWER_ALL_ON);  			// 2F
DOG_write_cmd(DISPLAY_VOLTAGE_RESISTOR); 		// 26
DOG_write_cmd(DISPLAY_VOLUME_MODE_1);			// 81
DOG_write_cmd(lcd_contrast);						//
Kontrast DOG_write_cmd(DISPLAY_INDICATOR_OFF);
			// AC
DOG_write_cmd(DISPLAY_INDICATOR_MODE_OFF); 	// 00
DOG_write_cmd(DISPLAY_ON);
						// AF

//font_width = 6;
font_typ   = FONT_NORMAL;

DOG_cls();
}


> > 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."
> 
> Das würde bedeuten ich müsste etliches umbauen. R/W habe ich aktuell
> fest auf GND und DB7 fest auf +3,3V...
> 
> Ich steuere das Display aktuell über Hardware-SPI und einen
> zusätzlichen GPIO für RS an.

Laß es. Das DOGL hat nur SPI-Bus und ist ebenso wenig mit einem
Datenausgang ausgestattet. Und im Datenblatt steht es so, wie Du es
verdrahtet hast. Der Chip mag senden können, ist aber im Display
drumrum von EA offensichtlich nicht vorgesehen.
 
> Ich gehe mal davon aus, dass der Chip die im Datenblatt angeführten
> Ausführungszeiten etwa einhält? 

weiß ich nicht.

> Also als pragmatische Lösung ein 2ms
> "sleep" nach jedem Befehl?

Probiers, entweder reicht es nach Reset oder der Controller schiebt so
schnell Daten bzw. Kommandos nach, daß sich das Display verschluckt.
Odeer der Reset-Workaround greift.

Marc

[toc] | [prev] | [next] | [standalone]

#187625

FromGernot Fink <g.fink@gmx.net>
Date2015-06-22 21:40 +0200
Message-ID<nt4m5c-dn5.ln1@garv.home>
In reply to#187499
In article <cuo7vvFklsbU1@mid.individual.net>,
	Christian Zietz <newsgroup.1001@chz.xyz> writes:
> 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."

Ich steuere Displays immer mit Delay. Das hat den Vorteil dass du nicht
ständig lesen und prüfen mußt. 
Außerdem läuft das Gerät bei Diaplayhängern problemlos weiter.

Ich wüdre mir einfach eine Home und eine CLR funktion mit 3 ms Delay machen.
Alle anderen Befehle brauchen nur 29us.

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

Gernot

[toc] | [prev] | [standalone]

Back to top | Article view | de.sci.electronics

csiph-web