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?
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.
Anscheinend beim Setzen von SPE. Ich denke SS hat keine Bedeutung wenn der Atmega als Master läuft?
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.
>Ich denke SS hat keine Bedeutung wenn der Atmega als Master läuft?
Das sieht das Datenblatt anders ;)
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....
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...
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.
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 ;)
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....
Hoppla, vergessen Namen einzutragen. Beitrag oben ist von mir ;)
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.
@ 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
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.
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!
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.