STM8 SPI MOSI geht nicht auf High nach Transmission

OP #4578479
Lesenswert?

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:
1
  GPIOC->DDR = (1<<MOSI) | (1<<SCK) | (0<<MISO); //MOSI & SCK output, MISO input
2
  GPIOC->CR1 = (1<<MOSI) | (1<<SCK); //MOSI& SCK push-pull
3
  
4
  GPIOA->DDR |= (1<<CS); //set CS as output
5
  GPIOA->CR1 |= (1<<CS); //set CS as push-pull
6
  GPIOA->ODR |= (1<<CS); //turn CS high
7
  
8
  SPI_DeInit();
9
  SPI_Init(
10
    SPI_FIRSTBIT_MSB,
11
    SPI_BAUDRATEPRESCALER_256,
12
    SPI_MODE_MASTER,
13
    SPI_CLOCKPOLARITY_HIGH,
14
    SPI_CLOCKPHASE_2EDGE,
15
    SPI_DATADIRECTION_2LINES_FULLDUPLEX,
16
    SPI_NSS_HARD,
17
    0x07);
18
  SPI_Cmd(ENABLE);
1
void SPITransmit(uint8_t data){
2
  while(SPI_GetFlagStatus(SPI_FLAG_TXE) == RESET){
3
    nop(); //wait until TX-Buffer is free
4
  }
5
  SPI_SendData(data);
6
  while(SPI_GetFlagStatus(SPI_FLAG_BSY) == SET){
7
    nop(); //wait until not busy
8
  }
9
}

Wie man im Anhang sieht, bleibt MOSI zwischen beiden Datenpaketen auf 
Low, wie kann ich das ändern?
Angehängte Dateien:
OP #4578516
Lesenswert?

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?
Angehängte Dateien:
OP #4578569
Lesenswert?

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.
Angehängte Dateien:
OP #4578946
Lesenswert?

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.
Angehängte Dateien:
#4579100
Lesenswert?

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
OP #4579115
Lesenswert?

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
OP #4579181
Lesenswert?

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?
Angehängte Dateien:

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren