Hallo, ich arbeite gerade mit dem Evalboard STM32 Nucleo-F401RE, an dem 15 Sensoren angeschlossen sind. Die ankommenden Daten ergeben eine Baudrate von über 1,6 MBaud. Das Evalboard hat eine ST-LINK MCU STM32F103CBT6, die an PA2 und PA3 des F401 angeschlossen ist. Der COM-Port ist mit 1,9 MBaud initialisiert. Das Problem: Der Datenstrom hat alle 10 Minuten bis halbe Stunde Aussetzer, es fehlen mehrere Bytes bis hin zu 100 Bytes an einem Stück. Mit dem Oszi belauscht sieht man, dass der F401RE die Daten sendet, sie werden vom ST-LINK nur nicht verarbeitet bzw. an den PC weitergesendet. Hat das jemand schon mal beobachtet?
Klingt für mich nach einem typischen Pufferüberlauf. Irgendwann beschließt das OS auf dem PC mal eine mehr oder weniger lange meditative Pause einzulegen, um z.B. Dinge neu zu organisieren. Dann läuft zuerst der RX-FIFO am PC voll und dann auch ziemlich schnell der TX-FIFO des ST-Link. Währenddessen kommen von hinten weiter Daten nach und der ST-Link weiß nicht wohin damit. Um was für ein Betriebssystem handelt es sich denn PC-seitig?
Gast
#5083938
Tycho B. schrieb: > sie werden vom > ST-LINK nur nicht verarbeitet bzw. an den PC weitergesendet. Das kann doch nur sein, weil es ein Handshake vom PC gibt? Grundsätzlich wirst du ein Problem nicht lösen können: egal ob Windows oder Linux, beides sind keine Realtime-Systeme mit garantierter Antwortzeit. Da helfen nur ausreichend grosse Bufferspeicher. Die müssten dann wohl im ST-LINK beheimatet sein. Georg
Georg schrieb: > Tycho B. schrieb: >> sie werden vom >> ST-LINK nur nicht verarbeitet bzw. an den PC weitergesendet. > > Das kann doch nur sein, weil es ein Handshake vom PC gibt? > > Grundsätzlich wirst du ein Problem nicht lösen können: egal ob Windows > oder Linux, beides sind keine Realtime-Systeme mit garantierter > Antwortzeit. Da helfen nur ausreichend grosse Bufferspeicher. Die > müssten dann wohl im ST-LINK beheimatet sein. > > Georg Oder ein anderes Bussystem, dass für solche hohen Übertragungsraten ausgelegt ist. Alles über 1MB ist IMO nicht für UART geeignet. mfg
Georg schrieb: >> ST-LINK nur nicht verarbeitet bzw. an den PC weitergesendet. > > Das kann doch nur sein, weil es ein Handshake vom PC gibt? ST-Link ist USB. Da ist der Handshake implizit, d.h. der PC stellt einfach das Einholen der Daten auf dem USB Endpoint ein wenn der USB Host Puffer voll ist. Was dann auch eine mögliche Lösung darstellt: Eingenes USB Handling via LibUSB-(win32). Mit dessen Async Funktionen kann man dem LibUSB gleich mehrere Lesepuffer hintereinander übergeben - was das Problem des Puffer Überlaufs auf dem µC deutlich entschärfen kann. Denn es reicht damit das der LibUSB Treiber im Kernel noch ein paar CPU Zyklen mit abbekommt. Der µC im F104RE wird mit USB OTG Feature beworben, eventuell ist es besser wenn der selbst mit dem PC über USB redet.
Felix F. schrieb: > Oder ein anderes Bussystem, dass für solche hohen Übertragungsraten > ausgelegt ist. Alles über 1MB ist IMO nicht für UART geeignet. Man will da auf jenden Fall Hardware Handshake und FIFO mit =>8Byte Speicher haben, dann geht das sehr oft problemlos. Auf dem Nucleo wird es vermutlich keinen HW-Handshake geben.
Christopher J. schrieb: > und dann auch ziemlich schnell der TX-FIFO des > ST-Link RTS und CTS werden nicht benutzt, also kann ST-Link nicht wissen, dass der PC überläuft, er muss einfach weitersenden. Auf der PC-Seite habe ich einen win7 mit labview 2015 64bit und einen core i5 mit 2,6GHz, 16GB Arbeitsspeicher. In Labview ist der Puffer 65k und läuft nicht über.
Tycho B. schrieb: > RTS und CTS werden nicht benutzt, also kann ST-Link nicht wissen, dass > der PC überläuft ne, das war Blödsinn, es ist ja USB. In LabVIEW gibt es aber die Möglichkeit die Anzahl der Zeichen im Puffer ausgeben zu können, da sehe ich, dass er nicht überläuft. Kann natürlich sein, dass es auf der Systemebene passiert, und LabVIEW da nichts sieht. USB ist doch für deutlich höhere Übertragungsraten ausgelegt, macht sich da der FTDI chip besser? Wird ja explizit mit 3 MBaud beworben.
Mit dem neuen Treiber stsw-link009, DriverVer=06/08/2017,2.01 hat sich das Problem anscheinend erledigt. Davor hatte ich DriverVer=01/21/2013,1.01.