Forum: Mikrocontroller und Digitale Elektronik EA-DOG S 102 Ansteuerung


von Steven (Gast)


Lesenswert?

Hallo,

Versuche nun schon seit einigen Tagen das im Betreff genannte Display in 
Betrieb zu nehmen. Bislang jedoch leider ohne Erfolg.

Das Display habe ich wie im Datenblatt beschrieben mit einem ATMega16 
verbunden:

ATMega  I DOGS102
________I_________
MOSI    I SDA
SCK     I SCK
PB0     I CD


CS0 liegt auf GND und RST auf VCC.
Sonstige Kondensatoren und Stromanschlüsse sind auch wie im Datenblatt 
beschrieben angeschlossen.

Nun bin ich mir recht sicher dass ich hardwaretechnisch alle richtig 
gemacht habe.

Ich habe folgenden C-Code compiliert und auf den Controller geschrieben. 
Erwartet habe ich nun eigentlich einen schwarzen Balken von 1 * 8 Pixel.
Vielleicht kann mal wer über den Code blicken und sieht vielleicht auf 
Anhieb meinen/ meine Fehler.

(Auch ein Delay von etwa 30ms nach jedem gesendeten Byte brachte keinen 
Erfolg.)

1
#include<avr/io.h>
2
3
void SPI_MasterInit(void) //SPI Intialisierungsbeispiel aus ATMega16-Datenblatt
4
  {    // MOSI, SCK und PB0 als Ausgang
5
      DDRB |= ((1<<7)|(1<<5)|(1<<0));
6
    // SPI Konfiguration (Richtiger SPI-mode?)
7
      SPCR |= (1<<6) | (1<<4) | (1<<3)|(1<<2); // SPI-Enabled, Mastermode, SPI-mode
8
      SPSR = (1<<0);
9
}
10
11
void sendCommand(char command)
12
  {   
13
     // PB0 auf low -> Command!
14
      PORTB &= ~(1<<0);
15
    //Daten in SPI Data-Register
16
      SPDR = command;
17
    //Warten bis Byte komplett gesendet
18
      while(!(SPSR &(1<<SPIF)));
19
  }
20
21
void sendData(char data)
22
  {
23
    //PB0 auf high -> Data!
24
      PORTB |= (1<<0);
25
    //Daten in SPI Data-Register
26
      SPDR = data;
27
    //Warten bis komplett gesendet
28
      while(!(SPSR &(1<<SPIF)));
29
  }
30
31
void DisplayInit(void)    //Initialisierungsbeispiel aus DOG102-6 Datenblatt
32
  {
33
    sendCommand(0x40); // 
34
    sendCommand(0xA1);//
35
    sendCommand(0xC0);//
36
    sendCommand(0xA4);//
37
    sendCommand(0xA6);//
38
39
    sendCommand(0xA2);//
40
    sendCommand(0x2F);//
41
    sendCommand(0x27);//
42
    sendCommand(0x81);//
43
    sendCommand(0x10);//
44
45
    sendCommand(0xFA);//
46
    sendCommand(0x90);//
47
    sendCommand(0xAF);//
48
49
    
50
  }
51
52
int main(void) 
53
  {
54
     //SPI initialisieren
55
      SPI_MasterInit();   
56
    //Display initialisieren
57
      DisplayInit();
58
    //Balken von 8*1 Pixel in Column 0, Page 0
59
      sendData(0xFF); 
60
    //Show SRAM content
61
      sendCommand(0xA4); // Daten anzeigen!
62
63
64
65
66
    while(1);  //Endlosschleife
67
    
68
  }


MfG

Steven

von olikraus (Gast)


Lesenswert?

Hi Steven

Mir sind zwei Sachen aufgefallen:

1. Die Chip-Select Leitung dauerhaft auf GND zu legen ist riskant.
Über die fallende Flanke an der CS0 Leitung wird das Kommunikations-
register im DOGS zurückgesetzt. In der Tat ist die Frage, ob nicht
nach dem Reset hier eine fallende Flanke notwendig ist, um
überhaupt mit dem DOGS kommunizieren zu können.

2. Soweit ich das sehe fehlt in der sende-Routine das Auslesen des 
Datenregisters zum Zurücknehmen des Interrupt-Flags.

siehe Zeile 270 hier:
http://code.google.com/p/dogm128/source/browse/libraries/Dogm/utility/dogmspi.c
Das dogm128 projekt unterstützt auch das dogs102 modul...

Grüße,
Oli

von Roman (Gast)


Lesenswert?

Es fehlt auch das Reset Timing! Siehe Datenblatt Seite 33, in etwa so:

1. Power On
2. Set RST to LOW
3. Wait >= 1 ms
4. Set RST to High
5. Wait >= 5 ms
6. Start commands....

Bei meinen Routinen reicht bei 5. auch 1 ms wait.

Wenn Du also RST auf High hast, hat der LCD Controller evtl zu wenig 
Zeit sich zu initialisieren und wird daher die ersten Kommandos der 
Initialisierung gar nicht mitbekommen.

Gruss
Roman

von Steven (Gast)


Lesenswert?

