mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik DOG-M Display über SPI


Autor: Roland Schmidlin (rschmidlin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hoffe jemand von Euch kann mir helfen. Ich versuche gerade ein 2
Zeiliges DOG-M Display (von Reichelt) über SPI in Betrieb zu nehmen.
Wenn ich das richtig gesehen hab, ist der Clock im passiven Zustand auf
HIGH und die Daten werden bei der steigenden Flanke übernommen. Ich
versuche bisher die Initialisierung aus dem Datenblatt vom Controller
auszuführen und hinterher eine kurze Zeichenkette auszugeben.
Komischerweise wird die Zeichenkette jetzt ab und zu angezeigt, aber in
den meisten Fällen wird nach nem Reset nichts oder nur Schrott
ausgegeben.
Ist da jemandem von Euch was bekannt, dass es da Probleme mit dem
Timing oder ähnlichem geben könnte?

Hoffe jemand kann mir helfen.

Gruß Roland

Autor: Roland Schmidlin (rschmidlin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keiner ne Idee?

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Roland !

Scheint mir ein Timing-Problem zu sein.
Hast Du das mal überprüft ??

LG Ron

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, nochwas: Eventuell Pullups manuell ergänzen.

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ronald,

ich habe nur ein DOG-M 16-3 im 4 Bit Modus zum laufen gebracht.
Ich weiß nicht, wie die SPI Version ist, aber beim "normalen"
hatte ich erst auch einige Probleme, da es anders als andere
Displays initialisiert werden muß.

Bei mir war es erst so, daß das Display bein Power on nichts
anzeigte.
Nach einem Reset ging es plötzlich.
Es hatte mit der Initialisierung zu tun.
Die aus dem Datenblatt funktioniert bis heute bei mir nicht!

Hier meine INIT des DOG-M 16-3 in C.

_long_delay();
_lcd_init_write(0x30);
_long_delay();
_lcd_init_write(0x30);
_long_delay();
_lcd_init_write(0x30);
_long_delay();
_lcd_init_write(0x20);
_long_delay();

_lcd_ready(); // RS=0
_lcd_write_data(0x29);

_lcd_ready(); // RS=0
_lcd_write_data(0x14);

_lcd_ready(); // RS=0
_lcd_write_data(0x7A);

_lcd_ready(); // RS=0
_lcd_write_data(0x51);

_lcd_ready(); // RS=0
_lcd_write_data(0x6A);

_lcd_ready(); // RS=0
_lcd_write_data(0x0C);

_lcd_ready(); // RS=0
_lcd_write_data(0x01);

_lcd_ready(); // RS=0
_lcd_write_data(0x06);

// Zurück zur Tabelle 0:1
// _lcd_ready(); // RS=0
// _lcd_write_data(0X28);

Vielleicht hilft es dir ja.

Gruß Toby

Autor: Roland Schmidlin (rschmidlin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Euch beiden,

ich werde mir meine Initialisierung nochmal anschauen und versuchen
meine Leitungszustände mittels PullUps noch ein bisschen sauberer
hinzukriegen. Hab mitm Oszi festgestellt, dass da ab und zu n paar ganz
hässliche Spitzen beim umschalten drauf sind.

Gruß Roland

Autor: ege (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi ich habe auch vor den 3x16 zu kaufen und über die SPI zu Steuern habe
jedoch in der beschreibung keinerlei hinweise gefunden wie die SPI
Schnittstelle zu betreiben ist könnt ihr mir da weiterhelfen

DANKE!

Autor: ege (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zurück zu deinem problem in dem datenblatt
http://www.electronic-assembly.de/eng/pdf/zubehoer...
steht

"Bitte beachten Sie, dass aufgrund der COG-Technik die
  Strombelastbarkeit der Ausgänge begrenzt ist. Es kann
  dadurch bei größerer Buslast zu Signalverschleifungen
  und unsauberen Pegeln kommen.
  Im Zweifelsfall sind zusätzliche Pull-Down Widerstände (8051)
  erforderlich, oder es müssen zusätzliche Waits/NOP's
  eingefügt werden."


Ich denke dass wird es wohl sein.

Aber wie gesagt finde ich leider kein support über die SPI Schittstelle
bitte um hilfe!!!

Autor: denba (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also ich kann nur sagen: mit der standard-initialisierung lt. datenblatt
läufts via spi auch ohne pull-ups einwandfrei - nie ein problem gehabt.
denba

Autor: Florian S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
habe mir auch das DOG-M 163 über SPI angetan. Ich mach da jetzt schon
seit Tagen rum, aber auf dem Display tut sich gar nichts. Nach dem
Befehl Cursor ON müsste der ja eigentlich zu sehen sein. Meine
Initialisierung hab ich unten aufgeführt. An der hab ich inzwischen
keine Zweifel mehr.

Display ON
wait >40ms
RS=0
0x38
wait >26,3µs
0x39
wait >26,3µs
0x1D
wait >26,3µs
0x50
wait >26,3µs
0x6C
wait>200ms
0x7C
wait >26,3µs
0x0F
wait >26,3µs
0x01
wait>2ms
0x06

und wie das auf dem Logik-Analyzer aussieht seht ihr im Anhang. Ich
habe das CS- Signal allerdings noch etwas rausgezögert.
Ich bin mir nur nicht sicher was den Clock im passiven Zustand
betrifft. Der ist bei mir anders als im Datenblatt des ST7036
gefordert, LOW. Das müsste doch egal sein,oder?
ich sollte vielleicht noch dazu sagen: Das SPI Bussignal wird
hardaremässig mittels einem Microwire Interface Baustein
(TP3465)erzeugt.

Ich hoff mal, mir kann jemand weiterhelfen.

Gruß,
Forian

Autor: Roland Schmidlin (rschmidlin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,

ich hab' das Display mittlerweile auch zum laufen bekommen. Ich poste
hier morgen mal meine Initialisierung und schau mal nach, wie ich die
Pegel/Flanken an meinem SPI-Controller konfiguriert hab. Da das Teil
jetzt schon seit längerem funktioniert hab ich das nicht mehr alles im
Kopf. Ich verwende das integrierte SSI-Interface von einem Philips
LPC2132-Controller. PullUps/-Downs verwende ich auch keine.

Gruß Roland

Autor: Barti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab 2 Tage gebraucht, um einen SPI-Treiber für ein 16x2 DOG zu
schreiben. Wenn mich nicht alles täuscht, stimmt eine Wartezeit im
Datenblatt nicht(jedenfalls damals). Das Timing bei der Initialisierung
ist relativ kritisch, danach funktioniert alles perfekt. Teilweise habe
ich das Problem, wenn ich einen Reset mache, wird das Display nicht
richtig initialisiert. Also nochmal das Timing prüfen...

Autor: Florian S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Barti,
das mit dem Timing hab ich mir auch gedacht. Deshalb hab ich auch da
auch sehr drauf geachtet. Kannst du mir vielleicht mal dein Timing
posten? Kann man auch zu lange Pausen setzen? Denk mal nicht, oder?
Welche Frequenz hat denn dein Clock?


Gruß,
Florian

Autor: ege (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
in der Doku steht wenn man probleme meiden möchte sollte man Pull Down
Widerstände verwenden. Beim Neustart oder nach einem Reset soll es ab
und zu zuunsauberen Pegeln kommen.

Autor: ege (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
denba machst du das in asm oder C?

Autor: ege (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie sieht eigentlich lcd_write_data aus

Autor: Barti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gewünscht meine "quick'n'dirty" Initialisierung für ein 16x2 DOG
mittels AVR:

void LCD_Init(BYTE display)            //LCD initialisieren
{
  DDRB = (1<<RS) | (1<<CSB) | (1<<SPI_MOSI) | (1<<SPI_SCLK);
  PORT &= ~(1<<CSB);
  SPCR |= ((1<<SPE) | (1<<MSTR) | (1<<CPOL) | (1<<CPHA));      //SPI
(Master) aktivieren mit CPOL = 1 und CPHA = 1 und fosc = 1/4
  _delay_ms(40);
  PORT &= ~(1<<RS);
  LCD_SendCmd(0x38);                //8-bit Datenlänge, 2 Zeilen, 
Instruction
Table1
  LCD_SendCmd(0x39);                //8-bit Datenlänge, 2 Zeilen, 
Instruction
Table1
  LCD_SendCmd(0x1C);                //Bias Set: 1/4, 2-zeiliges LCD
  LCD_SendCmd(0x74);                //Kontrast C3, C2, C1 setzen
  LCD_SendCmd(0x52);                //Booster aus, Kontrast C5, C4 
setzen
  LCD_SendCmd(0x69);                //Spannungsfolger und Verstärkung 
setzen
  _delay_ms(200);                  //Wartezeit bis Spannung stabil 
>200ms
  LCD_Switch(display);              //Display ein
  LCD_Clear();                  //Display löschen, Cursor Home
  LCD_SendCmd(0x06);                //Cursor Auto-Increment
}

Hoffe das hilft.

MfG Barti

Autor: Barti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wird eigentlich der Sourcecode hier ordentlich dargestellt? Da gab
es doch mal so eine Funktion...

Hier noch die wichtige LCD_SendCmd() Funktion vergessen:

void LCD_SendCmd(BYTE Command)
{
  PORT &= ~(1<<CSB);
  _delay_us(1);
  SPDR = Command;
  while(!(SPSR & (1<<SPIF)));
  _delay_us(30);                  //kleine Wartezeit um SPI-Daten zu 
schreiben
  PORT |= (1<<CSB);
}

Autor: FS1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin zusammen,

hab den code Barti mal durchprobiert.

Ging nicht so richtig....

Ist die Verdrahtung so richtig ?

ATMEGA                   DOG-M
------------------------------------
PB0             ->         RS
PB1             ->         CSB
PB4(MISO)       ->         SI
PB5(SCK)        ->         CLK

hat vielleicht jemand ein code der mit SPI richtig funktioniert ?

komme leider mit SPI und LCD garnicht klar ?

hab ne atmega8 8Mhz, benutze WinAVR, hab den SPI teiler auf 16, also
500khz

Gruß FS1

Autor: Ssss Ssssss (sssssss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>PB4(MISO)       ->         SI
ne, MOSI muss nach SI (DOG)
(master out, slave in: daten vom uc zum display.)

Bye, Simon

Autor: FS1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
den fehler hatte ich auch schon gefunden, aber leider klappt das auch so
nicht


FS1

Autor: .... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du must auf das Timing achten. Du darfst nicht zu schnell hintereinander
zwei Bytes senden. Das habe ich gelöst, in dem ich die Frequemz des
SPI-Takt relativ klein halte.

Autor: FS1 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
moin, hab jetzt den Teiler auf 32, also 250kHz.

Sind die Timings nicht vom SPI Clock abhänging ?

Auf Seite 43 stehen "wohl" die Timings von 380kHz, muss ich die
umrechnen ?

Autor: FS1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der SPI Programme hängt ja auch an den Pins vom Display...

Wenn ich jetzt nun den Code an den uC schicke, dann leuchte paar
Zeichen usw auf, nachher ist manchmal dir blinkende cursor zusehen.

Ist ja komisch, das irgendwelche wirren Daten das Display initialisiern
können, und mein prog schafft das nicht :)


Gruß FS1

Autor: FS1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uups, da sind mir wohl 1,2 schreibfehler untergekommen...

Autor: .... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ab Seite 26 stehen die Ausführungszeiten. Achte z.B. darauf, dass
"Clear Display" über 1ms benötigt, in dieser Zeit darfst du kein
weites Komando senden. Soweit ich weiß, hängt das nicht von SPI-Takt
ab.

Autor: FS1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
erstmal vielen dank an alle die mir hilfreich tipps gegeben haben.

Die initialisierung klappt jetzt so einigermaßen, jedefall sehe ich
jetzt ne blinkenden cursor.

     juhu, das DISPALY lebt :)


naja jetzt muss ich noch wat ordentliches anzeigen lassen


Gruß FS1

Autor: Florian S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die DOG-Module sind ja mit der COG-Technik gefertigt. Dh. der Chip und
die Leitungen befinden sich direkt auf dem Glas. Ich hatte das Problem,
dass ich das Display beim Einlöten zu sehr beansprucht habe und einige
Verbindungen gebrochen sind.

Könnte ja bei dem ein oder anderen hier auch das Problem sein.

Gruß,
Florian

Autor: FS1 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

wollt mich nochmals bedanken...


@Florina
Das mit dem einlöten sieht ganz gut bei mir aus, die Pins sind recht
stabil



Gruß FS1

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@FS1: Kannst du deinen Source und die gemachten Einstellungen speziell
des Taktes bitte einmal posten! Danke!!

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht kann hier ja einer der Experten noch Licht ins Dunkel bringen
:-) Ich versuch jedenfalls mich in das DOG-Lcd am SPI-Bus einzudenken.

Eigentlich dachte ich, dass SPI bei den ATMegas MOSI, MISO, SCK und je
Slave ein Slave-Select-Pin verwendet. Schau ich mir die Doku für das
DOG Lcd an, so sehe ich dort MOSI, SCK, Slave-Select und RS. Laut Info
hier wie auch woanders wird RS an einen freien Pin von Port B
angeschlossen (und nicht an MISO).

- Was macht RS dann?
- Und - newbie Frage, ich weiss - ist diese 4-Draht-Lösung orginal SPI,
auch wenn ich statt MISO einen anderen Pin/Port belege?


cu & danke, Michael

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RS kannst du an jeden IO Pin am AVR anschließen, nimm einfach einen den
du sonst nicht brauchst. RS bestimmt ob die Daten die der AVR gerade
ans Display schickt Steuerkommandos sind oder darzustellende Zeichen.

MISO heißt Master In Slave Out, da das Display nichts sendet brauchst
du es nicht (soweit du nur das Display am SPI hängen hast). Wenn du den
AVR also als Master only benutzt könntest diesen Pin auch für RS nehmen
(hab ich aber nicht getestet, schau mal ins Datenblatt deines AVR unter
SPI).

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo gibt es mittlerweile denn eine funktionieren Initalisierung in
Assembler?
Ich komme mit der SPI gar nicht zurecht.

Es wäre sehr nett wenn ein  Vorposter, oder natürlich auch ein anderer
:-) , mal nen Code bereit stellen könnten.
Benutz nen Atmega8515 wie gesagt mit Assembler.

Vielen Dank schonmal an die Profis die das Display zum Laufen gebracht
haben^^

MfG
Michael

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@danilo, so hab ich es auch verstanden. Danke für die Erläuterung.

Nur ging ich bis jetzt davon aus, dass bei einer sternförmigen
Verdrahtung ich bei SPI 3 (MOSI, MISO, CLK)  + <n> Pins benötige. <n>
ist hierbei die Anzahl der Slaves.

Mit dem DOG-Display brauche ich jetzt aber: MOSI, MISO, CLK, <n> Slave
Select + RS, also ein Pin mehr. Das soll bei meinem Fall nicht das
Problem sein, wundert mich aber schon :-)

cu, Michael

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael Z.: Ja, so ist das bei diesem Display :)

@Michael: ich habe nur Code für den GCC... prinzipiell basiert der aber
auch nur auf den schon geposteten Beispielen + ein wenig rumprobieren.

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tag zusammen,

hat jemand einen funktionierenden Quelltext für den SPI-Mode vom
Dog-Display in Verbindung mit Bascom?!

gruss
Norbert

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein ASM zuerst bitte :-)

Sieht so aus als wohl öfter Probleme mit dem Display auftreten.
Bin immernoch verzweifelt am rumprobieren um irgendwie dieses Display
zu initialisieren.

Code in Assembler wird gerne angenommen^^

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, also poste mal deinen Code, dann schau ich mal was evtl falsch
ist.

Mir ist aufgefallen, das man den SPI Takt vor dem Senden "manuell"
hochziehen muss, sonst gehts nichts.

Autor: Kai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich versuche auch verzweifelt eine 5V-Version aber als 4Bit.
Bei mir ist auch das Display tot. Hat da vielleicht eine in
assembler/bascom abhilfe?

Vielen Dank

Autor: Norbert (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab ich im Forum gefunden und klappt auch (4bit 5V):

Autor: Kai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh, also ich habe andere pin-configuration. Muß deswegen der
assemblertext verändert werden? weil bei mir klappt das nicht...

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du kannst das Display entweder so anschließen wie es im Basic Quelltext
steht oder du passt den Quelltext an.
unter dem CLS muss natürlich noch dein text in Form von LCD
"TEXTTEXT" kommen.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kenn mich ja nicht so aus aber hab jetzt schon ewig rumprobiert und komm
nicht weiter.
Hier mal mein Code für die Initialisierung:
LCD_Init:


rcall  delay40us
ldi   A,0x38
rcall   datatakt
rcall   delay30us

ldi    A,0x14
rcall   datatakt
rcall   delay30us

ldi   A,0x78
rcall  datatakt
rcall  delay30us

ldi    A,0x5E
rcall   datatakt
rcall   delay30us

ldi   A,0x6A
rcall   datatakt
rcall   delay200ms

ldi   A,0x0F
rcall  datatakt
rcall  delay30us

ldi   A,0x01
rcall   datatakt
rcall   delay2ms

ldi   A,0x06
rcall   datatakt
rcall  delay30us
end:  rjmp end

Sollte nach der Initialisierung nicht wenigstens mal ein Cursor oder so
zu sehen sein?!
Oder was mache ich falsch?

Danke schonmal für Eure Hilfe!

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nutzt du Hardware SPI?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein mach ich per Software.

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, die Initialisierung sieht nicht so schlecht aus.

Ich würde vermuten der Fehler liegt im Timing, oder die Pegel deines
SPI sind anders als es das LCD erwartet!? Manche SPI Chips übernehmen
Daten bei fallender, andere bei steigender Flanke des Taktes.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Werd mir das nochmal anschauen und rumprobieren und mich dann nochmal
melden^^

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie ist denn die maximale Frequenz für mein Clock-Signal?
Kann im DB nix finden.

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, ich hab 16.000.000 als uC Takt und 128 als Vorteiler. Die Timings
im Datenblatt von EA sind für 380kHz - 700kHz angegeben.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat denn hier wirklich niemand einen funktionierenden Code in Assembler
für diese Display?

Ich denke auch das es ein Timing Problem ist aber hab mich ans DB
gehalten und darüber hinaus jetzt auch schon sehr viel rumprobiert aber
es will einfach nicht.

Nach meiner Inttialisierung sollte doch wenigstens eine Cursor zu sehen
sein oder!?

MfG
Michael

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja sollte... ich nehme zwar an du hast... mal die elektrischen
verbindungen kontrolliert?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja hab ich...nicht unr einmal :-)
Das sollte aber soweit passen....kein Plan an was es liegen könnte.

Bei SPI muss ich ja D5-D0 + E + RW auf 3,3 Volt legen.
Kann ich diese Pins denn auch direkt an µC Pins hängen und diese auf
High schalten?
Oder hat der zuwenig Power oder so?

Würd sich auf Steckbrett halt anbieten...

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bekomm es einfach nicht hin...
Meint ihr es würde etwas bringen EA mal direkt anzuschreiben?
Eher nicht oder...?

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dachte ich mir schon :)

Ich habs auch aufm Steckbrett laufen und diese Pins direkt an VCC (bei
mir allerdings 5v).

Hmm, die sagen meist nur "Distributor fragen". Aber versuchs doch
mal...

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Version des Displays hast du denn?
Hast du mit oder ohne Beleuchtung da manche ja anscheinend dringend
eine Beleuchtung brauchen und andere nicht...

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe DOGM163S-A (3x16 , Schwarzer Hintergrund) + LED 55X31-W (weiß).

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, soll keine Blöde Frage sein ,also nicht falsch verstehen:

Hast du die Caps für den 3.3 Betrieb richtig rum verbaut? Und kannst du
mal 5v testen?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist mir recht wenn jemand frägt, egal was solange es helfen könnte.
Hab mir die Caps nochmal angeschaut aber das passt.

5V passiert genau sowenig wie 3,3 V....nämlich nix :-(

Oh mann Oh mann....mach an diesem sch**** Display rum und nix passiert.

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
probier doch meinen Code aus, den gibts in C und Assembler für alle
möglichen Ansteuerungen. ist für ein zweizeiliges display, sollte aber
schnell umzuschreiben sein.
Über die Suche sollte der zu finden sein.
Dann kann man die Init evtl. ableiten oder teilweise direkt übernehmen
und hardwarefehler aussschließen.
(habe den beitrag hier nicht komplett gelesen, erahne daher nur, wo
probleme liegen)

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, würde ich auch vorschlagen. Teste mal Wolframs Code. Kannst auch
meinen haben, müsstest da aber das Delay anpassen, da ich FreeRTOS
benutze und dort einfach den Task suspendiere.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also der Code funzt leider nicht.
Keine Ahnung was da nicht passt aber das Display macht absolut gar
nix.
Hab jetzt mal auf 8bit umgestellt aber geht leider auch nicht.

Vermute fast ein Timing-Problem aber hab schon so viel rumprobiert.
Im Datenblatt sind ja Ausführungszeiten der Befehle bei
380KhZ...540Khz....700Khz angegeben.

Wie kann ich denn die Frequenz ändern bzw. einstellen?

MfG
Michael

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na das Timing bestimmst du durch deinen SCK. Die Länge einer Periode ->
1/"HIGH über Low bis wieder High" (in s).

Nimm einfach 1ms für (fast) alles, damit hat das Display genug Zeit zum
"arbeiten".

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das ist klar aber bin gerade am testen mit 8bit
Da fällt CLK ja weg...

Aber das Display muss ja auch irgendeine "geschwindigkeit" haben.
Also ich kann ja meine Befehle wahrscheinlich nicht alle direkt
hintereinander senden sondern muss ein paar nops und so einfügen.

Wie schnell erkennt oder reagiert das Display auf Flankenwechsel usw.
mein ich.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seh glaub bald vor lauter Bäumen den Wald nicht mehr.
Bin gerade am grübeln ob die 8 Datenleitungen so stimmen weil das im
Datenblatt Seite 4 etwas komisch beschrieben ist.

Kommt da an Pin D7 des Displays das Bit 7 oder das Bit 0 an?

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bit7 (MSB)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also am Pin 28 D7 des Displays ist MSB.

Z.B. PortD,7  <------->  D7

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollte so stimmen!

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lol bin jetzt wieder bei SPI da das mit den 8bit auch nicht
funktionierte.
Mit dem call "Hardware Reset" ist das trennen von der Spannung bzw.
einschalten der Spannung ausreichend oder?

Oder muss ich da erst mit nem Pin auf low ziehen und anschliessend
wieder auf High setzen?

Autor: Maggi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo erstmal,
habe eigentlich das selbe Problem wie die meisten hier, bin jetzt schon
seit ein paar Tagen dran, aber ich bekomme das DOG nicht über SPI
initialisiert, ich habe die 8bit und die 4bit Initialisierung am laufen
aber SPI will einfach net.
Ich habe zuerst mit dem integrierten SPI des Mega 8 gearbeitet und bin
mittlerweile "back2basics" da ich es einfach nicht verstehe warum das
nicht läuft. Hier mal meine Initialisierung:

rcall  delay50ms
ldi  temp,0b00111000
rcall  SPI_MasterTransmit
rcall  delay50us
ldi  temp,0b00111001
rcall  SPI_MasterTransmit
rcall  delay50us
ldi  temp,0b00011100
rcall  SPI_MasterTransmit
rcall  delay50us
ldi  temp,0b01111111
rcall  SPI_MasterTransmit
rcall  delay50us
ldi  temp,0b01010010
rcall  SPI_MasterTransmit
rcall  delay50us
ldi  temp,0b01101001
rcall  SPI_MasterTransmit
rcall  delay250ms
ldi  temp,0b00001111
rcall  SPI_MasterTransmit
rcall  delay50us
ldi  temp,0b00000001
rcall  SPI_MasterTransmit
rcall  delay50us

Laut Datenblatt sollte sie so laufen, ich habe aber auch schon andere
folgen versucht:
(0x38)(0x39)(0x1C)(0x74)(0x52)(0x69)(0x0C)(0x01)(0x06)
(0x38)(0x39)(0x14)(0x78)(0x5E)(0x6A)(0x0C)(0x01)(0x06)

Meine Hardware ist ein Mega8@1MHz und das Dog hängt an:
PB0-CSB PB1-RS PB3-SI PB5-CLK
Die SPI_MasterTransmit habe ich nun mittlerweile auf die mir einfachste
bekannte weise geschrieben:

sbrs  temp,7 bis 0
cbi  PortB,3
sbrc  temp,7 bis 0
sbi  PortB,3
sbi  PortB,5
nop
nop
cbi  PortB,5
usw.

Eigentlich ähnlich der vorgehensweise im original Datenblatt.. aber es
kommt einfach nix :-(

Ich habe mal meinen assembler code angehängt, vielleicht kann man
gemeinsam was finden woran es liegt, wenn man ja erstmal so ca. wüsste
was man dem Ding schicken muss und in welchen abständen.

Gruß an Alle :-)

Autor: Danilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich hab mir nur den Ausschnitt angeschaut, nicht den gesamten
Source. Hast du schonmal versucht deinen Takt "umzutauschen". Also
anzunehmen das die Daten bei High->Low (jetzt ist wenn ich das richtig
sehe Low->High) übernommen werden?

Autor: Maggi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, so habe noch mal alles etwas umgeschrieben

sbrs  temp,7
cbi  PortB,SI
sbrc  temp,7
sbi  PortB,SI
cbi  PortB,CLK
rcall  delay50us
sbi  PortB,CLK
rcall  delay50us

mit der Steigenden Flanke wird alles übernommen, zumindest sind im
Datenblatt Pfeile an der steigenden Flanke, ich warte jetzt auch nach
jedem Byte 50ms und das CLK Signal lasse ich im 50us Takt ansteigen und
abfallen, dann sollte doch jetzt alles gehen, aber es tut sich einfach
nix.... Ich sende Bit 7 bis Bit 0 und das nun mittlerweile extrem
langsam, aber einfach kein erfolg :-( Vielleicht findet ja noch wer
was.

Gruß Maggi

@Danilo: Danke für den Tipp :-)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss es denn unbedingt SPI sein?
Hatte das auch versucht aber wollte einfach nicht klappen.
Wie auch du habe ich am timing rum gemacht und probiert aber kein Plan
warum es nicht geht.

Hab jetzt den Code hier aus dem Forum für 8bit benutzt und jetzt läuft
das Display einwandfrei.

Also wenn du eventuell auf SPI verzichten kannst versuch erstmal den
8bit Code.
Kannst danach wenn es läuft ja versuchen mal nach SPI hin anzupassen.

MfG
Michael

Autor: Maggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, 8bit und 4bit habe ich schon am laufen, würde aber gerne auch noch
spi zum laufen bekommen, würde natürlich im gegensatz zu 4bit noch mal
3 Leitungen sparen, das ist ja bekanntlich immer gut ;-) Außerdem hasse
ich es wenn etwas nicht klappt ;-)
Also ich hoffe mal das hier jemand noch ne erleuchtung hat, kann ja net
sein das das so schwer ist, das SPI interface soll ja eigenlich eine
erleichterung für den Programmierer sein und nicht ein Alptraum!

Gruß Maggi

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja wenn das so ist :-)
Wie gesagt ich habs nicht hinbekommen aber wenn es bei dir klappt würd
ich mir gerne mal den Code bzw. die init mal ansehen^^

Viel Glück noch!

Autor: Maggi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Freudige Nachricht, habe es jetzt endlich mit meinem SPI hin bekommen,
habe auch gleich die Routine für den internen SPI das Mega8
geschrieben, jetzt läuft endlich alles :-)
Wer es testen möchte hier die Pinbelegung (Kann unter den Definitionen
natürlich geändert werden):

