Exti und NSS auf den selben Pin

[Felix C. (felix_c13)]

Hallo allerseits,

Ich habe eine SPI-Applikation, bei welcher mein STM32F103RB als Slave 
agiert. Dabei wird der DMA für RX und TX verwendet. Zu 
Synchronisationszwecken wird auf die fallende Flanke des Slave Selects 
ein externer Interrupt getriggert. In dem Interrupt-Handler werden dann 
die NDT-Register der beiden DMA-Channel überprüft. Ausserdem ist der 
Slave Select NICHT im "Softwaremodus".

Soweit so gut. Es funktioniert eigentlich tadellos. Ich bin jetzt 
gezwungen die Applikation mit dem CubeMX von ST nochmals neu 
aufzusetzen. Wenn ich dort auf den PB12 (den Slave-Select-Pin von SPI2) 
einen EXTI setze, ist "Hardware NSS Signal" rot eingefärbt und das steht 
fix auf Disable.

Ich war mir jetzt unsicher ob mein vorheriges Programm auch wirklich 
läuft wie es soll, und es tut es. Ich laufe bei jeder Kommunikation in 
den EXTI-Handler und der Slave Select ist auch im Hardware-Modus.

Hat jemand eine Ahnung was das soll? Oder ist der Cube einfach verbuggt, 
oder versucht mich vor etwas dummem zu beschützen?

Gruss

Felix

[Felix C. (felix_c13)]

Niemand ein Idee? ;)

[dasrotemopped (Gast)]

>oder versucht mich vor etwas dummem zu beschützen?
du kommst der Lösung schon recht nahe.

Wie soll die Doppelbelegung vom Pin funktionieren ?
ein IRQ auslösen jedes mal, wenn ein SPI Datentransfer ansteht ?
Oder der CS wird von einem externen Event durcheinandergebracht
und der SPI Datentransfer gestört ?

Gruß,

dasrotemopped.

PS: mehr Info über das gewünschte Ergebnis hilft

[Felix C. (felix_c13)]

dasrotemopped schrieb:
> Wie soll die Doppelbelegung vom Pin funktionieren ?
> ein IRQ auslösen jedes mal, wenn ein SPI Datentransfer ansteht ?

Genau!

Ziel der SPI-Kommunikation ist der Datenaustausch zwischen zwei 
uControllern.  Dabei wird von beiden jedes mal die gleiche Datenstruktur 
übertragen. Diese ist insgesamt 16 Bytes gross.

Der Master versucht alle 150ms diesen Datenaustausch stattfinden zu 
lassen.

Nun ist es aber wichtig, dass wenn die Verbindung in mitten eines 
Austauschs getrennt wird, bei Beginn des nächstens die NDT-Register der 
DMA-Channel wieder richtig stehen. Andernfalls wäre ja alle Bytes in den 
Datenstrukturen verschoben.
(Es gäbe hier sicher noch bessere Wege, so eine Kommunikation zu 
realisieren, jedoch steht es nicht in meinem Handlugsspielraum dies zu 
ändern).

Wird nun auf den Slave Select ein Interrupt getriggert, (Mir ist 
bewusst, dass man bei einer Punkt-zu-Punkt-Verbindung auch den 
Software-Slave-Select auswählen könnte, darum gehts aber nicht.) kann in 
dessen Handler überprüft werden, ob die NDT-Register "richtig" gestellt 
sind. Ausserdem weiss der Slave dann, dass er angesprochen ist.

Wie bereits geschrieben hat dies bereits funktioniert, allerdings nicht 
mit dem Cube.

Gruss,

Felix

Edit:

dasrotemopped schrieb:
>>oder versucht mich vor etwas dummem zu beschützen?
> du kommst der Lösung schon recht nahe.

Wieso ist dies in seinen Augen dumm? Also rein aus technischer Sicht, 
nicht die Sinnfrage, oder will der Cube mir Philosophien aufzwingen ;)

[dasrotemopped (Gast)]

jede Hardwarekomponente im uC hat einen eigenen IRQ, auch SPI.
Damit können Events wie ankommende Daten, Senden beendet ect. erfasst 
werden. Einen GPIO-IRQ dazu zu verbiegen ist nicht nötig. Diese Optionen 
kann man im CubeMX auch konfigurieren, der entsprechenden IRQ Handler 
wird dann dem Projekt hinzugefügt.
Non-blocking HAL Routinen sind da mal ein Tipp von mir.

Gruß,

dasrotemopped.

[Felix C. (felix_c13)]

dasrotemopped schrieb:
> jede Hardwarekomponente im uC hat einen eigenen IRQ, auch SPI.

Beim STM32F1xx sind sogar gleich 5 IRQ's für SPI verfügbar:

Receive Buffer Not Empty
Transmit Buffer Empty
Master Mode Error
Overrun Error
CRC Error

Ich seh da eigentlich keine andere Möglichkeit, als einen EXTI wie du es 
nennst "umzubiegen". ;)