Bei meiner seriellen Übertragung ist die Portzugriffgeschwindigkeit entscheidend für die Gesamtdauer, und die gilt es zu minimieren. Momentan nutze ich eine an Qt angepasste Bibliothek, die aber offenbar nicht vollständig implementiert ist, d.h. ich muss teilweise pollen und warten. Eine ältere Implementierung mit ReadFile() und SetCommTimeouts() ist etwas schneller, aber immer noch nicht so schnell wie die Übertragung von einem Mikrocontroller aus (ist ja klar, der schickt nach wenigen µs eine Antwort und muss nicht auf BS und USB warten). Die Frage ist also: kann man das irgendwie beschleunigen?
uffa schrieb: > Eine ältere Implementierung mit ReadFile() und SetCommTimeouts() ist > etwas schneller, aber immer noch nicht so schnell wie die Übertragung > von einem Mikrocontroller aus (ist ja klar, der schickt nach wenigen µs > eine Antwort und muss nicht auf BS und USB warten). > > Die Frage ist also: kann man das irgendwie beschleunigen? das kann ich nicht galauben. Liest du jedes Byte einzeln mit Readbyte oder mehre? Ein PC schafft es bequem 1Mbaud zu lesen, das muss man schon sehr viel falsch machen damit es langsamer wird.
Dein Problem ist das der USB Serial Converter versucht zu Puffern da ein USB Packet mimum 64byte große ist. Wenn du einen FTDI verwendest schau dir mal den DX2X Treiber an. Mit der kanst das Maximale aus einem FTDI rausholen.
Genau "Peter II", das Problem ist, dass ständig Bytes einzeln gelesen/geschrieben werden. Es wäre besser, die Daten zusammen per USB zu übertragen und die RS-232 Verbindung dann per Mikrocontroller zu erledigen. Es werden u.A. Wandler von FTDI und Prolific genutzt, auf den Schnittstellentyp habe ich keinen Einfluss. Danke "xxx" für den Tipp mit dem Puffer, ich werde mal versuchen, an den Einstellungen drehen
Hi, man muss vor allem bei USB-seriell-Wandlern zwischen Durchsatz und Latenz unterscheiden. Den Durchsatz mag man mit entsprechenden Protokollen noch ganz gut hin bekommen, bei der Latenz sind USB-Lösungen aber echten PCI-E-Seriell-Karten haushoch unterlegen. Das Problem bei USB ist, dass es keine Hardware-Interrupts gibt und der Host (PC) auch s.g. "interrupt transfers" immer selbst initiieren muss (polling). Dadurch ergibt sich auf der einen Seite (je nach Treiber und USB-Modus) eine vergleichsweise sehr hohe Round Trip Time von Datenpaketen und auf der anderen Seite eine hohe Empfindlichkeit für FIFO-Überläufe bei hohen Datenraten ohne Flusskontrolle. PCI/PCI-E-Karten können dagegen Hardware-Interrupts auf der CPU beim Empfang der Daten auslösen und stellen somit die empfangenen Daten der Anwendung viel schneller zur Verfügung. Irgendwie habe ich diesbezüglich Verbesserungen bei USB3 im Kopf, kann mich aber gerade nicht genau entsinnen. Was ich eigentlich damit sagen möchte: Es liegt nicht am Betriebssystem, dass Deine Daten zu langsam ankommen, sondern viel eher an der Implementierung und an der verwendeten Hardware. Ich habe hier mit speziellen PCI-RS485/422-Karten problemlos ~10 MBit/s bei sehr geringen Latenzen übertragen. Gruß, Oliver
uffa schrieb: > Genau "Peter II", das Problem ist, dass ständig Bytes einzeln > gelesen/geschrieben werden. Es wäre besser, die Daten zusammen per USB > zu übertragen und die RS-232 Verbindung dann per Mikrocontroller zu > erledigen. wenn du sie per USB als BLock übertragen kannst warum dann nicht auch per RS232?
Protokolle für die serielle Schnittstelle sollte man so aufbauen, daß nicht einzelne Bytes im "ping-pong"-Verfahren übertragen werden, sondern immer größere Datenblöcke gesendet bzw. empfangen werden. Dafür sind die seriellen Schnittstellen üblicher PCs optimiert, das hat mit den Sende- und EmpfangsFIFOs in der Standard-PC-UART 16550 angefangen, und ist bei USB-Seriell-Adaptern noch ausgeprägter. Idealerweise sollten Antworten asynchron ausgewertet werden, d.h. bei einer blockorientierten Übertragung sollte nicht nach jedem Block auf eine Quittung gewartet werden. Ein Beispiel dafür ist das ZModem-Protokoll. Natürlich ist diese letzte Eigenschaft nicht überall sinnvoll abbildbar, aber man sollte so etwas bei der Gestaltung eines Protokolles im Hinterkopf behalten.
http://www.ftdichip.com/Drivers/D2XX.htm "D2XX drivers allow direct access to the USB device through a DLL. Application software can access the USB device through a series of DLL function calls." In den Schnittstelleneinstellungen kann man Puffergrößen und irgendwelche Wartezeiten reduzieren, das bringt was: in meinem Fall 25%-200%.
Ich hab mal eine Simulation geschrieben, in der Datenrate und Delays gegeneinander abgewogen werden, und dann wurde klar dass der dDelay schnell mal dominiert. Das bedeutet man sollte das Protokoll auf grosse Bloecke optimieren. Lass mal hoeren weshalb du einzelne Bytes uebertragen moechtest. Und wir erzaehlen dann wie man das mit grossen Bloecken besser macht.
Danke auch für eure Beiträge - leider habe ich auch keinen Einfluss auf das Protokoll. Denkbar wäre jedoch, die Daten als Block über USB zu übertragen und dann einen Mikrocontroller einzusetzen, der durch die Interruptfähigkeit entsprechend schnell reagieren kann.
uffa schrieb: > Danke auch für eure Beiträge - leider habe ich auch keinen Einfluss auf > das Protokoll. kannst etwas mehr über das Protokoll sagen? Ist es wirklich so das du jedes byte einzeln auf die Reise schicken musst und dann auf eine Antwort wartest?
Was packt man denn so in etwa an Bandbreite mit einem aktuellen Windows?
Michel schrieb: > Was packt man denn so in etwa an Bandbreite mit einem aktuellen Windows? keine ahnung, denn ds limit ist die uart. 1Mbit ist kein Thema.
Sry aber ich hab mir das jetzt mal durchgelesen und irgendwie kapier ich nicht um was es eigentlich geht. >Eine ältere Implementierung mit ReadFile() und SetCommTimeouts() ist >etwas schneller, aber immer noch nicht so schnell wie die Übertragung >von einem Mikrocontroller aus Ist da nicht immer ein uC im Spiel, oder überträgst Du von PC nach PC? >von einem Mikrocontroller aus (ist ja klar, der schickt nach wenigen µs >eine Antwort und muss nicht auf BS und USB warten). Und was meinst Du hiermit? Was bedeutet BS? Wer wartet hier auf USB? Der PC mit Sicherheit nicht. Das erledigt der USB-Host.
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.