mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Probleme mit SPI auf Atmega 128


Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wir haben ein Displaymodul von display3000.com. Der Atmega spricht das 
verbaute Display über SPI an (wahlweise Hard oder Software). Jetzt 
wollte wir 2 weitere Elemente über SPI anbinden. Nämlich einen DSP und 
einen MMC-Connector.

Leider bereitet uns das SPI einige Probleme und zwar folgendes:
Zunächst haben wir die Version mit Software-SPI für das Display 
verwendet. Hierbei werden zwar die SPI-Ports des Atmega benutzt (also 
SCLK,Data, etc) jedoch über Funktionen geschaltet.
Wir haben dann für die Ansteuerung des DSP Hardware-SPI mit den 
entsprechenden Voreinstellungen durch Registereinträge konfiguriert und 
gestartet.
Ergebnis: sobald man das SPI Enable Bit setzt geht nichts mehr.
Grund: Wahrscheinlich kollidieren die verschiedenen Taktraten. Das 
Software-SPI läuft nahezu mit vollem Takt während wir für Hardware einen 
Vorteiler von 128 genommen haben.

Also nächster Versuch:
Ansteuerung von Display und DSP mit Hardware-SPI. Die Routinen für das 
Display sind vorhanden, brauchten wir also nicht ändern. Auch hier läuft 
der Takt nur mit einem Vorteiler von 2. Wir haben dann eigene Routinen 
geschrieben, die das Hardware-SPI mit unseren gewünschten Einstellungen 
laden. Diese Routinen werden dann VOR einer Befehlsausgabe zum DSP 
aufgerufen, anschließend werden wieder die alten SPI-Einstellungen für 
das Display hergestellt.
Ergebnis: Es hängt wieder am SPI-Enable Bit, wird es gesetzt...geht 
nichts mehr. Auch wenn man vor der Neukonfigurierung alle SPI-Register 
auf 0 setzt, bleibt der Fehler bestehen.

Letzter Versuch:
ALLE Header,Funktion usw die mit dem Display zu tun haben entfernt. Auch 
aus dem Makefile. Dadurch sollte nur noch der Atmega128 angesprochen 
werden.
Umgesetzt wurde SPI über Hardware mit Polling dann EXAKT nach der 
passenden Atmel-Application-Note (hab die Nummer gerade nicht im Kopf). 
Es wurden nur die Pins angepasst, die von der Application Note zum 
Atmega128 etwas verändert sind.
Das ganze wurde mit AVR-Studio 4 simuliert und dort lief alles. Man kann 
schön den Registern zugucken wie sie Bytes in SPDR laden usw...
Also alles fix mit Programmers Notepad kompiliert und auf das Board 
geladen.
Ergebnis:
Nichts.....mit dem Oszilloskop sieht man daß auf den SPI-Ports tote Hose 
ist.
Ich hab dann noch zum Vergleich in einer while(1) PortD komplett auf 
High gelegt.
Im AVRStudio ebenfalls problemlos simuliert. Wieder kompiliert und 
runtergeladen. Weder Action auf den SPI-Ports noch ist PortD auf High.

Fazit:
Sobald ich das SPI-Enable Bit setze scheint sich das ganze System 
abzuschießen.
Obwohl das Bit in den passenden Funktionen fürs Display läuft. Wenn ich 
ein Programm aufs Board lade, was nichts macht als auf dem Display 
irgendwas anzuzeigen dann kann ich auf den SPI-Ports auch schön das 
Clock-Signal, Daten usw mit dem Osca messen bzw. angucken...


Weiß jemand Rat?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo hängt es denn ? Beim abfragen von SPIF ?
Schau dir im Datenblatt mal den SS Pin genauer an,
bzw. lies auch ein bißchen weiter hinter den
Codebeispielen.

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anscheinend beim Setzen von SPE.
Ich denke SS hat keine Bedeutung wenn der Atmega als Master läuft?

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irosenhagen wrote:
> Ich denke SS hat keine Bedeutung wenn der Atmega als Master läuft?
Doch, hat er. Wenn der /SS-Pin als Eingang konfiguriert ist und auf Low 
gezogen wird, wird automatisch in den Slave-Modus umgeschaltet. Wenn das 
nicht passieren soll, dann muss entweder sichergestellt sein, dass der 
Pin nicht auf Low gezogen werden kann oder er muss als Ausgang 
konfiguriert sein.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich denke SS hat keine Bedeutung wenn der Atmega als Master läuft?

Das sieht das Datenblatt anders ;)

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, also kann es sein, daß ich alles richtig konfiguriert habe. Aber 
sobald ich dann mein SPI-Enable Bit setze springt der Atmega in 
Slave-Modus und deshalb kann ich logischerweise an den Ports nichts mehr 
messen.

