STM32f103 DMA Uart Rx ist zu langsam

[aSma>> (Gast)]

Servus,
habe für Matlab mit meinen 3€ China stm32f103 eine echtzeitfähiges 
Kummunikationsschnittstelle programmiert. Als Port habe ich den USART1 
mit DMA Channel 4(Tx) und Channel 5(Rx) gewählt. Dabei verzichte ich auf 
Hardwarecontrol und den CK-Eingang, also ein normales UART halt mit Rx & 
Tx.

Das Problem ist, dass es voll langsam ist. Ich spüre keinen unterschied 
mit oder ohne DMA. Ich habe das Reference Manual studiert, komme aber 
nicht weiter.

Baudrate=115200. D.h bei 20bytes müssten es 1,74ms sein. 13ms für 
weitere aufgaben. Ziel ist 20ms, da ein instabiles System zu regeln ist. 
Leider dauert die ganze geschichte 60ms.

Protokoll ist ganz schlicht gehalten. Zuerst abwarten bis die erwartete 
Menge an Daten angekommen ist, dann wird der header und terminator 
überprüft und letztendlich die Daten mit memcpy in ein array kopiert.

Nur als Info. Ich habe keine Interrupts erstellt. Ich habe irgendwo 
gelesen, dass man bei echtzeitsystem darauf möglichst verzcihten sollte. 
(Außer natürlich der Systick ist in Betrieb).

Nach der Initialisierung wird immer das ausgeführt:

//Enable RX DMA
DMA_Cmd(DMA1_Channel5, DISABLE);
DMA1_Channel5->CNDTR = 20;
DMA_Cmd(DMA1_Channel5, ENABLE);
while(DMA_GetCurrDataCounter(DMA1_Channel5)!=0){};//wait until data 
reached

Hat jm eine Idee?

Ach ja, habe ein ein fake FTDI. Habe neulich leider ein Update 
installiert. Dann kamm in HTerm: "NO DEVICE FOUND...". Voll der Upfuck. 
Hat über 2std gedauert bis ich es gecheckt habe.
Danke.

mfg

[Horst (Gast)]

aSma>> schrieb:
> Leider dauert die ganze geschichte 60ms.

Was genau dauert 60ms? Wie misst du die?

Wenn ich was raten darf, was Schuld ist, dann Matlab. Fast immer wenn 
etwas langsam ist, liegt es an Matlab...

[R42 (Gast)]

R42 ist zu klein.

[Sven S. (boldie)]

Für dein Vorhaben ist aller Wahrscheinlichkeit nach der FTDI bzw. USB 
schuld an deiner Misere. Jedes Byte was der FTDI empfängt wird nicht 
direkt an den Host gesendet, sondern in einem Puffer zwischengespeichert 
und erst dann abgesendet, wenn der Puffer voll ist oder ein Timeout 
vorbei ist. Man kann das irgendwie auch setzen, da müsste etwas in der 
einer der Librarybeschreibungen stehen (DXX oder so was). USB basiert 
auf Polling vom Host und auf Paketübertragung und ist damit auf 
Durchsatz und nicht die Latenzzeit optimiert.

Wenn du USB nutzen möchtest, musst du das direkt im Controller 
Implementieren und einen Kernel-Treiber schreiben und den 
Interrupt-Transfer nutzen. Dann bekommst du diese Zeit je nach Device 
runter, aber auch hier gibt es je nach Full-speed oder High-Speed noch 
Verzögerungen durch das Pollen am USB.

Letztendlich würde ich dir raten, über das Systemdesign Gedanken zu 
machen, denn du wirst noch mehr Probleme bekommen mit Aussetzern, da 
weder Matlab noch das Betriebssystem echtzeitfähig ist.

[aSma>> (Gast)]

Horst schrieb:
> Was genau dauert 60ms? Wie misst du die?

Die Sample time (Abtastzeit) dauert 60ms. Dadurch dass Uart in 
BlockingMode ist, wird die gewünschte Abtastzeit nicht erreicht 
(überschritten).
Habe auch ein Osziloskob und ich habe gemerkt, dass es bei:

while(DMA_GetCurrDataCounter(DMA1_Channel5)!=0){};

sehr lange braucht bis es erkennt, dass der Buffer voll ist.


> R42 ist zu klein.
Ok. Geht das ein wenig ausführlicher. Ich arbeite leider momentan mit 
der stdlib. Da lernt man nicht so viel über die Architektur.

[aSma>> (Gast)]

Sven S. schrieb:
> Letztendlich würde ich dir raten, über das Systemdesign Gedanken zu
> machen, denn du wirst noch mehr Probleme bekommen mit Aussetzern, da
> weder Matlab noch das Betriebssystem echtzeitfähig ist.

Ich brauche Matlab nur für einen Regler-Entwurf. Die 20ms sind nicht 
unmöglich.

[aSma>> (Gast)]

