STM8 SPI MOSI geht nicht auf High nach Transmission

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.

Was geht denn nicht? Antwortet der Sensor gar nicht?

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

Hi Daniel,

Daniel R. schrieb:
> Das Problem ist, dass der Sensor bei einem High-Pegel im I²C Modus
> (Slave) ist.

Stimmt:

1

This OR gate will hold the SDA line high when CS is high to prevent SPI bus traffic at the ADXL345 from appearing as an I2C start command.

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.

Ich habe die Stellen markiert...
Dies wird in deiner Software-SPI Version nicht der Fall sein, schätze 
ich?!

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?