CSB  PB2(SS)
SI   PB3(MOSI)
RS   PB4(MISO)
CLK  PB5(SCK)

Timings sind für einen Mega8@1MHz

Danke noch mal an alle die gepostet und geholfen haben :-)

Gruß Maggi

P.S: Wer den Init noch mal in der alten (Simplen Form (sbrc/sbrs) haben
möchte bitte kurze Mail)

Autor: Michael Z. (incunabulum)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die ganzen Infos hier! Ohne die wäre ich wohl wirklich
aufgeschmissen gewesen.

Anbei für C++ als Eclipse-Winavr (workspace verzeichnis) meine
SPI-Lösung. Ein Umbau auf C sollte eigentich kein Problem sein.
Getestet auf einem atmega32 mit 1 Mhz und 16 Mhz.

Der Code ist noch nicht richtig schön, einige Debug-Anweisungen (PC.7)
sind noch drin. Aber das wichtigeste kann man hoffentlich erkennen.

Vielleicht kanns ja jemand gebrauchen

cu, Michael

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ALLE

ein sehr nützlicher Thread, hat mir sehr viel Zeit erspart,

den ST7036 im SPI Modus zu initialisieren.

Danke

Bernhard

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

hab leider auch noch Probleme und hab mittlerweile allesmögliche 
getestet.