Also als erstes möchte ich mal ein riesiges Dankeschön an euch 
loswerden!
Sehr freundliche und kompetente Hilfe die ihr zwei mir hier gegeben 
habt.

Habe eure Anregungen in mein Programm einfließen lassen und siehe da -
mit dem folgenden Code werden immerhin schon mal die Daten die ich sende 
fehlerfrei angezeigt. Der Rest des Displays ist zwar noch Pixelsalat, 
was aber durch Überschreiben des gesamten Displayinhalts in den Griff zu 
bekommen sein sollte.
Direkt nach der Programmierung des ATMegas wird leider kein 
Displayinhalt dargestellt, was aber vermutlich daran liegen sollte, dass 
der ISP-Programmer den Displaycontroller etwas durcheinander bringt, da 
die beiden ja am selben SPI-BUS hängen.

Was mich gerade aber etwas verwundert ist, dass die gesendeten Daten 
auch ohne den Befehl "show SRAM content"(0xA4) angezeigt werden.
Werde mir im Datenblatt die Befehlstabelle wohl nochmal zu Gemüte führen 
müssen.

1
#include<avr/io.h>
2
#define F_CPU 1000000
3
#include <util/delay.h>
4
5
#define CHIPSELECT     PORTB &= ~(1<<1);
6
#define CHIPUNSELECT  PORTB |=  (1<<1);
7
8
#define DATA       PORTB |= (1<<0);
9
#define COMMAND      PORTB &= ~(1<<0);
10
11
#define RESETHIGH    PORTB |= (1<<2);  
12
#define RESETLOW    PORTB &= ~(1<<2);
13
14
15
void SPI_MasterInit(void)
16
  {  //Dieser Programmabschnitt scheint funktionsfähig zu sein,
17
}
18
19
unsigned char spi_out(char b)
20
{
21
    //Byte senden
22
      SPDR = b;
23
    //Warten bis Sendevorgang komplett
24
      while(!(SPSR &(1<<SPIF)));
25
    //SPIF löschen durch lesen von SPDR
26
      return SPDR;
27
28
}
29
30
void sendCommand(char command)
31
  {    CHIPSELECT;      
32
       COMMAND;
33
    //Byte senden
34
      spi_out(command);
35
      CHIPUNSELECT;    
36
  }
37
38
void sendData(char data)
39
  {     CHIPSELECT;
40
      DATA;
41
    //Byte senden
42
      spi_out(data);
43
      CHIPUNSELECT;
44
  }
45
46
void DisplayInit(void)
47
  {   //Display reset
48
    RESETLOW;
49
    _delay_ms(1);
50
    RESETHIGH;
51
    _delay_ms(5);  
52
    
53
    //Display init
54
55
    sendCommand(0x40);
56
    sendCommand(0xA1);
57
    sendCommand(0xC0);
58
    //sendCommand(0xA4);
59
    sendCommand(0xA6);
60
61
    sendCommand(0xA2);
62
    sendCommand(0x2F);
63
    sendCommand(0x27);
64
    sendCommand(0x81);
65
    sendCommand(0x10);
66
67
    sendCommand(0xFA);
68
    sendCommand(0x90);
69
    sendCommand(0xAF);
70
71
72
73
    
74
  }
75
76
int main(void) 
77
  {   SPI_MasterInit();
78
    DisplayInit();
79
    /*Ein Paar Daten testweise senden.
80
    Erwartung: Schwarzes Kästechen von 5*8 Pixeln in der
81
    oberen linken Ecke*/
82
    
83
    sendCommand(0b00000000);
84
    sendCommand(0b00010000);
85
    sendData(0xFF);
86
    sendCommand(0b00000001);
87
    sendCommand(0b00010000);
88
    sendData(0xFF);
89
    sendCommand(0b00000010);
90
    sendCommand(0b00010000);
91
    sendData(0xFF);
92
    sendCommand(0b00000011);
93
    sendCommand(0b00010000);
94
    sendData(0xFF);
95
    sendCommand(0b00000100);
96
    sendCommand(0b00010000);
97
    sendData(0xFF);
98
    //SRAM Inhalt darstellen!
99
    //sendCommand(0xA4);   //Merkwürdig!
100
101
    while(1);
102
    
103
  }

MfG
Steven

von olikraus (Gast)


Lesenswert?

Hi Steven

Prima, wenn wir Dir soweit helfen konnten.

Meiner Erfahrung nach muss man nicht vor jedem Byte an dem Chip Select 
ziehen. Es reicht, wenn man das beispielsweise vor dem neu-Zeichnen des 
Bildschirminhalts macht.

Was die Störungen des ISPs betrifft, hilft ein einfacher pull-up an der 
Chip-Select Leitung. Wenn der ATMEGA programmiert wird, gehen nämlich 
die Ports alle auf LOW, was das Display fälschlicherweise als 
Chip-Select interpretiert. Damit versucht das Display dein Hex-File als 
Daten oder Commandos zu interpretieren.

Siehe Schaltplan und Beschreibung hier:

https://code.google.com/p/dogm128/wiki/dogm132_atmega88_hardware

Widerstand R5 (etwas schwer erkennbar) dient genau diesem Zweck den 
Pixelsalat durch den ISP zu verhindern.

Grüße,
Oli

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.