www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik EA-DOGM - LCD an SPI - Schnittstelle


Autor: Patrick R. (pat711)
Datum:
Angehängte Dateien:
  • 01.zip (18,9 KB, 55 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend zusammanen,

ich habe mal wieder ein Problem.
Ich bin bei der programmierung meines EA-DOGM 163, das ich über SPI 
betreiben will daran gescheitert, dass ich noch nie mit SPI gearbeitet 
habe.

Das LCD habe ich angeschlossen wie das Bild zeigt. der Controller ist 
ein ATmega88 mit 12MHz an 3,3V.

Hat mir jemand ein Beispiel zur Ansteuerung des Displays via SPI?
oder vielleicht einfach nur ein Beispiel zu Programmierung der 
SPI-schnittstelle.

In der Zip-Datei befinden sich meine bisherigen erfolge. Einen Teil 
davon (lcd_dogm.c) habe ich hier aus dem Forum. Es fehlt allerdings die 
Funktion "spi_transmit(0x00);" Das wird der mein nächster Schritt sein 
eine solche zu erstellen.

MfG Pat711

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok ein Beispielprogramm zur SPi habe ich nun gefunden. Nun bleibt das 
ganze nur noch auf das LCD zu übertragen.

MfG Pat711

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>In der Zip-Datei befinden sich meine bisherigen erfolge.

Das ist zusammengeklauter Schrott. Ein lauffähiges Programm
sieht etwas anders aus.

>Es fehlt allerdings die
>Funktion "spi_transmit(0x00);"

SPDR = 1; // sende eine 1
while( !( SPSR & (1<<SPIF) ) );

Lohnt kaum dafür ne Funktion zu schreiben;)

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem zusammengebastelt seh ich genau so. aber ich hab noch zu 
wenig erfahrung mir selbst eine SPI - Routine zu bauen.

Danke schon mal für den Tipp,
ich werde mich nu doch noch mal auf die Suche nach einem fertigen Code 
begeben. (3,3V EA-DOGM163, SPI) am besten eben dreizeilig aber das ja 
nur ne sache der konfiguration

MfG Pat711

Autor: Klaus S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Patrick,

guck mal bei: http://www.lcd-module.de/download.html

Da gibt es jede Menge fertigen Code u.a. auch für AVR

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen dank, auf der Seite war ich schon mal. Habe sie gestern dann aber 
wieder gesucht und einfach nicht finden können.

MfG Pat711

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Salü!

Ich habe mal mit einem EA-DOGM gespielt. Anbei siehst Du die 
Initialisierung, mit der ich das Display überredete, sich zu 
initialisieren sowie ein paar Pixel in den obersten acht Zeilen zu 
zeichnen.

Die SPI-Routinen machen für Dich keinen Sinn, da ich mit einem Cortex 
spielte.

Gruäss
Simon
void DispInit()
{
  int i;

  GPIOB->BRR |= GPIO_Pin_6; //Reset
  for(i=0; i<1000; i++);
  GPIOB->BSRR |= GPIO_Pin_6;
  for(i=0; i<1000; i++);

  GPIOA->BRR |= GPIO_Pin_6; //A0

  DispWrite(0x40);
  DispWrite(0xA1);
  DispWrite(0xC0);
  DispWrite(0xA6);
  DispWrite(0xA2);
  DispWrite(0x2F);
  DispWrite(0xF8);
  DispWrite(0x00);
  DispWrite(0x27);
  DispWrite(0x81);
  DispWrite(0x16);
  DispWrite(0xAD);
  DispWrite(0x01);
  DispWrite(0xAF);

  GPIOA->BSRR |= GPIO_Pin_6; //A0


  for(i=0; i<64; i++)
  {
    DispWrite(i);
  }
  for(i=63; i>0; i--)
  {
    DispWrite(i);
  }

  int j;
  for(i=1; i<8; i++)
  {
    DispChangePage(i);
    for(j=0; j<128;j++)
    {
      DispWrite(0);
    }
  }
}
void DispWrite(char data)
{
    GPIOA->BRR |= GPIO_Pin_4;
  SPI_I2S_SendData(SPI1, data);
  while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_BSY));
  GPIOA->BSRR |= GPIO_Pin_4;
}
void DispChangePage(char page)
{
  GPIOA->BRR |= GPIO_Pin_6; //A0
  DispWrite(0xB0 + page);        //2.Page
  DispWrite(0x10);
  DispWrite(0x00);
  GPIOA->BSRR |= GPIO_Pin_6; //A0
}

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank,

aber bei diesem Code fehlt doch auch noch was oder? die #includes?

MfG Pat711

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An diesem Code fehlt sogar noch 'ne ganze Menge! :-)

Die Includes würden Dir aber nichts nützen, weil Du ja einen AVR 
programmieren willst. Dieser Code stammt aus einem Cortex-Projekt.

Die Idee ist ja auch nur, Dir zu zeigen, was Du der Reihe nach tun musst 
mit dem Display, dass es funktioniert.

Das Folgende meine ich nicht böse:

Gib ganz schnell die Hoffnung auf, dass Du von Forumsteilnehmern und 
Internetseiten Codeschnippsel sammeln und dann einfach in LEGO-Manier 
zusammenfügen kannst. So einfach ist es in aller Regel nicht, wenn Du 
Dich im deeply-embedded bare-metal Bereich bewegst. Ausser, Du nimmst 
GENAU diese HW, für die dieser Code geschrieben ist, und übernimmst die 
GESAMTE Anwendung.

Ansonsten gibt's nur eins: Code anschauen, verstehen, genau wissen, was 
Du übernehmen kannst, was nicht, was Du selber dazufügen musst, was Du 
wie ändern musst...
Aber anfangen tust Du besser mit selber programmieren. Dann weisst Du 
nämlich, was Du tust. Wenn's auch anfangs nur kleine Brötchen sind, die 
Du bäckst.

Das macht es ja schliesslich auch spannend! Aber glaub mir: Wenn Dich 
das Display nach etlichen Stunden das erste Mal mit einem leuchtenden 
Pixel beglückt, ist das dann dafür ein umso geileres Gefühl! :-) Und ab 
da ist es nur noch ein kurzer Weg zum ersten "Hello World!"

--> Nichts mehr zusammenkramen! Selber Datenblätter lesen, und dann 
probieren, probieren, probieren! Und !! SELBER PROGRAMMIEREN !!

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Simon für diesen aufheiternden Beitrag^^

Ich habe gestern bereits begonnen einen eigenen Code zu schreiben und 
mir vorgenommen all meine erfahrungen die ich während dem entwickeln 
gemacht hab hier im forum zusammen zu tragen um nach mir kommenden das 
gesuche in tausenden foren zu ersparen.

>Das macht es ja schliesslich auch spannend! Aber glaub mir: Wenn Dich
>das Display nach etlichen Stunden das erste Mal mit einem leuchtenden
>Pixel beglückt, ist das dann dafür ein umso geileres Gefühl! :-) Und ab
>da ist es nur noch ein kurzer Weg zum ersten "Hello World!"

Oh ja das kenn ich. Vor allem von meinen Experimenten mit dem ARF32 
Bluetoothmodul, mit dem ich aber trotzdem noch nicht ganz fertig bin. Da 
hab ich des datenblatt wahrscheinlich schon 2-3mal durch, aber nun 
sendets immerhin ^^

MfG Pat711

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu diesen Displays gibt es doch was in der Codesammlung:
Beitrag "Library für EA-DOGM Grafikdisplays inkl. Font-Generator"

Hat bei mir sogar funktioniert, nach meinem Fix in der Initialisierung.

Jörg

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist doch für das Grafik-LCD von der serie oder?

MfG Pat711

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh verreckt, Du hat ja ein text-basiertes Display! Sorry, das habe ich 
übersehen. Vergiss den obigen Code, der passt vermutlich nicht.

Ganz wichtig bei Displays:
Die Datenblätter der Displays selber beschränken sich auf minimale 
Infos, die wirklich spezifisch für den entsprechenden Typ sind, sowie 
einige homöopathisch verabreichte Informationsschnipsel.

Du musst unbedingt das darin referenzierte Datenblatt des Controllers 
anschauen:

http://www.lcd-module.de/eng/pdf/zubehoer/st7036.pdf

