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

Groups > de.sci.electronics > #187535

Re: Komische Timingprobleme mit DOGM162 Display

Show all headers | View raw

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

Back to de.sci.electronics | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web