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
>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;)
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
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
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 !!
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
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.
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
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.
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
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
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
Ä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.
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
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
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? :-)
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
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
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
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
>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
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
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
Ich habe nun das Problem mit dem SlaveSelect gelöst. Es war in diesen
Zeilen
1
DDRB|=(1<<LCD_SS)|(1<<LCD_MOSI);// setze MOSI,PB0 (SS) als Ausgang
2
DDRB|=(1<<LCD_RS)|(1<<LCD_SCK);// setze SCK, RS als Ausgang
folgendes gestanden:
1
DDRB=(1<<LCD_SS)|(1<<LCD_MOSI);// setze MOSI,PB0 (SS) als Ausgang
2
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
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
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
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:
1
dogm_lcd.c:64: warning: value computed is not used
welche von diesen Zeilen kommt:
1
voidLCD_print_string(unsignedchar*buffer)
2
{
3
while(*buffer!=0)
4
{
5
LCD_print_char(*buffer);
6
*buffer++;
7
}
8
}
Übersieht da der Compiler die Schleife?
Naja immerhin hats ja scheinbar keine negative Auswirkung.
MfG Pat711
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
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
Thread beobachten
Seitenaufteilung abschalten