Hast Du ein Oszi? Oder (besser) einen Logic-Alalyzer? Hört sich sehr 
teuer an, ist es aber nicht. Ist es zulässig, eine Marke zu nennen? 
Schau mal bei saleae.com vorbei. Aber es gibt auch vergleichbare 
Produkte zu vergleichbaren Preisen.
Generell ist so ein Teil aber fast ein must-have, vor allem für den 
Fall, dass Du kein Oszi hast (aber auch sonst). So kannst Du nämlich 
Schritt für Schritt vorgehen und erst mal sehen, ob Deine SPI überhaupt 
irgendwas schwatzt. Ansonsten hast Du viel zu viel frustrierenden 
Blindflug.

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Datenblatt habe ich schon angesehen. Musses nur noch ganz 
durcharbeiten.
Das mit dem analyser werd ich mit mal anschaun weil oszi hab ich derzeit 
noch keins. Überlege ir aber eines zuzulegen möglicherweise auch mit 
schnittstellenunterstützung (UART, etc.)

MfG Pat711

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Oszi ist 'ne feine  Sache. Aber die sind halt teuer.

Ein analoges kriegst Du sicher günstig. Die sind auch super geeignet für 
das, wofür sie halt gebaut sind. Protokollanalyse gehört definitiv nicht 
dazu.

Die Oszis, die das können, kriegst Du aber definitiv nicht mehr für ein 
Schinkenbrot. 4-5stellige Preise sind in der Einsteigerklasse üblich.

So ein kleiner Logic-Analyzer (die grossen Brüder von denen kosten auch 
5stellige Summen) tut's aber für Hobby-Anwendungen in den allermeisten 
Fällen. Wirklich schnelle Signale wirst Du nicht messen müssen, und 
bezüglich Protokollanalyse hast Du alles, was Du brauchst (läuft alles 
auf dem PC, der dran hängt). Ich kann das wirklich sehr sehr sehr 
empfehlen.

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
diue oszis die ich mir angesehen habe lagen alle so zwischen 400-800€. 
aber ich glaub die hatten alle das mit der analyse nicht dabei. Aber was 
ich auf jeden Fall gerne hätte ist ein USB - Host.

Ich werde mir nun trotzdem erst mal die Analyser ansehen. Als ergänzung 
bestimmt nicht schlecht^^.

MfG Pat711

