Hallo zusammen, hattet Ihr schonmal das Problem, dass der FT232R ab einer bestimmten Länge von Bytes "abstürzt", bzw. einen "Overrun" produziert? Ich versuche 500Bytes bei 115.2k unter WinXP am Stück drüber zu schicken - das scheint er nicht zu mögen. Weniger bzw. langsamer geht. FTDI-Seite: http://www.ftdichip.com/Products/ICs/FT232R.htm
@ Kay Imperator (imperator) >Ich versuche 500Bytes bei 115.2k unter WinXP am Stück drüber zu schicken Wie? Direkt auf den virtuellen COM-Port oder per direktem Treiber? >- das scheint er nicht zu mögen. >Weniger bzw. langsamer geht. Über den virtuellen COM-Port solle das problemlos laufen, dort sorgt der Treiber für die passende Pufferung. Beim Direktzugriff kann es sein, dass du dich selber darum kümmern musst, hab ich noch nie gemacht. Der FT232R hat 128 Byte TX Puffer in Hardware. MFG Falk
Falk Brunner schrieb: > Über den virtuellen COM-Port solle das problemlos laufen, dort sorgt der > Treiber für die passende Pufferung. Die nützt aber nichts gegen das Problem, dass ja jedes Byte über USB transferiert werden muss. Der generische Windows COM-Port-Treiber weiss ja nix von USB, als der entworfen wurde, gabs nur die Hardware bei Adresse 3F8 oder so. Bei seriellen Servern über Ethernet wie z.B. XPort ist das insofern anders, als da gegenüber ein ganzer Linux-Rechner drinsteckt. Die müssten also schnell mal 500 Bytes verkraften, aber probiert habe ich das noch nicht. Gruss Reinhard
Ich hab den IC mit den Virtual-Comport-Treibern von FTDI betrieben (VCP-Treiber, siehe http://www.ftdichip.com/Drivers/VCP.htm) So wollte ich den IC auch nutzen: wie einen RS232-Ersatz Das Problem tritt dann auf, wenn mein MicroController die Bytes zum PC sendet. Wahrscheinlich wichtig zu wissen: Die ganze Kommunikation läuft ohne Handshake -> also nur Rx / Tx zum uC. Ich hab dazu leider auch kein FAQ oder ähnliches bei FTDI gefunden. > Der FT232R hat 128 Byte TX Puffer in Hardware. @ Falk Heißt das dann, das Problem ist also nicht zu lösen, wenn ich bereits VCP nutze? > Die nützt aber nichts gegen das Problem, dass ja jedes Byte über USB transferiert werden muss. @ Reinhard Ich hab den USB-Datenstrom noch nicht analysiert, aber vermutlich schickt der IC nicht jedes seriell zu übertragende Byte in einem extra Paket los, sondern hat eine variable Payload - oder? Zu dem Thema hatte ich schon den USB-Host-Controller im Verdacht, dass dieser den FTDI zu selten "abholt" und dass der seine Daten aus seinem Fifo nicht schnell genug los wird. Wenn der IC aber mit noch deutlich höheren Baudraten spezifiziert ist, wäre es doch ein Armutszeugnis, wenn er schon bei 115.2k überfordert ist. Gruß, Kay
@ Kay Imperator (imperator) >Das Problem tritt dann auf, wenn mein MicroController die Bytes zum PC >sendet. Na Klasse, in deinem ersten Post klang das genau anders herum. "Ich versuche 500Bytes bei 115.2k unter WinXP am Stück drüber zu schicken - das scheint er nicht zu mögen." Das klingt nach "der PC sendet". >Wahrscheinlich wichtig zu wissen: Die ganze Kommunikation läuft ohne >Handshake -> also nur Rx / Tx zum uC. Muss aber auch dann gehen. 115k2 sind ~11kB/s, das ist lächerlich für USB, das kann der FT232 locker wegpuffern und DAUERHAFT abführen. >Heißt das dann, das Problem ist also nicht zu lösen, wenn ich bereits >VCP nutze? Mann, deine Logik muss man verstehen. Es ist noch nicht mal das Problem ansatzweise analysiert, da wirfst du schon die Flinte ins Korn. >Ich hab den USB-Datenstrom noch nicht analysiert, aber vermutlich >schickt der IC nicht jedes seriell zu übertragende Byte in einem extra >Paket los, sondern hat eine variable Payload - oder? Sicher, der packt möglichst viele Daten in einen USB-Frame, alles andere wäre nicht nur sinnlos sondern gar unmöglich, denn USB hat bis High Speed (12 Mbit/s) nur 1kHz Framerate. >Zu dem Thema hatte ich schon den USB-Host-Controller im Verdacht, dass >dieser den FTDI zu selten "abholt" und dass der seine Daten aus seinem >Fifo nicht schnell genug los wird. Kann sein, ist aber sehr unwahrscheinlich. >Wenn der IC aber mit noch deutlich höheren Baudraten spezifiziert ist, >wäre es doch ein Armutszeugnis, wenn er schon bei 115.2k überfordert >ist. Ist er nicht. Möglicherweise hast du ein schlechtes Terminalprogramm. Nimm mal Hterm oder Teraterm, die sollten das können. MfG Falk
Was hier in Serie läuft ist Silabs C8051 + FT232R kein Handshake, 1.5 MBit/s, 8N2 PC-seitig wird allerdings die FTD2XX.DLL genutzt (FT_Read/FT_Write) mit einigen weiteren Einstellungen: Timeouts Read 1 sek und Write 0.5 sek, Latenz runter gesetzt auf 2 ms, USB Transferlänge runter gesetzt auf 256 Bytes (USB IN und OUT). Die Einstellungen kann man auch im Gerätemanager für den Comport (zum Testen) machen (Anschlusseinstellungen -> Erweitert) p.s. der Buffer im FT232 (Controllerseite -> USB) ist nur 256 Bytes groß...
@ Falk Nur ruhig Blut - ok, vielleicht ist es falsch rübergekommen. Unterm Strich sollen die Daten jedenfalls von uC zu PC kommen. Was das VCP-Thema angeht, hat niemand die Flinte geworfen - das war tatsächlich als Frage gemeint. Wie kommt man hier mit Com-Port-Emulation weiter? Ich bin Deiner Meinung, das dies absolut keine nennenswerte Belastung darstellt - ich muss also irgendwo anders einen Fehler machen. Das Terminal-Thema werd ich mal anschaun - hab aktuell ein selbstgestricktes Programm laufen, das die Daten entgegennimmt. Hier hab ich jedoch keinen Fehlervermutet, da zum einen Win die Daten puffert und zum anderen läuft es ja fehlerfrei mit einer echten RS232. @Arc Net 256Bytes ist ein guter Hinweis. (FT_Read/FT_Write) hab ich mich noch nicht rangetraut - wollte ja das PC-Programm unverändert lassen (Virtual Com Port). Gruß, Kay
Moin zusammen, ich hab jetzt die Lösung [zumindest meines Problems] : Win-Geräte-Manager -> Ports (COM&LPT) -> USB Serial Port (COM xx) -> Eigenschaften -> Anschlusseinstellungen -> Erweitert -> "BM Einstellungen" -> Wartezeit (ms) : kleiner stellen, z.B. auf 3 Alle PC-Programme funktionieren bei mir nun absolut Problemlos - auch bei größeren Datenströmen. Trotzdem vielen Dank an alle, die sich bei der Problemsuche beteiligt haben! Gruß, Kay
@ Kay Imperator (imperator)
>Einstellungen" -> Wartezeit (ms) : kleiner stellen, z.B. auf 3
Auf welchem Wert stand es denn vorher?
115k2 sind ~11kB/s. Bei 1 kHz USB Framerate müssen im Mittel 11
Byte/Frame transportiert werden, bei 3ms akkumulieren sich maximal
33Byte. Bei 10ms sind es schon 110 Byte, der RX Puffer hat nur 256, was
ihn nach ca. 25ms überlaufen lässt. Aber sollte da nicht parallel auch
eine FIFO-Steuerung greifen, die bei 90% Füllstand automatisch die Daten
abschickt?
MFG
Falk
> da zum einen Win die Daten puffert
Und du vertraust Windows das es das tut ?
Wieviele andere Geräte sind denn noch an diesem Controller ?
Du solltest dir bewußt sein das normalerweise nur EIN Controller mit
einem USB Kanal Verbaut ist und danach (auf dem motherboard) nur noch
ein Hub kommt. Das heißt du hast nur EINEN 480MBit/s Kanal der Alle
Geräte bedienen Muß. Wenn ein Gerät mal dazwischen Funk oder zuviel
Bandbreite will : pech gehabt mit konstanter Datenrate ohne stolpern.
Und Windows kümmert sich auch nur wenn es "lußt" hat um diese USB
"Dinger".
Außerdem ist jedes Datenpacket immer 1ms lang egal wievile Date drin
stehen ob 1 byte oder 4000 Byte die brauchen immer 1ms.
Wenn du z.B. oft 5Byte packete verschickst dann würdest du mit 1000
Stück den Gesammten (480MBit/s)Bus blockieren (1000 x 1ms = 1s) und nur
1000 x 5 Byte übertragen 5000Byte/s. Windwos mag das aber nicht und
nimmt sich für Tatatur und Maus und so nen paar Slots weg das bedeutet
du hast stotterer drin und ne sche** Datenrate. Lösung Puffer
VOLLSTÄNDIG ausnutzen. Das geht aber nicht wenn du auf Verstanden
Antworten warten mußt für gesendete Befehle von 5 Byte länge. Dann ist
die Lösung einen anderen Bus als USB zu benutzen.
Naja, die einfachste und sicherste Lösung ist Handshake, entweder per Software oder viel besser per Hardware. Der FT232 benutzt die HW-handshake Leitung zum Signalisieren des vollen Puffers.
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.