Mist, jetzt hab ich das Zeug alles im Labor liegen gelassen, weil ich 
mich am WE etwas davon ablenken wollte. Aber man kommt ja doch nicht 
davon los....

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurzer Nachtrag:
Wenn das System im Slave-Modus ist, macht es dann gar nichts weiter als 
auf Daten zu warten?
Das würde dann ja auch erklären warum nichtmal der PortD getoggelt 
wurde...

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irosenhagen wrote:
> Kurzer Nachtrag:
> Wenn das System im Slave-Modus ist, macht es dann gar nichts weiter als
> auf Daten zu warten?
Rüchtüch. Was Anderes kann es auch nicht machen, weil der Master den 
Takt erzeugt. Beim Slave ist SCK ein Eingang und solange da nix 
passiert, kann der Slave auch nix machen.

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also am SS Pin alleine lag's nicht.
Irgendwie scheint die Konfiguration von Display und DSP (jeweils 
unterschiedliche SPI Takte) sich geblockt zu haben. Obwohl ich extra das 
SPI-Control Register nach den jeweiligen Operationen mit 0x00 
überschrieben und dann neu initialisiert hatte.

Hab jetzt die Routinen fürs Display auf Software umgebogen. Momentan 
reagiert der DSP auf die Kommandos über Hardware-SPI.
Mal schauen was passiert, wenn noch die MMC-Karte dazu kommt ;)

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, wir sind jetzt umgestiegen auf ein größeres Display in Verbindung 
mit Atmega 2561.
Nun geht wieder nichts mehr....
Jetzt haben wir mal nen Logik-Analysator angeschlossen und die 
Hardware-SPI angeguckt. Dabei sollten Befehle zum DSP geschickt werden, 
Display wurde nicht initialisiert, kriegt also auch nichts über den 
SPI-Bus.

Auf dem Analysator kann man schön sehen, daß die Timings scheinbar nicht 
stimmen. Alles was zum DSP kommt ist um 1 Bit nach links "verrutscht".
D.h. es kommt eine Clock zu früh.
Weiterhin ist uns aufgefallen, daß am Ende jeder Clock-Phase eine 
weitere, 9. Clock kommt. Die ist doppelt solang die vorangegangen 8 
Clocks.
Was hat es denn mit der auf sich?

Der gesamte Clockcycle, also alle 9 Clocks liegt bei 200kHz. Eingestellt 
haben wir Vorteiler 8 bei einer CPU von 14.75MHz, also sollten das doch 
auch ~2MHz sein, oder?

Sind gerade etwas verwirrt....

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hoppla, vergessen Namen einzutragen.
Beitrag oben ist von mir ;)

Autor: Der Grosse (jonnyk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo..

also folgendes ich benutze auch das Display3000 mit dem mega 128

Ich habe mit dem hard SPI auch Probleme gehabt.

aber ich habe den code von Ulrich Radig genommen und mit soft SPI habe 
ich es geschaft die SD - karte anzusprechen.

Wenn nachfrage bedarf besteht kann ich hier den code auch reinstellen am 
sonsten bei ulrich radig Homepage nachschauen.

was mit Hard SPI ist weiss ich leider nicht. Den Prozessor programmieren 
geht wie ne 1 aber irgend was anderes damit zu betreiben ist so ziemlich 
komliziert.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Der Grosse (jonnyk)

>was mit Hard SPI ist weiss ich leider nicht. Den Prozessor programmieren
>geht wie ne 1 aber irgend was anderes damit zu betreiben ist so ziemlich
>komliziert.

Kaum. Gerade bei SPI kann man ja nur wenig einstellen, und damit auch 
nur wenig falsch einstellen.

AVR-Tutorial: Schieberegister

MFG
Falk

Autor: Irosenhagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Komplett auf Software-SPI umsteigen wollten wir eigentlich nicht.
Wir müssen ja immerhin DSP,MMC und Display ansprechen.
Und alles bunt gemixt, also mal Daten von der MMC zum DSP bringen, 
Display aktualisieren usw.
Wobei das zeitkritischte bestimmt der Datentransport MMC<--->µC<--->DSP 
ist.

Autor: Heiko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich setze das Board mit Atmega128 ein und kann die Verwirrung mit dem 9. 
Bit verstehen. Das Display kann nicht komplett auf Hardware SPI 
umgestellt werden, da es mit 9 Bit angesteuert wird (1. Bit entscheidet 
über Command/Data). Somit kann man auch die mitgelieferten Programme 
nicht für ein anderes SPI Interface benutzen.
Eine Frage habe ich: wie habt Ihr denn die MISO Verbindung hergestellt? 
Diese ist eigentlich nicht angeschlossen!

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.