Autor: xmega (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

Patrick R. schrieb:
> ich habe mal wieder ein Problem

schau mal hier: http://www.basteln-mit-avr.de/

Gruß xmega

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für den Link, ich dachte mir nun, gut dann mal einfach den 
code nehmen ohne zu ändern und auf nen 644er draufspiele der hier grad 
so rumfährt. Außer einer Anpassung an der Frequenz im Makefile habe ich 
nichts gemacht. Die habe ich auf 1MHz gestellt. das ist doch di 
standardfrequenz des internen oszillators oder?

Nun das Display hat immer noch ken Bock. Die Beschaltung hab ich auch 
angepasst. Was nun noch sein könnte ist, dass der interne oszillator vll 
zu ungenau ist oder meine Zuleitungen zu lang sind.

Zu der Schaltung: für die 2 externen Kondensatoren hab ich je 1µF Elkos 
genutzt. Die Spannungen die ich daran messe sind folgende:
C an 21 und 22: -0,13V
C an 24 und 25: -0,78V
jeweils nach Polung des Kondensators gemessen.
Pin21 gg. Masse:2,5V
Pin22 gg. Masse:2,44V
Pin24 gg. Masse:2,44V
Pin25 gg. Masse:3,22V

Aber wenn die Schaltung im LCD nicht aktiv ist wird hier ja auch nichts 
gewandelt.

MfG Pat711

Autor: xmega (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

Patrick R. schrieb:
> ohne zu ändern und auf nen 644er draufspiele

mit welcher Spannung läuft dein Atmega644?

– ATmega644V: 0 - 4MHz @ 1.8 - 5.5V, 0 - 10MHz @ 2.7 - 5.5V
– ATmega644: 0 - 10MHz @ 2.7 - 5.5V, 0 - 20MHz @ 4.5 - 5.5V

Das Display wird mit 3,3 Volt betrieben. Siehe dogm163.h, hier ist der 
3,3 Volt Typ definiert. Ansonsten musst du die #define nach 5 Volt 
ändern.

Zum Takt:

The device is shipped with internal RC oscillator at 8.0MHz and with the 
fuse CKDIV8 programmed,resulting in 1.0MHz system clock.

Wenn du nichts geändert hast, siehe Datenblatt, läuft dein Proz.
mit 8Mhz/8

> Die Beschaltung hab ich auch angepasst

Pins sind frei wählbar, da der interne SPI nicht verwendet wird!
Achtung: LCD_BACKLIGHT_PORT darf nicht mit "SPI-Port" kollidieren

> Anpassung an der Frequenz im Makefile
F_CPU hat keine Auswirkung auf die Einstellungen


Gruß xmega

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ändere Deine Vorgehensweise!

Auch wenn es paradox klingt: Selber code zu schreiben ist einfacher als 
Code zu übernehmen.

Du hast jetzt den bestehenden Code übernommen und bei ca. 1462 Stellen 
nicht so ganz genau gewusst, warum jetzt hier ein Pointer steht, ob jene 
Zeile, die Du auskommentiert hast, damit der Compiler nicht mehr moost, 
auch wirklich nicht benötigt wird, ob diese Änderung im Makefile - was 
immer das ist - auch wirklich mit der Frequenz zu tun hat.... und 
findest heraus: Es funktioniert nicht. Schön. Und jetzt? Du hast keine 
Ahnung, wo Du ansetzen sollst. Du weisst nicht einmal, ob die SPI 
überhaupt schwätzt, ob die GPIOs richtig konfiguriert sind, ob die 
Spannungen stimmen, ja, nicht einmal, ob das Ding vielleicht super 
funktioniert, aber auf irgendeine Geissart auf einen anderen Displaytyp 
konfiguriert ist...

Vorschlag (nochmals): Kauf Dir so ein Logic-Teil. Dann probier mal, 
einen Pin von Low auf High zu togglen. Wenn das geht, weisst Du schon 
ganz genau, wie Du die Ports konfigurieren musst.
Dann versuchst Du mal, die SPI-Schnittstelle so zu konfigurieren, dass 
sie irgendwas plaudert. Wenn das nicht klappt, weisst Du, dass der Haken 
irgendwo zwischen der SPI und dem GPIO liegt. Der für sich geht ja. 
Wenn's klappt, bist Du schon wieder viel gescheiter. Dann probierst Du 
mal, die Init-Sequenz auf das Display zu schreiben. Wenn's nicht klappt, 
schaust Du Dir mal mit dem Logic-Teil, ob die auch wirklich kommt. ..... 
etc....

Erst später, wenn Du weisst, wie das AVR-Gerät funktioniert, solltest Du 
Dir aus FAULHEIT Codesegmente kopieren. Grundsätzlich immer nur aus 
Faulheit, nie, weil man nicht weisst, was das denn nun für Zauberei ist, 
was das tut.

Bei diesen Baby-Steps kannst Du Dir übrigens auch viel besser helfen 
lassen! Ein Code-Schnippsel, das "blabla" auf die SPI-Schnittstelle 
schreibt, kannst Du hier als Vorschlag reinposten, und viele Leute 
werden Dir helfen, das so hinzubiegen, dass es das dann auch wirklich 
tut. Und Dir erklären, warum man es noch etwas umbiegen muss.

Autor: Patrick R. (pat711)
Datum:
Angehängte Dateien:
  • 06.7z (15,1 KB, 77 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Tag zusammen,

ich habe mit nun einen Logik-Analyser zugelegt und meinen eigenen Code 
geschrieben. Alledings zeigt das LCD nichts an. Die liegt (wie ich am 
Analyser sehen kann) daran, dass nur der Clock was sendet. Die anderen 
Signale sind still.
Der Clock wird 17 mal aktiviert, was mit dem Programm übereinstimmt (7 X 
Initialisierung und 10 X Daten)

Hab ich bei der Initialisierung der SPI etwas vergessen?

MfG Pat711

Autor: Patrick R. (pat711)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Morgen zusammen,
ich habe nun noch hier den Verlauf der Signale wie der analyser sie 
erkennt.

MfG Pat711

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Enable muß die ganze Zeit auf low sein. Von vor der ersten 
Taktflanke bis nach der letzten.


Peter

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Enable wird doch zu Beginn der Übertragung eines Bytes auf Low 
gesetzt und danach geht er wieder auf high, oder?
Im Programm habe ich das so eingebaut aber das geht genau so wenig wie 
der MOSI.

MfG Pat711

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Salü!

Habe nur kurz reingeschaut. Ich habe keine Ahnung von AtMegas, aber 
könnte es sein, dass Du das Interrupt Flag selber rücksetzen musst? 
Würde m.E. das Fehlverhalten erklären.

p.s. geiles Teil, das Saleae-Kästchen, gell? :-)

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Enable wird doch normalerweise zu beginn eines bytes auf low gesetzt 
und signalisiert dann auch wieder das Ende des bytes. oder?
Im Programm habe ich das auch so eingebaut. allerdings regt sich der SS 
irgendwie nicht. der RS allerdings funktioniert.

Das LOGIC hat schon was nun weiß ich halt warum es nicht geht aber es 
geht halt immer noch nicht ^^

MfG Pat711

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S

Patrick R. schrieb:
> nun weiß ich halt warum es nicht geht aber es
> geht halt immer noch nicht

Der Patient wird ja auch nicht gesund, nur weil der Arzt ihn mit der 
Röntgenmaschine bestrahlt. :-)

Fehlersuche macht so viel mehr Spass, nicht?


Also... immernoch dasselbe: Ich habe nicht nochmals in den Code geschaut 
(mangels Zeit). Vielleicht liege ich völlig falsch, aber schau das mal 
an:

SPI Enable geht kurz runter und sofort wider rauf. Dann passiert eine 
Weile lang nichts. Dann kommen Takte.

Stell Dir mal vor, ich habe recht, und Du hast vergessen, das 
Interrupt-Flag zurückzusetzen. Was mach dann Dein Code?

Er setzt Enable auf 0, startet die SPI-Maschine und wartet dann, bis das 
Byte gesendet ist... NÖÖÖÖÖ! Er wartet, bis das Interrupt-Flag gesetzt 
ist. Das war aber zuvor schon gesetzt! Du hast nämlich vergessen, es zu 
resetten! Also sofort wieder rauf. Darum der Spickel nach unten und 
gleich wieder rauf.

Wie gesagt, ich hab nur flüchtig drauf geschaut und das ist eine 
VERMUTUNG.


Warum keine Daten kommen, das ist dann wieder eine andere Baustelle. 
Erst mal das mit dem Enable lösen.

Gruäss
Simon

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.lcd-module.de/eng/pdf/zubehoer/st7036.pdf

Seite 47, so muß es aussehen.


Peter

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So sollte es auch aussehen wenn alles nach plan funktionieren würde. ich 
habe das programm anhand des PAP's entworfen welcher auch in dem 
Datenblatt enthalten ist.

MfG Pat711

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hilf mir mal: Du hast jetzt schon zweimal eine Antwort geschrieben, ohne 
auf meine Vermutung einzugehen. Heisst das:

a) Du hast das gechecked und das ist es nicht
b) Du wirst das noch anschauen
c) Du weisst nicht, was ich meine

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>So sollte es auch aussehen wenn alles nach plan funktionieren würde. ich
>habe das programm anhand des PAP's entworfen welcher auch in dem
>Datenblatt enthalten ist.