Servus,
habe beim ftdi Chip Hersteller etwas geforscht. Nun, ja man könnte 
nochmals die Geschwindigkeit des Chips erhöhen indem man mit MPROG den 
Chip auf "optoisolated" in den EEPROM programmiert. Dabei müssen halt 1k 
pullup dazu.

Aber bei 115200 baud. Liegt es 100%ig am stm32f1.

[aSma>> (Gast)]

Mprog. Für Interessenten.

[avion23 (Gast)]

Nur um das klar zu stellen: USB-seriell-Adapter haben hohe Latenzzeiten. 
120ms sind nicht ungewöhnlich.

Falls du die Kommunikation über USB abwickelst solltest du dich über die 
60ms freuen.

[Torsten C. (torsten_c)]

aSma>> schrieb:
> Aber bei 115200 baud. Liegt es 100%ig am stm32f1.

Schicke mal 'ne große Datemenge rüber. Du wirst sehen, dass selbst 
500kBaud und mehr ankommen. Ich hatte das vor ein paar Monaten mal 
ausprobiert, mit unterschiedlichen USB-VCOM-Adaptern.

Über das Problem mit der Latenzzeit sind auch vor Dir schon viele 
gestolpert: Es ist ärgerlich, ist aber so.

Die USB-VCOM-Adapter warten, bis der Puffer voll genug ist oder ein 
Timeout abläuft. Viele kleine Datenpakete sind also deutlich langsamer.

Da ich das gleiche Problem und noch keine gute Lösung habe, lese ich 
hier mal weiter mit. ;-)

[3 DMA Ua (Gast)]

>Die USB-VCOM-Adapter warten, bis der Puffer voll genug ist oder ein
>Timeout abläuft. Viele kleine Datenpakete sind also deutlich langsamer.

Dann soll er halt Dummy-Daten schicken, wenn der TO sonst nicht in den 
Griff zu kriegen ist...

[Carl D. (jcw2)]

Die USB-Adapter haben keine andere Wahl als zu warten, denn erst wenn 
der Host das nächste Mal polled, können sie was senden. Auch wenn man 
"Interrupt-EndPoints" verwendet, läuft das so.
500kBd bedeutet eben nicht, daß das erste Bit nach 2μs ankommt, sondern 
daß 500000Bits jede Sekunde ankommen. Auf dem Kabel waren die aber 
vielleicht sogar mit 480MBit unterwegs. Aber nur zwischen den Pausen.
Wie lange der STM32 braucht, kann man nur an dessen PortPins ermitteln. 
Also Oskar/LA dran klemmen!

[Torsten C. (torsten_c)]

aSma>> schrieb:
> Ach ja, habe ein ein fake FTDI.

FTDI und STM32F103 treffen sich bei der höchsten Baud-Rate von 1.5MBps.

Der STM32F103 kann zwar 2.25MBps und 4.50MBps, aber der FTDI nur 
2.00MBps und 3.00MBps.

Bei 1.5MBps und - wie "3 DMA Ua" bereits vorschlug - Dummy-Daten kommst 
Du netto wahrscheinlich auf die gewünschten 115200.

[aSma>> (Gast)]

Servus,
aufgrund einer Vogelgrippe, war ich einfach lahmgelegt. Beim Problem bin 
ich nicht so recht weiter gekommen. Es gibt ja nur zwei Möglichkeiten: 
Ftdi oder Matlab. (Habe eine ori ftdi2232H jetzt aus der Schublade 
geholt).

1. senden von 62 bytes bei 1.5Mbaud. nichts gebracht. Problem liegt am 
Host!
2. Hardwareflowcontrol. Merde. Der Cts pin beim stm32 wollte nie low 
werden. Habe den einfach auf Masse gelegt. Nur ein Vorteil hat sich 
ergeben: Matlab ist stabiler gelaufen. Keine einziger Absturz.
3. habe nicht ausprobiert.
4. auf 1ms gestellt.

Ergebnis: Latenz von 40ms!

===> Es muss an Matlab liegen. Habe mir die:
-sserialsb, sserialrb, sserialcb angeguckt. Naja, that se fuck is this: 
java. Affen. Es füllt sich an wie ein gedrosselter Esel. Die wollen 
einfach Kohle machen und einen ne verdammte Bibliothek mit Hardware 
verkaufen.

Meine Regelstecke ist nicht annährend so instabil, wie das Programm!!! 
:D


Ich habe eine echte Rs232 SS am Laptop. Jetzt muss ich 1 mon warten bis 
aus China der MAX232 kommt :(. Dann werden wir sehen was die Bremse ist.

Naja, der Regler ist denoch einiger maßen zufriedenstellend erstellt 
worden. Ich mach dann vllt noch ein vid.

mfg


Anlagen:
http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf

[Torsten C. (torsten_c)]

Du sagst, es liegt an Matlab.

aSma>> schrieb:
> Ich habe eine echte Rs232 SS am Laptop.

Ist es denn aus Matlab-Sicht ein Unterschied, ob da eine "USB VCOM" oder 
eine "echte Rs232" im Hintergrund werkelt?