STM32F4xx UsartRx mit DMA

Servus,
du bist echt wie ein einarmiger Bandit.

Kein Affe weiß was du mit DMA willst.

mfg

Mahlzeit zusammen,

@aSma:
Danke für deine konstruktive Kritik. Es scheint so, als ob zwei "Affen" 
doch wissen, was ich mit dem DMA machen möchte.

@Jan H., @Matthias Sch.:
Die "Prophetschaltung", wie sie Matthias Sch. so schön bezeichnet hat, 
habe ich bereits implementiert und diese funktioniert auch zuverlässig.

Vllt habe ich das Problem nicht genug umschrieben:

Wenn ein Fehler auftritt wird dies von der Prophetschaltung (der Name 
sollte Markenrechtlicht lizenziert werden...) erkannt.
Zur Erklärung:
Ein Frame soll bspw aus 4 Datenbytes (x -> S.u.) bestehen. Es kann nun 
vorkommen, dass beim Senden eines Frames nicht 4 sondern nur 3 
Datenbytes ankommen (Frame 1)

Frame 1: [X X X]

Hier wird dann natürlich der DMA-Full-Callback nicht ausgelöst.
Wird nun ein zweites Datenbyt mit der korrekten Länge(4) gesendet (Frame 
2) kommt es zu einem "Überlauf" des DMAs, wodurch alle folgenden Frames 
(mit Korrekter länge) als Falsch erkannt werden

Frame 2: [Y Y Y Y]

Bsp: Beim Senden des ersten Bytes steht wird der DMA folgender maßen 
befüllt:

DMA[X X X 0]
    1 2 3 4
DMA Byte 4 bleibt also leer.

Beim Senden des ersten Bytes des 2ten Frames geschieht nun folgendes:

Frame2[Y Y Y Y->] DMA[->Y X X X] 0->
                      1 2 3 4
Byte 4 des DMA wird weitergeschoben und der Callback ausgelöst. Im 
Callback wird jetzt erkannt, dass die Daten fehlerhaft sind, da es sich 
nicht um ein Vollständiges Frame handelt.
Nach dem Callback stehen jedoch die verbleibenden 3 Bytes des 2ten 
Frames im DMA und das Spiel beginnt von vorn.
DMA[Y Y Y 0]

Ich möchte nun, wenn von der Prophetschaltun© ein Fehler erkannt wird, 
den DMA vollständig löschen bzw. zurücksetzten, damit der DMA wieder 
"Synchron" läuft.
Wie kann ich dies ohne einen neuen Init des USARTs umsetzen.

Grüße

Servus,

Nico schrieb:
> Ich möchte nun, wenn von der Prophetschaltun© ein Fehler erkannt wird,
> den DMA vollständig löschen bzw. zurücksetzten, damit der DMA wieder
> "Synchron" läuft.
> Wie kann ich dies ohne einen neuen Init des USARTs umsetzen.

Was du brauchst ist ein Protokoll. Mit header und terminator. Bei der 
Auswertung siehst du was fehlt.

Daten senden ist einfach, aber gesendete Daten zu empfangen dagegen 
nicht. Hat man einen großen Buffer (FIFO), dann muss muss man irgendwie 
feststellen, ob die Daten schon geschrieben sind. Dazu gibt es irgendwo 
eine AppNote von st mit z.B. einen Timer.

Bei einen festen Buffer hat man mit Überlauf zu kämpfen oder man muss 
einen timeout erstellen, falls zu wenig Daten angekommen sind.

1

Nico schrieb im Beitrag #4544123:

2

> g_hdma_usart3_rx.Init.Mode = DMA_CIRCULAR;

Das Problem ist hier, dass sobald der Buffer voll ist, erst dann wird 
ein Interrupt ausgefühlt. Man kann auch per Protokoll überprüfen, was 
fehlt und diese Daten anfordern.

Leider kenne deine Libraray nicht gut, da ich mit der Standart Lib 
arbeite.

Mein Vorschlag wäre:

1

g_hdma_usart3_rx.Init.Mode = DMA_Mode_Normal;

2

3

//Pseudo Code, DMA Channel muss erst ausgemacht werden, 

4

//damit neue Bufferlänge Wirkung hat!

5

DMA_UART_RX(uint8_t num2read)

6

{

7

DMA_Cmd(ChannelRx, DISABLE);

8

DMA_SetCurrDataCounter(x,x,num2read);

9

DMA_Cmd(ChannelRx, ENABLE);

10

}

Sry, aber ich denke kaum jemand nutzt die HAL? Bibliothek.

mfg

Matthias S. schrieb:
> Für mich stellt sich die Frage, ob sich für die paar Bytes der ganze DMA
> Aufwand überhaupt lohnt.

Ein klares JA, aber nur wenn man den Vorteil der DMA auch einsetz (ISR). 
Beim pollen nutze ich es auch immer, da der Code sich stark minimiert.

Matthias S. schrieb:
> Auch ein Restart der DMA im Fehlerfall birgt immer das Risiko, falsch
> auf einen Frame einzurasten oder ein Byte zu verpassen.

Bei einen konstanten Buffer ist das größte Problem ein overflow. Nehmen 
wir an beim Initialisieren des UART sendet der Tx ein paar sinnlose 
bytes. Dann werden die Daten gesendet [header]data[terminator]+paar 
bytes.

Genau diese Aufgabe gilt es jetzt zu lösen. Fährt man die gleiche 
Schiene, dann muss der overflow erkannt werden und einen restart der 
Daten anfordern.

Andere Möglichkeit wäre ein FIFO zu implementieren mit einen großzügigen 
Buffer. Oder auch wie zuvor geschrieben, einen Timer erstellen der 
guckt, fertig oder nicht mit der Übertragung?

Man kann es auch ohne DMA lösen, aber mit sehr viel Mehrcode.

Matthias S. schrieb:
> Bin auch kein HALer sondern StdLibler und kann deswegen auch nicht
> beurteilen, ob evtl. die HAL das Problem ist.

Willkommen im Club. :)

Nico schrieb:
> ich habe ein kleines Problem mit dem USART-DMA-Modus.

Das sehe ich anders: Du hast Probleme mit dem Durchsteigen durch dein 
eigenes Vorhaben, kurzum falsch angedacht.

Wozu soll bitte sehr denn ein DMA-Betrieb für sowas wie einen USART gut 
sein?
Glaubst du, damit besser oder schneller zu werden? Allein wenn ich mir 
deine Initialisierungsorgie anschaue, bezweifle ich dies.

Als nächstes frag ich mich, was du denn tun willst, wenn gerade dann, 
wenn dein DMA-Puffer voll ist und die DMA fertig ist, weitere Zeichen 
hereingerauscht kommen? Ignorieren? Ungewollt verlieren?

Nee, bei USART's macht man das anders: Zeichenempfang in einen 
Ringpuffer und Zeichenausgabe aus einem Ringpuffer. Beides natürlich per 
Interrupt, so daß die eigentlichen Programmschichten, die den gewünschen 
Algorithmus praktizieren, lediglich mit Puffern zu tun haben, aus denen 
und in die man zeichenweise den I/O-Strom fließen läßt. Dieses puffernde 
Verhalten eines guten seriellen Treibers kann man per DMA eben niemals 
nachbilden, denn dazu ist CPU-"Intelligenz" vonnöten.

Und es möge hier keiner behaupten, daß das zugehörige Interruptprogramm 
aufwendig oder umfänglich sei. Das ist Quatsch.

W.S.

W.S. schrieb:
> Dieses puffernde
> Verhalten eines guten seriellen Treibers kann man per DMA eben niemals
> nachbilden, denn dazu ist CPU-"Intelligenz" vonnöten.

Um die Intelligenz muss sich der Programmierer kümmern. Prizipiell kann 
man schon die DMA nehmen, wenn man genau weiß wieviele Bytes man 
empfängt. Eine Möglichkeit um overflow zu entgehen, könnte der 
Half-Transfer Interrupt genutz werden. Beispielsweise: Man will 20bytes 
empfangen. Den Buffer setzt man auf 40 Bytes. Mit ein wenig Phantasie 
lässt sich schon was machen.

W.S. schrieb:
> Und es möge hier keiner behaupten, daß das zugehörige Interruptprogramm
> aufwendig oder umfänglich sei. Das ist Quatsch.

Wenn man halt die Möglichkeit hat die CPU zu entlassen, warum sollte man 
es nicht auch anstreben? Es gibt viele Wege nach ROM. Man muss nur den 
richtigen aussuchen. Über das Mittelmeer, wie die Asylanten dauert 
einfach zu lange. Ich nehme das Flugzeug.

aSma>> schrieb:
> Um die Intelligenz muss sich der Programmierer kümmern. Prizipiell kann
> man schon die DMA nehmen, wenn man genau weiß wieviele Bytes man
> empfängt.

Eben genau diese Annahme ist der Knackpunkt. Sie ist nämlich IMMER 
falsch. Bei jeder seriellen Verbindung muß man damit rechnen, daß 
selbige unvollständig ist oder gestört oder sonstwas. Die Kommunikation 
findet nämlich immer mit einem anderen Ding statt, welches schlichtweg 
unabhängigig ist vom eigenen Programm.

Folglich darf man niemals damit rechnen, an irgend einer Stelle im 
eigenen Programm (oder zu einem bestimmten Zeitpunkt) genau soundso 
viele Bytes zu empfangen. auf solche Annahmen darf man sein Programm 
niemals aufbauen, sonst erleidet man Schiffbruch.

Also ist es schlichtweg sinnlos, eine DMA auf eine bestimmte Anzahl 
Bytes für einen bestimmten Puffer zu programmieren und dann quasi blind 
losrennen zu lassen. Stattdessen muß man eben die Zeichen in der o.g. 
Interrupt-Routine empfangen und in einen hinreichend großen Ringpuffer 
packen. Die Grundroutine hingegen muß allzeit prüfen, ob was angekommen 
ist, muß es abholen und parsen und in einen weiteren (nicht-Ring-)Puffer 
schreiben. Wenn das aktuelle Zeichen nicht dem entspricht, was man an 
dieser Stelle erwartet, dann muß man eben das Bieherige verwerfen und 
nach der nächsten Synchronisier-Gelegenheit Ausschau halten. Also wieder 
auf Zeichen warten, auf Synchronisier-Zeichen oder -Zeichenfolge warten 
und dann weitermachen. All dies geht immer einzelzeichenweise und 
niemals blockweise aus oben genannten Gründen.

W.S.

Matthias S. schrieb:
> Ich muss aber bei einem F4XX nicht die CPU entlasten, um 4 Bytes vom
> USART zu empfangen. Das ist sicher optimieren an der falschen Stelle,
> abgesehen von der, wie wir ja sehen, Fehleranfälligkeit.
> Eine DMA ist sicher prima, wenn ich genau weiss, wieviel und wohin es
> gehen soll. Beim Mehrkanal ADC gibt es ja sogar nur diese Option.
>
> Aber nicht für 4 Bytes über die serielle.

Ja, gut nehmen wir an, dass man super lange Leitung hat und baud von 
9600 ausgesetzt ist und kriegt 4096 bytes. Der TE hat nichts darüber 
erzählt. Er wollte nur wissen wie man den DMA counter rücksetzt.

W.S. schrieb:
> Eben genau diese Annahme ist der Knackpunkt. Sie ist nämlich IMMER
> falsch. Bei jeder seriellen Verbindung muß man damit rechnen, daß
> selbige unvollständig ist oder gestört oder sonstwas. Die Kommunikation
> findet nämlich immer mit einem anderen Ding statt, welches schlichtweg
> unabhängigig ist vom eigenen Programm.

Genau das ist die Annahme von AVR Programmierer. Man muss mal auch den 
horizont erweitern können! Bei Störung, Fehler, Verzögerung etc. kann 
man immer tätig werden. Ich verstehe schon, wenn man einmal ein Konzept 
ausgearbeitet hat, dann kann man dieses auch weiter nutzen.

Ich habe gleich mit stm32 angefangen zu programmieren, deshalb bin ich 
vielleicht mehr offen für alles. Mein Beispiel zuvor mit Halb transfer 
Interrupt war vielleicht unglücklich gewählt. Aber die Ideologie ist 
nicht verkehrt, wenn man mit ein wenig Gehirnschmalz sich ein echtes 
FIFO mit DMA basteln will.

Wobei der M3 Cortex kein echtes Fifo bestizt, vielleicht der F4? Habe 
ich schon vergessen.

W.S. schrieb:
> Also ist es schlichtweg sinnlos, eine DMA auf eine bestimmte Anzahl
> Bytes für einen bestimmten Puffer zu programmieren und dann quasi blind
> losrennen zu lassen. Stattdessen muß man eben die Zeichen in der o.g.
> Interrupt-Routine empfangen und in einen hinreichend großen Ringpuffer
> packen.

Kommt immer wieder auf den Einsatzort an!
Nehmen wir mal das Beispiel: Ich möchte eine Echtzeit von 1ms mit 5Mbaud 
erstellen. Es sollen dabei 256bytes übertragen werden. Ich würde dabei 
nie auf die Idee kommen normalen Interrupt zu nehmen, sondern ich würde 
DMA einfach pollen. Ist doch kein Problem. Ein timeout programmieren, 
falls was schiefgegangen ist und basta. Zum Beispiel als 
Kommunikationschnittstelle mit den PC. Ist mein Regler erstellt worden, 
dann kommt UART eh wieder weg.

mfg

Hallo zusammen,

danke nochmals für eure anregungen. Allerdings geht die Dikusion hier an 
der eigentlichen Frage vorbei.
Mir ging es lediglich darum zu erfahren, ob und wie ich den DMA 
zurücksetzen bzw. löschen kann. Habe dazu jetzt auch ein ansatz. Sollte 
dieser funktionieren werde ich meine Lößung posten.

Ein letzter Satz zur Sinhaftigkeit der Nutzung eines DMA zur übertragung 
einer festen Frame-länge:
Angenommen bei 100000 übertragungen treten 10 Fehler auf. In diesem Fall 
muss der µC 10x den Fehler (wie auch immer) behandeln. Bei den 
restlichen 99990 übertragungen hat der µC keine zusätzliche Arbeit und 
das Datenframe kann direkt verarbeitet werden. Lohnt sich aus meiner 
Sicht also auf jeden Fall.

Grüße

Ps.

Außerdem die alten bewährten Methoden (auf Terminierendes zeichen im 
rxIr zu warten)werden irgendwann ja langweilig ;)

Nico schrieb:
> Mir ging es lediglich darum zu erfahren, ob und wie ich den DMA
> zurücksetzen bzw. löschen kann. Habe dazu jetzt auch ein ansatz. Sollte
> dieser funktionieren werde ich meine Lößung posten.

Siehe:

aSma>> schrieb:
> Datum: 14.04.2016 14:58

Nico schrieb:
> Außerdem die alten bewährten Methoden (auf Terminierendes zeichen im
> rxIr zu warten)werden irgendwann ja langweilig ;)

Hauptsache du hast nur einen Bruchteil von der Diskussion wahrgenommen.

mfg

>Bei den
>restlichen 99990 übertragungen hat der µC keine zusätzliche Arbeit
stimmt nicht. Der Frame muss immer auf Korrektheit geprüft werden. Das 
geht norm. nicht ganz ohne CPU.
Und eine DMA muss auch nicht "ausser Tritt" kommen, wenn ein 
Übertragungsfehler (auf der Übertragunsstrecke) aufgetreten ist.
Lediglich der gesamte Frame enthält dann Fehler (was ja später 
kontrolliert wird).
Wenn man schon nach jeder einzelnen Teilübertragung eine 
Fehler-Überprüfung machen wollte, wäre die Nutzung von DMA unnötig und 
umständlich.

