Hallo,
ich versuche aktuell, das SPI Peripherie Modul zu konfigurieren. Dabei
bin ich jetzt auf etwas gestoßen, was nicht passt. Und zwar geht der
MOSI pin nach einer Datenübertragung von 8-bit nicht auf High sondern
bleibt bei dem zuletzt gesendeten Bit, das geht leider nicht in Ordnung
da der Sensor den ich ansteuern möchte, immer ein MOSI von High auf Low
beim Übertragen braucht.
Meine SPI Konfiguration:
>sondern bleibt bei dem zuletzt gesendeten Bit
Das ist normal bei SPI.
>wie kann ich das ändern?
Mach Software SPI. Also schön selber zu Fuß an den Pins wackeln.
Hi und danke für deine Antwort,
holger schrieb:> Mach Software SPI. Also schön selber zu Fuß an den Pins wackeln.
Das hab ich schon gemacht (wie man in diversen Beiträgen von mir zum
selben Thema erfährt). Bin seit 3 Wochen am rumprobieren und schaffs
einfach nicht mit diesem Sensor zu kommunizieren.
holger schrieb:> Das ist normal bei SPI.
Und wie verfährt man dann, wenn man kein Software SPI machen will und
der Sensor aber diese Art der Konfiguration benötigt? Kann ja nicht
sein, dass darauf keine Rücksicht genommen wurde bzw. dass der ADXL345
der einzige Sensor ist, der den MOSI Pin von High auf Low haben will?
Ohne uns Datenblatt geschaut zu haben...
Wieso meinst du denn, dass du eine fallende Flanke brauchst? Die
resultiert in deinem Bild nur durch die erste "0" für den write comand.
PS: Habe gerade mal ins Datenblatt geschaut... Ist das der einzige
Sklave an dem spi Bus?
Daniel R. schrieb:> Ist das der einzige> Sklave an dem spi Bus?
Jup
Daniel R. schrieb:> Die> resultiert in deinem Bild nur durch die erste "0" für den write comand.
Hm, stimmt. Im Datenblatt steht nur wie CS und SCLK auszusehen haben.
Bei der Software - SPI Methode kamen komische Werte zurück. Bei der
selbstgeschriebenen Hardware-SPI Methode haben sich die
Beschleunigungswerte nicht geändert und jetzt bekomme ich gar nichts
zurück (mit der STM Peripheral Library).
Hast du deine gesendeten bits mit dem la mit denen im Datenblatt
verglichen? Vor allem auch die Timings, bzw. die Zeitpunkte wenn gelesen
und geschrieben wird?
Daniel R. schrieb:> Vor allem auch die Timings, bzw. die Zeitpunkte wenn gelesen> und geschrieben wird?
Im Anhang siehst du die Initialisierung (4byte) des ADXL345 mit meiner
Software-SPI Methode. Müsste eigentlich passen. Auslesen der DeviceID
klappt mit der Software-Methode und die Werte ändern sich bei
entsprechender Bewegung des Sensors auch.
Dann kannst du doch jetzt die beiden Varianten vergleichen. Da sollte
ja dann ein Unterschied zu sehen sein.
Wartest du nach dem einschalten ein wenig?
Poste mal deinen ganzen Code.
Daniel R. schrieb:> Dann kannst du doch jetzt die beiden Varianten vergleichen. Da sollte> ja dann ein Unterschied zu sehen sein.
Sieht bis auf MOSI gleich aus. Beides zeigt das Initialisieren des
ADXL345 mit folgenden Bytes:
1. 16-range und full-resolution:
1
0x31//register
2
0x0B//Wert
2. Enable Measurement
1
0x2D//register
2
0x08//Wert
Daniel R. schrieb:> Wartest du nach dem einschalten ein wenig?
Ich hab nen delay drinnen.
Daniel R. schrieb:> Poste mal deinen ganzen Code.
Okay, Software-SPI und Hardware-SPI ist angehängt.
Hey Max,
ich habe jetzt gerade noch einmal ins DB des Sensors geschaut.
Du hast Recht, dass der Sensor im inaktiven Zustand ein High am Miso
haben möchte.
Das ist da sogar recht gut beschrieben und sogar eine Lösung wird
gezeigt.
Das Problem ist, dass der Sensor bei einem High-Pegel im I²C Modus
(Slave) ist. Das Problem kannst du mit einem Oder-Baustein wie auf Seite
15 im Kapitel "Preventing Bus Traffic Errors".
Schönes Wochende,
Daniel
Ich verstehe aber nicht, wie so ein bus traffic auftreten kann, wenn
der ADXL345 das einzige Gerät ist, mit dem ich kommuniziere?
Noch etwas:
Der Fehler in meinem Hardware-SPI Programm war wohl, dass ich die
SPI-Verbindung zuerst eingeschalten habe, bevor überhaupt Sachen die
CPOL oder ähnliches gesetzt wurde.
Jetzt klappt es zumindest, dass ich die DEVID auslesen kann, der
zurückgegebenen Wert 229 stimmt auch mit der Angabe im Datenblatt
überein. Allerdings taucht nun wieder der gleiche Fehler auf, wie bei
meinem 1. Hardware-SPI Versuch ohne die STM-Lib: Alle Achsen (x,y,z)
haben den gleichen Wert (bzw. zumindest liest mein Programm diesen Wert
aus) im 16g full-res Modus: 2313.
Kann das an dem von dir beschriebenen Problem mit dem High-Pegel liegen?
Aber warum funktioniert dann das Auslesen der DEVID?
Grüße
Mosi darf nicht Low sein wenn CS auf High ist. Sonst interpretiert er es
vielleich als I²C Kommando. So verstehe ich das zumindest.
Ist das bei deinem Auslesen irgendwann der Fall, dass Mosi auf Low
steht?
Gruß
Daniel R. schrieb:> Ist das bei deinem Auslesen irgendwann der Fall, dass Mosi auf Low> steht?
Hm, sieht irgendwie nicht so aus. Anbei mal die Kommandos zum Auslesen
der 6 Register.
Daniel R. schrieb:> Dies wird in deiner Software-SPI Version nicht der Fall sein, schätze> ich?!
Nein, denn da setze ich MOSI nach jedem Durchgang wieder auf High. Die
MOSI Pegel sehen jetzt etwas seltsam aus, da ich 3-wire Software SPI
benutze.
Dein Clock sieht aber sehr seltsam aus...
Benutze also entweder eine saubere Software-SPI (ist ja auch schnell
selbst implementiert...) oder baue die Veroderung aus dem DB nach...
Gruß,
Daniel
Hm, ich hatte da noch ein delay drinnen, sieht das so besser aus? Danke
für deine Mühe.
Daniel R. schrieb:> Benutze also entweder eine saubere Software-SPI (ist ja auch schnell> selbst implementiert...)
Ich dachte eigentlich, dass ich das richtig gemacht hätte. Auslesen der
DEVID funktioniert und die ausgelesenen Beschleunigungswerte ändern sich
auch. Magst du vielleicht mal drüberschauen?