Hallo, könnt Ihr mir eine Software, unter Windows, empfehlen, mit der ich den realen Datendurchsatz durch einen virtuellen Com-Port bestimmen kann? Eine freie Software wäre natürlich praktisch. Ich habe hier eine Controller-Platine die per Uart und einen Uart-USB-Wandler (FT232) Status-Updates an ein PC-Programm ausgibt. Die Schnittstellengeschwindigkeit ist auf 57600Bd. festgelegt. Ab und zu sendet auch das PC-Programm eine kurze Anweisung an die Platine. Die Kommunikation nutzt aber die Bandbreite der möglichen 57600Bd. bei weitem nicht aus. Ich würde nun gern bestimmen welche reale Datenrate wirklich übertragen wird.
An Hard-/Software zum Thema weiß ich auf die Schnelle nur kostenpflichtige (teure) Angebote. Evtl. sind hier einige Infos : Beitrag "ATmega 8515/USART empfängt nicht schneller als 9600 Baud"
> Ich würde nun gern bestimmen welche reale Datenrate wirklich übertragen > wird. Ossi dranhängen oder besser gleich einen Frequenzzähler.
also 57600Bd kann man ohne Schwierigkeiten auf jeden PC erreichen. Wenn es bei dir viel langsamer ist, dann kann es nur an extrem schlechter Software oder an der Latenz liegen. Wenn man immer ein Byte sendet und dann auf eine Antwort wartet dann halbiert das schon mal die mögliche Bandbreite.
Zunächst mal Danke für Eure Antworten. Ich denke, ich habe mich da etwas blöd ausgedrückt. Die Kapazität der seriellen Leitung wird nicht ständig voll ausgenutzt. D.h. es wandern nur "ab und zu" mal ein paar Datenpakete hin und her. Das ist so auch in Ordnung. Ich möchte nun bestimmen wie hoch die Menge der übertragenen Daten ist. Ich bräuchte also z.B. ein Sniffer-Programm welches die Daten am virtuellen Com-Port mitschreibt. Bei einem festen Zeitraum könnte ich dann bestimmen welche Menge Daten, z.B. pro Sekunde, übertragen werden. Hintergrund: Ich würde gern statt der seriellen Leitung eine Funkstrecke einsetzen. Diese hat jedoch einen geringeren effektiven Datendurchsatz als 57600 (over the air). Die Schnittstellengeschwindigkeit des Funkmoduls kann ich auf 57600 einstellen. Wenn also die tatsächlich übertragene Datenmenge unterhalb der Datenrate der Funkstrecke bleibt muss ich nicht mit Datenverlusten rechnen, maximal mit verspäteten Daten.
Bastler schrieb: > Ich bräuchte also z.B. ein Sniffer-Programm welches die Daten am > virtuellen Com-Port mitschreibt. http://www.heise.de/download/free-serial-port-monitor.html Funktioniert mit allen seriellen Schnittstellen, ob "virtuell" (USB, Bluetooth, Ethernet-Deviceserver etc.) oder "real".
USB sendet pro Frame max. 8 Bytes und das alle 10ms. Machst du ne Pause in den Daten von mehr als 10ms bekommst du erst ins NÄCHSTE Frame wieder was rein. Ich glaub die Werte stimmen nicht ganz je nach USB-Variante. Aber Google einfach danach. Im Extremfall ist USB also schnarchlangsam!
Abdul K. schrieb: > USB sendet pro Frame max. 8 Bytes und das alle 10ms. Erzähl mal nochn Märchen. Bei 115200Baud ist ein üblicher Prolific mindestens gleich schnell, wie ne echte UART. Die Umsetzer haben deutlich größere Puffer, als die standard UART. Der FTDI hat sogar 4kB. Du mußt also nur in großen Blöcken senden, dann begrenzt allein die Baudrate den Durchsatz.
Ich schrieb nichts anderes. Genaue Werte sollten per Google ermittelt werden, habe die nicht im Kopf. USB1.5 USB2 verhalten sich auch unterschiedlich. Der Haken bei USB ist eben Warten auf eine synchrone Rückmeldung: Dann flutschen die Bytes eben wie oben beschrieben schön einzeln in Frames und das dauert. Asynchrones Streaming dagegen schafft ca. 90% der Bandbreite.
Bastler schrieb: > Ich würde nun gern bestimmen welche reale Datenrate > wirklich übertragen wird. Das hängt in erster Linie von dir und deiner Anwendung ab. Im USB-Bereich wird grundsätzlich paketorientiert gearbeitet, häufig (aber nicht immer) ist die Paketgröße 64 Bytes. Wenn du also volle Kanne Daten sendest, so daß der Fifo im FTDI-Chip immer so einigermaßen gut gefüllt ist, dann erreichst du eben die Datenrate, die aus deiner Baudrate resultiert. Wenn du hingegen Lücken läßt und dabei der Fifo im FTDI-Chip leer läuft, dann gibt's Einbrüche in der realen Übertragung - aber das sollte dich eigentlich nicht scheren, denn das USB-interne Tempo ist allemal größer als die üblichen Baudraten. Ärgerlicher wird es, wenn jemand sein System bidirektional mit Warten organisiert, also wenn dein uC erstmal ein Byte lesen will, dann ein Byte als Antwort sendet, daraufhin ein nächstes Byte lesen will und so weiter. Dann macht die USB-Verbindung weithin nix, bei nächster Gelegenheit (nach ner Millisekunde oder noch später) wird nur ein lumpiges Byte im (meist) 64 Byte großen Block übertragen und während dieser Zeit wartet sich das Programm im PC die Beine in den Bauch. Wenn es dann endlich die Antwort hat, sendet es wieder nur 1 Byte, wieder unausgenutzter Block, diesmal Warten auf Seite des uC ... usw. Da macht es keinen Unterschied mehr, ob man seriell mit 4800 Baud verkehrt oder mit 56K Baud. Also: solch einen Warte-Hin-Warte-Her Betrieb vermeiden und Datenströme im uC puffern. W.S.
Danke an Alle! Hat super geklappt mit dem Free-Serial-Port-Monitor. Leider ist die Version mit ein paar Funktionseinschränkungen versehen. Ging aber trotzdem. Ich habe einfach 100 sekunden lang den Datenstrom aufgezeichnet. Daraus ergibt sich, daß doch mehr Daten übertragen werden, als ich erhofft hatte. Etwa 40kB/s.
Bastler schrieb: > Etwa 40kB/s. Bei 57600 Baud? Da stimmt was nicht, denn damit sind rein physikalisch nicht mehr als 5760 Bytes/sec übertragbar. Oder meinst Du mit "kB" Kilobit?
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.