Das war auf die Antwort von Peter bezogen. Nach dem was du geschrieben 
hast muss ich erst nochmal genauer schaun.

MfG Pat711

Autor: Simon Huwyler (simi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, alles klar. :-)

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tag zusammen,

also ich habe nun nochmal einen Blick ins Datenblatt vom ATmega88 
geworfen. Dort steht drin, dass das SPIF - Bit gesetzt wird, wenn die 
Übertragung abgeschlossen ist. Rückgesetzt wird es automatisch, sobald 
ein Interrupt ausgelöst wurde, oder so wie bei mir, nach dem ersten mal 
abrufen.

MfG Pat711

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abend zusammen,

ich hab nun noch ein wenig rumprobiert. Nun habe ich ein Warning, 
welches mir bisher nicht aufgefallen ist:
main.c:9: warning: pointer targets in passing argument 1 of 'LCD_print_string' differ in signedness

Ich bin mir ziemlich sicher dass diese Warnung bisher noch nicht da war. 
Aber sie kommt nun auch wenn ich den selben Code compiliere, den ich 
hier hochgeladen habe. Wenn ich nun den Controller Flashe fehlen auch 
noch die Clock Signale!

So langsam bin ich echt am verzweifeln. Hat mir jemand eine Idee was die 
Ursache des Problems sein könnte?

MfG Pat711

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nun das Problem mit dem SlaveSelect gelöst. Es war in diesen 
Zeilen
  DDRB |= (1<<LCD_SS) | (1<<LCD_MOSI);    // setze MOSI,PB0 (SS) als Ausgang
  DDRB |= (1<<LCD_RS) | (1<<LCD_SCK);      // setze SCK, RS als Ausgang
folgendes gestanden:
  DDRB = (1<<LCD_SS) | (1<<LCD_MOSI);    // setze MOSI,PB0 (SS) als Ausgang
  DDRB = (1<<LCD_RS) | (1<<LCD_SCK);      // setze SCK, RS als Ausgang

wodurch nur die 2. Zeile wirkung hatte da sie die erste überschrieb. Nun 
fehlt aber trotzdem noch der Clock.
Die Warnung habe ich entfernt, indem ich auc
void LCD_print_string (unsigned char *buffer)
 dies machte:
void LCD_print_string (char *buffer)

MfG Pat711

Autor: Patrick R. (pat711)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch ein Bild des aktuellen Signalverlaufs

MfG Pat711

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick R. schrieb:
> main.c:9: warning: pointer targets in passing argument 1 of 'LCD_print_string' 
differ in signedness

Diese Warnung kannst Du ignorieren oder durch ein (void*) vor dem 
Pointer unterdrücken.

Der AVR-GCC macht leider auch einige unsinnige Warnungen.
Er akzeptiert für Stringfunktionen ausschließlich den Typ char.
Bei unsigned char, uint8_t oder int8_t warnt er.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick R. schrieb:
> Hier noch ein Bild des aktuellen Signalverlaufs

Da ist absolut garnichts zu sehen, was SPI auch nur entfernt ähnlich 
wäre.
Nimm dochmal das Software-SPI aus meinem Beispiel.


Peter

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für deine Antwort.

Ich habe ein Signal!!!

Ich habe im Datenblatt soeben noch einmal nachgelesen. der /SS Pin muss 
wenn er nicht als Ausgang verwendet wird auf "high" gehalten werden 
sonst stört er das SPI. Ich hatte PB0 für /SS gewählt und PB0 nicht 
weiter beachtet. Nun verwende ich diesen und siehe da. Mein CLK und 
sogar mein Mosi sind zurück ^^.

Jetzt fehlt noch der Schritt, dass auch das LCD noch funktioniert ^^.

und noch einmal zu den Warnings: die eine ist ja geklärt, die andere ist 
diese:
dogm_lcd.c:64: warning: value computed is not used
welche von diesen Zeilen kommt:
void LCD_print_string (unsigned char *buffer)
{
  while (*buffer != 0)
  {
    LCD_print_char(*buffer);
    *buffer++;
  }
}

Übersieht da der Compiler die Schleife?
Naja immerhin hats ja scheinbar keine negative Auswirkung.


MfG Pat711

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...  *buffer++; ...

Das Sternchen vor dem 'buffer' nuss weg. Du möchtest ja den Zeiger 
inkrementieren, nicht den Wert auf den er zeigt.

Autor: Patrick R. (pat711)
Datum:
Angehängte Dateien:
  • 07.7z (15,7 KB, 56 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Immer noch keine Reaktion des LCD :(
Hab ich vll in der Initialisierung nen Fehler?

Function Set1: 0b00111001 3 getrennte Zeilen, IS1

Function Set2: 0b00111001 3 getrennte Zeilen, IS1

Bias Set: 0b00010101 BS = 1/4 FX = 1

Contrast Set (lox byte): 0b01111101  (1101)

Power Control: 0b01010110 Icon aus, Booster an, Kontrast high(10)

Follower Control: 0b01101110 Fon = 1, Rab:(110)

Display On/off: 0b00001111 D=1 C=1 B=1

Zwischen den Befehlen liegen laut Logic immer ca. 16ms. Laut Datenblatt 
werden mindestens 26,3µs benötigt.


MfG Pat711

Autor: Patrick R. (pat711)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend zusamen,

ich habe meine Schaltung nun noch mehrmals geprüft und drei verschiedene 
LCD's verwendet. Aber immer noch keinen Erfolg erzielt.

MfG Pat711

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.