Nico schrieb:
> Ein letzter Satz zur Sinhaftigkeit der Nutzung eines DMA zur übertragung
> einer festen Frame-länge:
> Angenommen bei 100000 übertragungen treten 10 Fehler auf. In diesem Fall
> muss der µC 10x den Fehler (wie auch immer) behandeln. Bei den
> restlichen 99990 übertragungen hat der µC keine zusätzliche Arbeit und
> das Datenframe kann direkt verarbeitet werden. Lohnt sich aus meiner
> Sicht also auf jeden Fall.

Ich verstehe dein Argument nicht.
Also, du hast per DMA 99990 fehlerfreie Übertragungen gemacht, nun steht 
der Kram im RAM und dann? Was dann? Braucht es zur weiteren Verarbeitung 
keine CPU?

Nee, die CPU-Leistung ist immer gefordert, weil es ja keinerlei Vorteile 
bringt, die Daten erstmal vom UART in den RAM zu befördern und sich 
dabei zu denken "hach, was hab ich jetzt die CPU entlastet". 
Anschließend muß die CPU den Kram aus dem RAM holen anstatt aus dem 
Empfangsregister des UART und weiterverarbeiten - wo ist da der 
Entlastungseffekt? Ich seh da eher das Gegenteil: du mußt dich nicht nur 
um den UART kümmern, sondern obendrein noch um die DMA. Oder setzt die 
sich selbst auf?

W.S.

>Anschließend muß die CPU den Kram aus dem RAM holen anstatt aus dem
>Empfangsregister des UART und weiterverarbeiten - wo ist da der
>Entlastungseffekt?
Mit DMA kann die CPU Daten "in einem Rutsch" in den DMA-Puffer schreiben 
oder daraus lesen. Ohne DMA müsste die CPU ggfs bereits nach jedem Byte, 
Wort usw (je nach FIFO-Tiefe) tätig werden; was ein riessen Unterschied 
ist.
Allerdings ist es oft so, dass -je nach Architektur- bei aktiver DMA der 
CPU Cyclen "gestohlen" werden.

MCUA schrieb:
> Mit DMA kann die CPU Daten "in einem Rutsch" in den DMA-Puffer schreiben
> oder daraus lesen. Ohne DMA müsste die CPU ggfs bereits nach jedem Byte,
> Wort usw (je nach FIFO-Tiefe) tätig werden; was ein riessen Unterschied
> ist.

Du schreibst wirr. Entweder die CPU bewegt die Daten oder die DMA.

Aber verarbeitet werden sie immer nur per CPU.

Und nochwas: selbst bei 115000 Baud kommen die Byte mit nur so etwa 10 
kHz hereingerauscht. Das ist grottenlangsam im Vergleich zu dem, was ein 
heutiger µC so drauf hat. Das Begrenzende ist tatsächlich das 
Weiterverarbeiten und nicht der Empfang nebs Puffern.

W.S.

>Du schreibst wirr.
Wer hat denn das hier
>Anschließend muß die CPU den Kram aus dem RAM holen anstatt aus dem
>Empfangsregister des UART und weiterverarbeiten - wo ist da der
>Entlastungseffekt?
geschrieben?

>Entweder die CPU bewegt die Daten oder die DMA.
Muss nicht. Es kann sein, dass die CPU zuerst (an einem(!)) Daten zum 
DMA-Puffer schreibt, und der transferiert es dann weiter (dann ohne 
CPU).
Ausserdem düfte jedem hier klar sein, dass CPU Und DMA Daten bewegen.

Scheinbar kennst du die Vorteile (*) von DMA nicht, sonst hättest du das 
so nicht geschrieben.

(*)theoretische und praktische unterscheiden sich, wie schon erwähnt

>Das Begrenzende ist tatsächlich das
>Weiterverarbeiten und nicht der Empfang nebs Puffern.
Doch.
Bei höheren Bitraten wäre das Begrenzende definitv die CPU(-Last), weil 
die nach jedem Byte/Wort tätig werden müsste.