Vielleicht findet jemand ja die Zeit sich folgendes durchzulesen.
Beitrag "Probleme mit DOG-M (128x64)"


Danke ;-)

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein lauffähiges Beispiel mit einem DOG-LCD 128x64 für einen Atmega8 in 
Assembler:

Beitrag "DOG LCD 128x64 Initialisierung ATmega8 (Assembler)"

Bernhard

Autor: HellStorm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Nach langem hin und her habe ich es geschafft meinen Bildschirm zum 
laufen zu kriegen. Dabei bin ich auf ein paar Merkwürdigkeiten gestossen 
die evtl. auch bei anderen vorkommen.

Daten:
DOGM 163 LCD
5V Hardware SPI Modus
ATmega168
Dragon (USB Programmer)

Ich habe festgestellt dass der Bildschirm sich manchmal initalisieren 
liess als er am ausgeschalteten (!) Programmer hing. Hab dann mal am RS 
Port des Bildschirms (hängt an MISO) die Pegel gemessen. Mein Messgerät 
hatte einen schwachen Akku also sind die Werte nicht exact.

Am Programmer angeschlossen (vom PC getrennt) liegt high bei 2,8V und 
low bei 0V. Abgekoppelt liegt high bei 4,6V und low bei 1,8V! Die 
meisten anderen getesteten Ports erzeugen fast 0V bei low. Ist das eine 
Eigenheit des MISO Ports? Ich habe dazu nirgends was finden können.

