Hallo alle zusammen. Ich habe folgende Schaltung: PC <--> USB <--> FT232RL <--> UART <--> µC(STM32) Diese Schaltung funktioniert auch. Jetzt ist allerdings ein neuer Anwendungsfall hinzugekommen bei diesem viele Daten (einige kByte) vom µC zum PC versendet werden müssen. Hier habe ich jetzt das Problem das in unregelmäßigen Abständen Daten verloren gehen. Im Datenblatt des FT232 ist mir anschließend aufgefallen, dass dieser nur einen Sendepuffer von 256Byte hat. Wahrscheinlich kommt dieser mit dem Senden einfach nicht mehr hinterher. Ich habe nun jetzt die Leitungen CTS und RTS überkreuzt mit meinem µC verbunden. Das Phänomen scheint reduziert zu sein, dennoch habe ich weiterhin Datenverluste. Eine Messung mit dem Oszilloskop auf der "FT232 RTS / µC CTS" Leitung zeigt dass dieser High bei geschlossenem Com-Port und Low bei offenem Com-Port ist. Während dem Senden ändert sich der Pegel allerdings nicht. Müsste sich bei einem Pufferüberlauf nicht der Pegel ändern und müsste der Pegel nicht invertiert sein? Wie funktioniert das mit den CTS/RTS Leitungen überhaupt? Wird das Senden gestoppt, wenn der FT232 keine Daten mehr annehmen kann, oder wird das Senden gestoppt, wenn der PC keine Daten mehr annehmen kann? Auf der "FT232 CTS / µC RTS" Leitung messe ich circa 20 Peaks während der µC sendet. Dies macht für mich auch keinen Sinn. Diese Leitung ist doch nur dafür da um um dem FT232 bzw. dem PC zu sagen, dass der µC Daten empfangen kann.?
FTDI schreibt hier: There are 4 methods of flow control that can be programmed for the FT232BM device. 1. None - this may result in data loss at high speeds 2. RTS/CTS - 2 wire handshake. The device will transmit if CTS is active and will drop RTS if it cannot receive any more. 3. DTR/DSR - 2 wire handshake. The device will transmit if DSR is active and will drop DTR if it cannot receive any more. 4. XON/XOFF - flow control is done by sending or receiving special characters. One is XOn (transmit on) the other is XOff (transmit off). They are individually programmable to any value aber irgendwie passt das nicht zu dem von mir formuliertem
Matthias F. schrieb: > viele Daten (einige kByte) vom µC zum PC versendet werden müssen. > Hier habe ich jetzt das Problem das in unregelmäßigen Abständen Daten > verloren gehen. Falsches Protokoll oder fehlendes Handshake. > Im Datenblatt des FT232 ist mir anschließend aufgefallen, dass dieser > nur einen Sendepuffer von 256Byte hat. Reicht locker. > Wahrscheinlich kommt dieser mit dem Senden einfach nicht mehr hinterher. Nö. Der Puffer muß ja nur zwischen UART und USB puffern. USB arbeitet mit 12 Mbit/s, UART im Normalfall mit max. 115200 bit/s. > Ich habe nun jetzt die Leitungen CTS und RTS überkreuzt mit meinem µC > verbunden. > Das Phänomen scheint reduziert zu sein, dennoch habe ich weiterhin > Datenverluste. Softwarefehler. Der FTDI kann volles Rohr dauerhaft senden und empfangen, ohne Daten zu verlieren, selbst mit bis zu 3 Mbit/s. > Müsste sich bei einem Pufferüberlauf nicht der Pegel ändern und müsste > der Pegel nicht invertiert sein? Du bist auf dem Holzweg. Der FTDI steuert diese Leitungen NICHT selber, sondern er reicht die Signale vom PC durch! Dort muss die Software diese setzen! > Wie funktioniert das mit den CTS/RTS Leitungen überhaupt? Wird das > Senden gestoppt, wenn der FT232 keine Daten mehr annehmen kann, Nein. > oder > wird das Senden gestoppt, wenn der PC keine Daten mehr annehmen kann? Wenn die Software im PC glaubt, kein Daten mehr annhemen zu können und CTS inaktiv schaltet.
Die ganze Händeschüttlerei ist nur dann sinnvoll, wenn alle beteiligten sich auch darum kümmern. Viele Jahre lang wurden die Signale einfach mit Brücken "verdummt" - so lange, dass sich oft schon keiner mehr drum gekümmert hat. Übrigens: Das gilt für beide Beteiligten (Sender und Rücksender). Noch was: In vielen Fällen tut die Übertragungsroutine "blind" arbeiten. Ein Empfangspuffer hat also noch genügend freien Platz zu haben und wenn was zu Senden ist, wird’s einfach rausgerotzt. Also frage den Typen, der vor Deiner Tastatur sitzt, ob er alles richtig gemacht hat. Dabei denke doch bitte daran, das es zu spät ist zu sagen: "Ich habe die Schnautze voll", da dann oft noch, das angefangene Byte kommt. Oft wird auch Blockorientiert gearbeitet, indem z.B. ein Messwert ermittelt wird und dann dieser (oft in mehreren Bytes) verschickt wird.
Da die meisten STM32 USB in Hardware haben, könnte man auch das nehmen - hier übernimmt die Hardware vollautomatisch die Flusskontrolle, und es kann nichts verloren gehen außer wenn der µC kontinuierlich Daten produziert (z.B. Messung), der PC diese aber nicht schnell genug abholt.
Niklas G. schrieb: > Da die meisten STM32 USB in Hardware haben, könnte man auch das nehmen - > hier übernimmt die Hardware vollautomatisch die Flusskontrolle, und es > kann nichts verloren gehen außer wenn der µC kontinuierlich Daten > produziert (z.B. Messung), der PC diese aber nicht schnell genug abholt. Und du glaubst, daß jemand, der es nicht mal hinkriegt, eine einfache UART-Verbindung stabil aufzubauen, eine USB-Verbindung benutzen kann?
Falk B. schrieb: > Und du glaubst, daß jemand, der es nicht mal hinkriegt, eine einfache > UART-Verbindung stabil aufzubauen, eine USB-Verbindung benutzen kann? Es gibt sogar Leute, die schaffen es eingebettete Systeme mit WLAN auszustatten obwohl das um viele Größenordnungen komplexer als schnödes USB ist.
> Nö. Der Puffer muß ja nur zwischen UART und USB puffern. USB arbeitet > mit 12 Mbit/s, UART im Normalfall mit max. 115200 bit/s. Ja aber USB ist ja eine Schnittstelle in der es mehrere Teilnehmer gibt. Das heißt es darf nicht einfach willkürlich gesendet werden sondern der Bus muss auch erst frei sein. Und 256Byte bei 115200 bit/s sind sehr schnell voll. Vielleicht ist meine Aussage auch vernachlässigbar, da bin ich mir nicht sicher. >> Ich habe nun jetzt die Leitungen CTS und RTS überkreuzt mit meinem µC >> verbunden. >> Das Phänomen scheint reduziert zu sein, dennoch habe ich weiterhin >> Datenverluste. > > Softwarefehler. Der FTDI kann volles Rohr dauerhaft senden und > empfangen, ohne Daten zu verlieren, selbst mit bis zu 3 Mbit/s. Ich will einen Softwarefehler jetzt nicht ausschließen, aber ich habe den selben Code auch bei einer Lan Schnittstelle am laufen und hier funktioniert alles. Desweiteren prüfe ich vor dem Senden des Uart ob der letzte Sendebefehl abgeschlossen ist. Mehr sollte es ja eigentlich nicht zu managen geben. > Du bist auf dem Holzweg. Der FTDI steuert diese Leitungen NICHT selber, > sondern er reicht die Signale vom PC durch! Dort muss die Software diese > setzen! Ok, das hatte ich fast schon vermutet.
Niklas G. schrieb: > Da die meisten STM32 USB in Hardware haben, könnte man auch das nehmen - > hier übernimmt die Hardware vollautomatisch die Flusskontrolle, und es > kann nichts verloren gehen außer wenn der µC kontinuierlich Daten > produziert (z.B. Messung), der PC diese aber nicht schnell genug abholt. Das wäre natürlich super. Ich hatte diese Variante auch schon am laufen. Seltsamerweise war es damals so, dass ich alles mittels eines Terminal-Programmes getestet habe. Hier hatte meine Schnittstelle sauber funktioniert. Als ich jedoch eine PC-Software mittels Labview erstellen wollte musste ich festellen, dass sich in dieser Software der Com-Port nicht öffnen ließ. Nachdem ich hier eine lange Fehlersuche und viele Beiträge in verschiedenen Foren hatte, musste ich mich leider geschlagen geben und auf den FTDI umsteigen.
Niklas G. schrieb: > Falk B. schrieb: >> Und du glaubst, daß jemand, der es nicht mal hinkriegt, eine einfache >> UART-Verbindung stabil aufzubauen, eine USB-Verbindung benutzen kann? > > Es gibt sogar Leute, die schaffen es eingebettete Systeme mit WLAN > auszustatten obwohl das um viele Größenordnungen komplexer als schnödes > USB ist. In der Tat, der OP aber sicher nicht. Es sei denn, daß alle relevanten Subsysteme schon fertig sind.
Matthias F. schrieb: >> Nö. Der Puffer muß ja nur zwischen UART und USB puffern. USB arbeitet >> mit 12 Mbit/s, UART im Normalfall mit max. 115200 bit/s. > > Ja aber USB ist ja eine Schnittstelle in der es mehrere Teilnehmer gibt. Stimmt. > Das heißt es darf nicht einfach willkürlich gesendet werden sondern der > Bus muss auch erst frei sein. Stimmt auch. > Und 256Byte bei 115200 bit/s sind sehr schnell voll. Nö. Das sind riesige 22ms. Das ist für USB Zeitlupe. > Vielleicht ist meine Aussage auch vernachlässigbar, da bin ich mir nicht > sicher. ??? >> Softwarefehler. Der FTDI kann volles Rohr dauerhaft senden und >> empfangen, ohne Daten zu verlieren, selbst mit bis zu 3 Mbit/s. > > Ich will einen Softwarefehler jetzt nicht ausschließen, Das sollte man nie ;-) > aber ich habe > den selben Code auch bei einer Lan Schnittstelle am laufen und hier > funktioniert alles. Das kann auch Zufall sein. Sowas sieht man nur bei einem ECHTEN Streßtest incl. Messung der kritischen Parameter. > Desweiteren prüfe ich vor dem Senden des Uart ob der letzte Sendebefehl > abgeschlossen ist. Mehr sollte es ja eigentlich nicht zu managen geben. Scheinbar doch.
> Nö. Der Puffer muß ja nur zwischen UART und USB puffern. USB arbeitet > mit 12 Mbit/s, UART im Normalfall mit max. 115200 bit/s. https://www.ftdichip.com/Support/Knowledgebase/index.html?an232b_04flowctl.htm Hier findet man übrigens auch von FTDI eine Aussage, dass das sein kann.
Matthias F. schrieb: >> Nö. Der Puffer muß ja nur zwischen UART und USB puffern. USB arbeitet >> mit 12 Mbit/s, UART im Normalfall mit max. 115200 bit/s. > > https://www.ftdichip.com/Support/Knowledgebase/index.html?an232b_04flowctl.htm > Hier findet man übrigens auch von FTDI eine Aussage, dass das sein kann. Wollen wir wetten, daß dies nicht dein Problem ist? Der IC selber kommt seltenst bis nie in Bedrängnis, der Datentransfer auf dem USB läuft sehr stabil. Das Problem liegt in den allermeisten Fällen auf der Softwareseite beim PC oder Embedded Device.
Falk B. schrieb: > Wollen wir wetten, daß dies nicht dein Problem ist? Der IC selber kommt > seltenst bis nie in Bedrängnis, der Datentransfer auf dem USB läuft sehr > stabil. Das Problem liegt in den allermeisten Fällen auf der > Softwareseite beim PC oder Embedded Device. Also bei der Lan Schnittstelle benutze ich die selben Unterprogramme zum zusammenstellen meines Sendepuffers. Hier funktioniert alles. Also sollte das Zusammenstellen der Daten nicht das Problem sein. Wenn ich Debugge sehe ich auch, dass die verloren gegangenen Daten im Sendepuffer vorhanden sind. Wenn ich eine Wartezeit bei circa allen 1kByte einfüge funktioniert alles. Stelle ich meine Baudrate von 115200 auf 9600 funktioniert auch alles. Da bleibt doch nicht mehr viel übrig...
Matthias F. schrieb: > Falk B. schrieb: >> Wollen wir wetten, daß dies nicht dein Problem ist? Der IC selber kommt >> seltenst bis nie in Bedrängnis, der Datentransfer auf dem USB läuft sehr >> stabil. Das Problem liegt in den allermeisten Fällen auf der >> Softwareseite beim PC oder Embedded Device. > > Also bei der Lan Schnittstelle benutze ich die selben Unterprogramme zum > zusammenstellen meines Sendepuffers. Hier funktioniert alles. Das ist ja auch eher einfach. > Also > sollte das Zusammenstellen der Daten nicht das Problem sein. Nein, aber das Handshake bzw. Timing. Da stimmt irgendwie irgendwo was nicht. > Wenn ich Debugge sehe ich auch, dass die verloren gegangenen Daten im > Sendepuffer vorhanden sind. > > Wenn ich eine Wartezeit bei circa allen 1kByte einfüge funktioniert > alles. Wieviel Wartezeit? Auch das ist ein klares Zeichen, daß ein Handshaking bzw. deine Zwischenpufferung irgendwo nicht robust ist. > Stelle ich meine Baudrate von 115200 auf 9600 funktioniert auch alles. Weil dann deine Puffer deutlich weniger leisten müssen. Irgendwo ist ein zeitlicher Engpass drin. > Da bleibt doch nicht mehr viel übrig... Da bleibt verdammt viel übrig, du schiebst aber die Verantwortung für die Fehler und die Suche nach ihnen weit von dir. Ein immer wieder gern genutztes Konzept, auch überaus erfolgreich.
Falk B. schrieb: > Weil dann deine Puffer deutlich weniger leisten müssen. Irgendwo ist ein > zeitlicher Engpass drin. hast du im Gerätemanager unter erweiterten Einstellungen mal die BM Wartezeit auf 2ms gesetzt und ggf den Buffer auf 1k verkleinert ?
Matthias F. schrieb: > Als ich jedoch eine PC-Software mittels Labview erstellen wollte musste > ich festellen, dass sich in dieser Software der Com-Port nicht öffnen > ließ. Beitrag "STM32 und Labview" Das hier? Mal mit einer alternativen Software auf dem STM32 versucht, z.B. meiner USB-Tutorial mit STM32: Virtueller COM-Port? Hardware-Lösung für Software-Probleme ist immer irgendwie komisch...
Datenverlust bei hohen Baudraten und größeren Datenmengen kann ich bestätigen. Hab ich bei Tests mit meiner Android-App 'Serial USB Terminal' gesehen. USB mit mit 12 Mbit/s klingt zwar eigentlich schnell, aber in der Praxis kann es deutlich langsamer sein, wegen Paketierung und so. Das wichtigste war, die Daten auf USB-Seite möglichst schnell abzuholen, damit der Puffer im FTDI nicht überläuft. Nach diversen Optimierungen in der App (async. read API und USB-Buffer-Größe an Baudrate angepasst) tritt es kaum noch auf.
Kai schrieb: > Datenverlust bei hohen Baudraten und größeren Datenmengen kann ich > bestätigen. > > Hab ich bei Tests mit meiner Android-App 'Serial USB Terminal' gesehen. > USB mit mit 12 Mbit/s klingt zwar eigentlich schnell, aber in der Praxis > kann es deutlich langsamer sein, wegen Paketierung und so. Unfug. Das ist nichts als Halbwissen!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.