STM32 SPI mit 2 DMA Streams - geht das?

6a66 schrieb:
> Wir sehen das als sehr aufwendig und
> fehleranfällig an (neben dem Management der ChipSelect Signale).

Das ist dann wohl Eure Herausforderung.
Peripherie-DMA-Streams sind immer an die Schnittstelle gebunden.

Um Probleme zwischen zwei Bausteinen an einer Schnittstelle zu 
vermeiden, verwendet man bei RTOSen einen MUTEX oder Semaphoren zur 
Zugriffssteuerung.

STK500-Besitzer schrieb:
> Um Probleme zwischen zwei Bausteinen an einer Schnittstelle zu
> vermeiden, verwendet man bei RTOSen einen MUTEX oder Semaphoren zur
> Zugriffssteuerung.

Wir haben kein RTOS :( und werden auch keines einsetzen.
Das hilft uns da erst mal nicht weiter.

rgds

6a66 schrieb:
> Wir haben kein RTOS :( und werden auch keines einsetzen.
> Das hilft uns da erst mal nicht weiter.

Wie wollt Ihr denn auf die Schnittstelle zugreifen?
Irgendwie müsst Ihr ja erkennen, dass Euer DMA-Stream fertig übertragen 
wurde.

Es darf also maximal wechselweise einer der Bausteine beschrieben 
werden.
Wie wollt Ihr das bewerkstelligen?

Walter T. schrieb:
> Warum? Es kann doch eh nur ein Baustein gleichzeitig angesteuert werden.
> Es sei denn, man taktet direkt den SPI vom einen in den anderen. Aber
> selbst dann braucht man nur einen (zum mitlesen).

Das ist richtig. Wie müssen dann aber zwischen dem Display und dem FLASH 
Multiplexen. Mit dem Multiplexen muss dann auch der DFMA-Stream 
umgeschaltet werden. Das Display wird etwa 80x pro Sekunde (8 DMAs alle 
100ms) mit dem DMA angesteuert. Wenn dann von oben auch noch das FatFS 
auf das FLASH dazwischen scheiben oder lesen will wird das eine 
verflixte Arbitrierung der beiden DMAs.

Geht das geschickter?

rgds

STK500-Besitzer schrieb:
> Irgendwie müsst Ihr ja erkennen, dass Euer DMA-Stream fertig übertragen
> wurde.

Klar. Das erkennen wir im Falle des Displays ganz gut. Der Framebuffer 
wird in 8 Einzelteilen per DMA übertragen. So und jetzt kommt das FatFS 
dazwischen und sagt: Ich will FLASH Lesen. Gut, das stellen wir dann mal 
hinten an bis das Display fertig ist. Dann müssen wir
- Den Chipselect fürs Display abschalten
- den CS fürs FLASH einschalten
- in der SPI-Handle den DMA-Connector umbiegen
- und dann auf das FLASH zugreifen.
Wenn fertig dann wieder auf Display umschalten.

Alternative war eben: zweiten Handle für die gleiche SPI verwenden - 
geht das?

rgds

6a66 schrieb:
> Alternative war eben: zweiten Handle für die gleiche SPI verwenden -
> geht das?

Warum sollte es?
Ihr braucht eine Warteschlange oder sowas.
Greift das FatFS  von sich aus auf die Schnittstelle zu, oder habt Ihr 
da Steuermöglichkeiten?

Ich programmiere STM32 mit einem RTOS - das vereinfacht die Sache 
ungemein.

So müsst Ihr das, was ein RTOS als Threadkommunikation mitliefert, 
manuell basteln.

Zur Klarstellung:

Die Lösung
- SPI1 mit Handle initialisieren
- DMA2 Stream3 mit Handle inititalisieren
- Beide Handles miteinader verbinden
- CS ansteuern
- Loop
- 1/8 Frame übertagen per DMA
- Interrupt bekommen da DMA fertig
- Display Kommando auf nächste Teilpage setzen
- Nächsten Teilframe per DMA absetzen
- solange bis fertig
- LoopEnd
- CS disable

GEHT, funktioniert sauber und stabil. SPI1 und DMA2 arbeiten 
hervorragend zusammen.

ABER:
Jetzt kommt noch von oben das FatFS und will über die gleiche SPI über 
einen anderen DMA Stream das FLASH extern lesen.

a) Geht das - sprich hat das schon jemand mal gemacht - an der 
SPI-Handle den DMA-Connector auszutauschen (Prefer NACH der 
Display-Schleife) und dann per DMA auf einen anderen Baustein 
zuzugreifen?

b)Alternativ eine mit einer zweiten SPI-Handle zu arbeiten?

rgds

STK500-Besitzer schrieb:
> So müsst Ihr das, was ein RTOS als Threadkommunikation mitliefert,
> manuell basteln.

Die Threads auseinander zu halten ist nicht das Problem - das bekommen 
wir hin.
Das Problem ist die SPI. Die müsste ja mit zwei verschiedenen Handles 
arbeiten können: Kann die STM32-HAL das ???

rgds

6a66 schrieb:
> Kann die STM32-HAL das ???

NEIN,  geht nicht.
Warum sollte sie das auch?
Wie schon geschrieben: DMA-Kanäle gehören zur Hardware.
Wenn da mehr als ein Baustein dran hängt, müsst Ihr euch darum kümmern, 
dass es keine Kollision gibt.

Ihr müsst doch sowieso dem FatFs-DMA einen Speicher fürs Lesen und einen 
fürs Schreiben "verlinken".
Das muss sich halt abwechseln. Oder jedem seine eigene Schnittstelle 
spendieren.

Johnny B. schrieb:
> Selbstverständlich; das Handle muss ja bei allen HAL-Funktionen immer
> mitgegeben werden. Siehe entsprechende Header-Dateien (SPI, DMA, etc.).

Auch auf EINER SPI?
Das wäre dann die Lösung des Problems.

rgds

6a66 schrieb:
> Auch auf EINER SPI?
> Das wäre dann die Lösung des Problems.

Muss da kein DEInit und Init dazwischen?

rgds

Johnny B. schrieb:
> Selbstverständlich; das Handle muss ja bei allen HAL-Funktionen immer
> mitgegeben werden. Siehe entsprechende Header-Dateien (SPI, DMA, etc.).

ZWEI DMA-Streams auf eine Schnittstelle?
Dass man DMA-Streams mit unterschiedlichen RAM-Speicheradressen 
"verlinken" kann, sollte klar sein, aber für eine Schnittstelle zwei 
unabhängige DMA-Streams verwenden?