Na jedenfalls half dann ein Pulldown-Widerstand von etwa 600kOhm 
zwischen GND und MISO/RS um Pegel von 0V / 3,2V zu erreichen. Damit 
lässt er sich zuverlässig initialisieren.

Belegung:
RS -> MISO
CSB -> Masse
CLK -> SCK
SI -> MOSI

Initialisierung:
sendcmd(0b00111001,0);    //Instruction table 1
sendcmd(0b00111001,0);    //Instruction table 1
sendcmd(0b00010101,0);    //bias /frequency
sendcmd(0b01110000,0);    //power control 0b01010000
sendcmd(0b01101100,300);  //follower control
sendcmd(0b01111101,0);    //contrast 0b01111101
sendcmd(0b00111000,0);    //Instruction table 0
sendcmd(0b00001100,0);    //display on, cursor settings
sendcmd(0b00000001,5);    //clear lcd
sendcmd(0b00000110,0);    //entry mode



Hoffe das hilft einigen

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das eine ansteckende Seuche? Warum denkt dieses Wochenende jeder 
hier, dass man Schaltungen besser verbal als bildhaft rüberbringt?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HellStorm wrote:

> Ich habe festgestellt dass der Bildschirm sich manchmal initalisieren
> liess als er am ausgeschalteten (!) Programmer hing.
> ...
> CSB -> Masse

Ja, das ist ja auch kein Wunder, daß es nur zufällig funktioniert, wenn 
Du CSB fest auf GND hängst.

Damit fehlt jede Möglichkeit für LCD und AVR, sich zu synchronisieren.
Die SPI-Pins des AVR sind ja nach dem Reset tristate, d.h. floaten wild 
rum.
Daß dann das LCD synchron ist, ist reiner Zufall. Die Pulldowns 
entschärfen das leicht, aber zuverlässig ist das noch lange nicht.
Mach mal ein Reset ohne Powerdown und wenn dabei grad das LCD 
angesteuert wurde, sind sie wieder asynchron.

Wenns zuverlässig sein soll, muß man den CSB-Pin vom AVR mit ansteuern.
Das hat dann auch den Vorteil, daß man weitere SPI-Chips (z.B. 
74HC165/74HC595) mit ansteuern kann.

Es hat schon seinen guten Grund, daß im SPI-Schaltbild im Datenblatt der 
CSB nicht direkt auf GND gelegt ist, sondern vom MC angesteuert wird.

Ich hatte noch nie Probleme mit dem DOG-M, weil ich immer den CSB 
benutze.


Peter

Autor: HellStorm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CSB hing vorher an einem Port. RESET hing an VCC. Ich musste CSB dann 
auf GND legen weil keine Ports mehr frei hatte und den RESET ansteuern 
wollte. In beiden Fällen, also auch mit CSB an SS, lief der Bildschirm 
nicht zuverlässig.

