STM32 SPI mehr als 16 Bit übertragen

[Stm32 M. (benson32)]

Hallo liebe Stm32-Gemeinde,

ich versuche gerade ein 20 bit Protokoll per SPI auf meinem 
Mikrocontroller zu empfangen. Da die Empfängervariable nur 8 bit hat 
komme ich irgendwo durcheinander und bekomme keinen kontinuierlichen 
Empfangsablauf hin.

Hier meine Hardware
Sender ist eine Atmel DSP als Master
Empfänger Stm32100RB SPI als Receive Only slave

Software: Keil V5

Folgende Leitungen kommen aus der DSP
Datenleitung: 20 bit Strings
Sync-Leitung: geht 10µs auf low kurz auf high dann wieder low für 10µs
Clock: 2MHz

Konfiguration Stm32
Receive only Slave
8 bit mode
circulare datenübertragung (Mir fällt gerade auf das könnte das Problem 
sein, kann ich aber gerade nicht testen)
Datenrate: 2MBaud
ClkPhase und Polarität hab ich mal herumprobiert hat aber nicht geholfen

Ablauf
Ich habe eine DSP auf die ich keinen Zugriff habe und auch wenig drüber 
weiß.
Diese DSP sendet 20 bit Strings. Momentan sendet sie immer 0011 0001 
0001 1000 0011. Das kann ich auf dem Oszi sehen.

Ich stelle mir das jetzt so vor, die SPI empfängt 8 bit, schreibt sie in 
den Buffer welcher 3 Byte groß ist da ich ja 20 bit habe, dann die 
nächsten 8 bit wieder in den Buffer, und die letzten 4 bit ebenfalls. 
Der Buffer sollte mir ja dann konstant die gleichen Werte ohne Variation 
zeigen. HAL_GPIO_SPI(*hspix, uint8_t *pdata, uint16_t size, uint32_t 
timeout) ist der Befehl zu Empfang. Das ist Blocking_mode.

Auszug aus meinem Code:
uint8_t receive_data[3]={0}
size= 3 // Wegen 3 Byte oder?

HAL_GPIO_SPI(*hspi1, receive_data ,3 , 10000);

Problem
wenn ich mein Programm jetzt laufen lasse sehe ich das in den 3 
receive_data Feldern die richtigen Werte ankommen aber- und das ist das 
Problem- der Anfang des String steht mal in receive_data[0], dann in 
...[2], dann in ..[1] usw. mein String wird also völlig willkürlich auf 
die 3 Array Felder aufgeteilt. Das ist so nicht gewollt oder? Ich hätte 
gerne
receive[0]=ersten_8_bit;
receive[1]=zweiten_8_bit;
receive[2]=letzten_4_bit;.

Für jede  Hilfe bin ich Dankbar!
Beste Grüße
Torsten

[Vincent H. (vinci)]

Musst du jeden String einzeln auswerten?
Sonst empfang doch einfach 2x Strings a 40Bit in 5Byte.

Ist das nicht möglich, empfehle ich dringends eine Realisierung in 
Software. Bei 2MHz ist das ja kein Problem.

[Joe F. (easylife)]

Stm32 M. schrieb:
> Sender ist eine Atmel DSP als Master

Kannst du die 20 Bit beim Senden nicht einfach auf 24 Bit = 3 Bytes 
"aufblasen" (mit führenden Nullen padden)?

[Horst V. (hoschti)]

Ohne den HAL (bzw. die Funktionen zum Arbeiten mit der SPI) genau zu 
kennen, vermute ich, dass sich das Interface nur mit "vollständig" 
empfangenen Bytes meldet.

Spontan fäält mir nur folgendes als Lösungsansatz ein:
Mit einem zusätzlichen Pin die Clockimpulse von SPI-Master mitzählen und 
daraus den Offest des Telegaramms bestimmen. Den Empfanghspuffer dazu 
deutlich größer als die 3 benötigten Byte machen (z.B. wie "Vincent 
Hamp" geschrieben hat). Und imer, wenn die 20 Bit eingesackt worden 
sind, die Nutzdaten aus dem Puffer entsprechend umkopieren.

Hoschti

[Vincent H. (vinci)]

Horst V. schrieb:
> Ohne den HAL (bzw. die Funktionen zum Arbeiten mit der SPI) genau zu
> kennen, vermute ich, dass sich das Interface nur mit "vollständig"
> empfangenen Bytes meldet.

Das Interface kann sich gar nicht anders melden. Das interne 
Schieberegister ist eben nunmal auf vielfache von 8 Bit ausgelegt.

20 Bit als Einzel-Event zu empfangen ist somit ohne zusätzlichen Aufwand 
ohnehin schonmal unmöglich.

[TriHexagon (Gast)]

Welchen STM32 µC hast du denn? Beim SPI vom STM32F303 ist die Datengröße 
auch auf 10-Bit konfigurierbar. Keine Ahnung wie genau sich das verhält, 
habe bisher nur 8- und 16-Bit benutzt, aber vielleicht ist das was für 
dich.

[Vincent H. (vinci)]

TriHexagon schrieb:
> Welchen STM32 µC hast du denn? Beim SPI vom STM32F303 ist die Datengröße
> auch auf 10-Bit konfigurierbar. Keine Ahnung wie genau sich das verhält,
> habe bisher nur 8- und 16-Bit benutzt, aber vielleicht ist das was für
> dich.


Tatsächlich. Da hab ich doch glatt Blödsinn erzählt.
Viele STM32 haben im SPI Register CR2 eine einstellbare Datenlänge von 
4-16Bit...

Das löst natürlich das Problem!