Also künftig 5 Ports für den Bildschirm frei halten....

Autor: Daniel Reinke (sliderbor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Laut Datenblatt kann man den RESET Pin doch einfach an Vcc hängen! Dann 
resettet das Display selbst, wenn zwischendurch der Saft weg war. Mehr 
braucht man doch nicht, oder?

Autor: HellStorm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja RESET kann normalerweise an VCC (dort hing er auch vor der Umstellung 
wie bereits erwähnt). Aber zu Testzwecken war es doch praktisch den 
anzusteuern um zu sehen wann sich der LCD initialisieren liess ohne 
ständig den Saft an und aus zu schalten.

Autor: andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach tagelanger Suche läuft nun auch mein EA DOGM162-A mit SPI (der 
Cursor blinkt, juhu!!), der Code von Maggi hat mir geholfen. Mein Fehler 
war, dass ich CSB per Atmega328 (10 MHz, 3,3V) gleich von Anfang an auf 
0 geschaltet habe, ohne es vorher auf 1 zu schalten. Da passiert einfach 
gar nichts (Reset ist fest mit 3,3V verbunden).

Meine Routine sieht nun so aus:
CSB=1
40 ms warten für "VDD stable"
CSB=0
Initialisierung so wie im Datenblatt von LCD-Module.de beschrieben.

Die Wartezeiten nach den jeweiligen Befehlen (Function Set etc. siehe 
Datenblatt ST7036) dürfen auch deutlich länger sein, in meinem Fall sind 
es z.B. 26 ms anstatt der 26,3µs. SPI Geschwindigkeit hat bis 2,5 MHz 
funktioniert.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.