Hallo, hat jemand Erfahrung mit virtuellen COM-Ports (VCP) bezüglich Timing? Ich möchte einem Controller alle 10ms über UART einen Befehl geben. Mit dem Mikrocontroller kein Problem. Zur einfacheren Bedienung würde ich aber gerne über den PC die Befehle ausgeben. Wenn ich jetzt in C oder Matlab diesen Code schreibe, und alle 10ms den neuen Befehl an den VCP schicke, sendet der die Befehle gleich weiter, oder läuft das nach Gutdünken des Betriebssystems mit mehreren Millisenkunden Varianz (mit < ~0,1ms kann ich mich gut anfreunden)? Hab die Frage extra im Mikrocontroller Forum geschrieben, da bei PC Programmierung Timing normal eher zweitrangig ist. Danke schon mal Gerald
Gerald M. schrieb: > sendet der die Befehle gleich weiter, oder läuft das nach > Gutdünken des Betriebssystems mit mehreren Millisenkunden Varianz Ja, das hängt stark vom Treiber und dessen Konfiguration ab, sowie vom Verhalten des Adapter-Chip selbst. Schließlich weiß keiner davon wann ein Paket zu Ende ist und abgeschickt werden soll; stattdessen werden Puffer verwendet die "gelegentlich" geleert werden. Du könntest überlegen, ein eigenes USB-Device mittels eines USB-fähigen Controllers zu implementieren, da hast du deutlich mehr Kontrolle. Das geht mittlerweile auch unter Windows ohne eigenen Treiber. Bei Interrupt-und Isochronen Transfers kannst du vom USB auch definiertes Timing (Latenz) verlangen.
:
Bearbeitet durch User
So wie es aussieht wird ja meist ein FTDI Chip benutzt, doch genaueres finde ich bei dem Treiber nicht (nur dass man Priority erhöhen kann und zusätzlich Latencies einstellen kann). Prinzipiell soll er einfach anfangen zu senden, sobald er Daten bekommt. Der Bottleneck liegt ja eher auf der RS232 Seite (115k Baud) als auf der anderen Seite. Also der Puffer wird schneller beschrieben als Daten heraus gesendet werden. Deshalb einfach anfangen sobald Daten da sind, bis der Puffer leer ist.
Gerald M. schrieb: > Prinzipiell soll er einfach > anfangen zu senden, sobald er Daten bekommt. Ich weiß jetzt nicht wie die das bei FTDI machen, aber dieses Vorgehen hat ein prinzipielles Problem: Wenn jedes Byte, das vorliegt, sofort als 1-Byte-Paket über USB geschickt wird, sinkt die Datenrate stark, weshalb man typischerweise mehrere Bytes sammelt und abschickt wenn keine weiteren kommen oder der Puffer voll ist oder ein Timeout eintritt. Man kann auch nicht einfach anfangen ein Paket zu senden, und wenn dann doch mehr Bytes vorliegen die noch hinten anhängen. Die meisten USB-Implementationen werden abgeschlossene Pakete verlangen. Gerald M. schrieb: > Der Bottleneck liegt ja > eher auf der RS232 Seite (115k Baud) als auf der anderen Seite. Das Hauptproblem ist, dass USB paketorientiert ist (geht auch gar nicht anders) und die serielle Schnittstelle mehr so ein kontinuierlicher Datenstrom ist. Die Adapter brauchen eine Heuristik, die halt nicht immer so funktioniert wie man es gerne hätte...
Ohne besondere Hardware und Software zu benutzen habe ich festgestellt, dass Verzögerungen im einstelligen Millisekunden-Bereich zu erwarten sind. Sporadisch (wenn der Rechner durch andere Programme belastet wird) können mehrere hundert Millisekunden Verzögerung entstehen. Das passiert jedoch nur selten.
Gerald M. schrieb: > (mit < > ~0,1ms kann ich mich gut anfreunden)? Das wird nicht klappen. Wenn du wirklich so genaue Kontrolle brauchst, müsstest du einen Mikrokontroller mit USB aussuchen und selbst programmieren. Du weisst ja (hoffentlich) was bei dir ein Bbefehl ist und kannst dafür sorgen, dass der Befehl sofort abgeschickt wird sobald z.B. ein CR übergeben wurde. Die Verzögerung durch USB sollte sich in Grenzen halten. Auf PC-Seite ist nicht viel zu machen, weil heute ein PC keine Schnittstelle mehr hat, über die man mit einem Befehl etwas direkt ausgeben kann. Die Systeme werden zwar schneller, aber immer weniger echtzeitig. Georg
Gerald M. schrieb: > neuen Befehl an den VCP > schicke, sendet der die Befehle gleich weiter, oder läuft das nach > Gutdünken des Betriebssystems mit mehreren Millisenkunden Varianz (mit < > ~0,1ms kann ich mich gut anfreunden)? Kommt darauf an(tm). Der Host kann USB Pakete nur "im Raster" schicken - das ist bei Full Speed anders als z.B. bei High Speed. Hängt etwas damit zusammen wie der Host Controller DMA handelt. Wenn dir so 1/8 ms Latenz im Schnitt ausreichen, dann nimm einen der -H Typen von FTDI (also FT232H, FT2232H), die laufen mit USB 2.0 High Speed. Allerdings macht auch der PC nicht ohne Weiteres ein Timing <55ms (oder <1ms) mit - da ist ja noch der OS Scheduler im Weg.
georg schrieb: > Du weisst ja (hoffentlich) was bei dir ein Bbefehl ist > und kannst dafür sorgen, dass der Befehl sofort abgeschickt wird sobald > z.B. ein CR übergeben wurde. Ich würde gar kein CR mitsenden... Wenn ein Steuerpaket z.B. 27 Bytes groß ist, schickt man halt immer 27Byte-USB-Pakete. Die kommen dann auch am Stück beim Controller an, und man weiß genau wo sie beginnen und aufhören. Geht natürlich nicht beliebig groß. Jim M. schrieb: > Kommt darauf an(tm). Der Host kann USB Pakete nur "im Raster" schicken - > das ist bei Full Speed anders als z.B. bei High Speed. Hängt etwas damit > zusammen wie der Host Controller DMA handelt. Das Hauptproblem wird der VCP-Treiber sein, weil der wahrscheinlich wie erläutert die Daten gar nicht sofort in USB-Pakete verpackt! Wenn man direkt auf USB-Ebene arbeitet, kann man ein definiertes Timing in gewissen Grenzen anfordern.
Hallo, > Gerald M. schrieb: > hat jemand Erfahrung mit virtuellen COM-Ports (VCP) bezüglich Timing? Ja, unter Windoews sind die nicht echtzeitfähig. Man kann höchstens erwarten, das ca. aller 10ms ein Datenpaket initiert wird. > Ich möchte einem Controller alle 10ms über UART einen Befehl geben. > Mit dem Mikrocontroller kein Problem. Ja, ober mit einem Echtzeitbetriebssystem. > Zur einfacheren Bedienung würde ich > aber gerne über den PC die Befehle ausgeben. Wenn du einen alten PC hast, auf dem noch DOS läuft, auch leicht möglich. > Wenn ich jetzt in C oder > Matlab diesen Code schreibe, und alle 10ms den neuen Befehl an den VCP > schicke, sendet der die Befehle gleich weiter, oder läuft das nach > Gutdünken des Betriebssystems mit mehreren Millisenkunden Varianz Ja, genau das ist der Normalfall. > Hab die Frage extra im Mikrocontroller Forum geschrieben, da bei PC > Programmierung Timing normal eher zweitrangig ist. Weil es in PC-Betriebssystemen eben auch nicht geht, wenn es im Bereich weit unter 1s liegt. Gruß Öletronika
:
Bearbeitet durch User
U. M. schrieb: >> Zur einfacheren Bedienung würde ich >> aber gerne über den PC die Befehle ausgeben. > Wenn du einen alten PC hast, auf dem noch DOS läuft, auch leicht > möglich. USB unter DOS? Da kommt bestimmt Freude auf, da geht wenig bis gar nix. USB Unterstützung in Funktionierend gab es bei M$ erst ab Win2000/Win XP. Wenn USB und Echtzeit dann sollte man eher Richtung Linux denken, da gab es -RT Patches. Niklas G. schrieb: > Das Hauptproblem wird der VCP-Treiber sein, weil der wahrscheinlich wie > erläutert die Daten gar nicht sofort in USB-Pakete verpackt! Meine derzeitigen Experimente würden bei 10ms schon eine Verzögerung anzeigen die ich zumindest unter Win 10 nicht bemerke. Die Richtung PC->µC kann der VCP Treiber nahezu unmittelbar raushauen. Ich habe hier den direkten Vergleich der Ansteuerung VCP vs. LibUSB-Win32. Da ist kaum Verzögerung gegenüber dem was USB ohnehin hat zu Bemerken, jedenfalls bei USB Full Speed.
Habe ich fast vergessen: FTDI Chips verwenden einen anderen Low-Level Treiber als USB CDC. Die sind also nur eingeschränkt vergleichbar.
Hallo, > Jim M. schrieb: >> Wenn du einen alten PC hast, auf dem noch DOS läuft, auch leicht >> möglich. > USB unter DOS? Da kommt bestimmt Freude auf, Natürlich dann nicht über USB, sondern über originäres COM-Port. Das sollte wohl klar sein. Ist aber sicher eh nicht relevant für den Fragesteller. Gruß Öletronika
Gerald M. schrieb: > Wenn ich jetzt in C oder > Matlab diesen Code schreibe, und alle 10ms den neuen Befehl an den VCP > schicke, sendet der die Befehle gleich weiter, oder läuft das nach > Gutdünken des Betriebssystems mit mehreren Millisenkunden Varianz (mit < > ~0,1ms kann ich mich gut anfreunden)? Auch Windows sollte eine Möglichkeit haben einen flush auf den Buffer zu machen. Allerdings spielt der Scheduler da noch ein Rolle.
Das meiste wurde bereits gesagt, im Grunde bist du bei Nuztung des VCP Treiber unter Windows auf ein minimal-1ms-Raster limitiert. Damit laesst sich, je nach Betrachtungsweise (Jitter nur bezogen auf das Raster, oder inklusive der dazu asynchronen Peripherie), deine geforderte 0.1ms Varianz zumindest ueber einen gewissen Zeitraum, oder aber im letzteren Falle auch gar nicht, realisieren. Selbst wenn du das Betriebssystem komplett von weiteren Lasten befreist, werden ueber kurz oder lang ein oder mehrere dieser 1ms Intervalle uebersprungen werden, meiner Erfahrung nach fuer Win7 dann gleich 20-100 davon, es entsteht also eine Luecke im zwei bis dreistellingen ms Bereich - um anschliessend wieder quasi unterbrechungsfrei weiter zu laufen. Sollte das fuer deine Anwendung nicht akzeptabel sein, empfehle ich, direkt woanders weiter zu suchen - beispielsweise mittels FT232H, Cypress ezUSB FX, etc. Kannst du dieses Problem hingegen alle hin und wieder einmal tolerieren, folgende Tipps fuer Dich um diese Intervalle auf ein Minimum zu reduzieren: - VCP Treiber fuer den konkreten COM-Port, den du nutzt, im Geraetemanager so einstellen, dass die kuerzeste Latenzzeit 1ms ist (Standard sind glaube ich 16ms) unter Port Settings -> Advanced. - Rechenintensive Prozesse, AutoUpdates, etc. voellig verbannen. - Fuer den Prozess, der im x ms Takt etwas senden soll, im Task-Manager die UAC Virtualisierung deaktivieren - UND GANZ WICHTIG: Auf einem Multi-Thread/Kern System fuer diesen Prozess unter 'Set Affinity' nur einen einzigen Prozessorkern (aber nicht CPU0) zuweisen! Dies laesst sich auch ueber Batch-Datei und Kommandozeile automatiseren, ohne dass man jedes Mal im Taskmanager klicken muss. Wenn Du obige Punkte beachtest, werden solche Luecken in der kontinuierlichen Uebertragung deutlich seltener als standardmaessig auftreten (je nach System vielleicht einmal alle 10s bis 100s). Es bleibt aber ein unschoener Hack, der nahezu nach einer besseren Loesung schreit! Viele Gruesse, xenonart
georg schrieb: > Das wird nicht klappen. Wenn du wirklich so genaue Kontrolle brauchst, > müsstest du einen Mikrokontroller mit USB aussuchen und selbst > programmieren. Nee. Das funktioniert grundsätzlich nicht. Man muß sich damit abfinden, daß es immer eine Raster bei der Übertragung in der 1 ms Größenordnung gibt und daß es durchaus Verzögerungen unbekannter Dauer geben kann. Insofern ist der ganze Ansatz des TO falsch. Exaktes Timing macht man quarzgesteuert im µC und Informationen überträgt man asynchron per UART bzw. VCP. W.S.
Gerald M. schrieb: > hat jemand Erfahrung mit virtuellen COM-Ports (VCP) bezüglich Timing? Nimm eine PCI/PCIe/Cardbus/ExpressCard Karte mit echtem 16550A-kompatiblem UART. So etwas ist problemlos bei den üblichen Versendern erhältlich. Wenn Du so spezielle Anforderungen hast, wirst Du damit leben müssen, dass auch der PC spezielle Anforderungen erfüllen muss. fchk
Vielen Dank für die ganzen Antworten, ich hatte es ja vermutet und gehofft ich irre mich. Ist nicht so schlimm. Da ich das ganze auch über vier Parameter bestimmen kann (Anfang, Ende, Inkrementwert und Inkrementzeit) kommt eben ein Mikrocontroller an den USB Port der dann eben das Timing und die Ausgabe der UART Befehle übernimmt, nachdem er über VCP die Parameter bekommen hat. Hat auch seinen Charme wenn man Triggerpulse quasi umsonst mitbekommt. Danke für die Antworten :)
> USB unter DOS? Da kommt bestimmt Freude auf, da geht wenig bis gar nix.
FreeDOS kann das
Ganz unabhängig von der verwendeten Schnittstelle kannst du auf einem Windows/Linux System keine exakten Timings in der geforderten Größenordnung erzeugen. Du brauchst zwingend externe Hardware, die Kommandos puffern und zu vorher festgelegten Zeiten ausführen kann. Also typischerweise einen Mikrocontroller mit USB Interface. Das Prinzip hast du direkt vor der Nase: - Maus - Drucker - Grafikkarte - Soundkarte - Scanner All diese Geräte müssen Signale im Bereich unter 1mS erzeugen und erfassen. Sie alle haben einen eigenen Mikrocontroller (mit integrierten Timern) zur Ablaufsteuerung und Pufferspeicher für die relativ unregelmäßige Datenübertragung zum PC.
Gerald M. schrieb: > kommt eben ein Mikrocontroller an den USB Port der dann > eben das Timing und die Ausgabe der UART Befehle übernimmt, nachdem er > über VCP die Parameter bekommen hat. Man kann auch Befehle direkt übergeben, nur muss man mit diesen einen Empfangspuffer im Controller füllen, und der Controller sendet die im festen 10ms-Raster aus. Es müssen bloss immer genug Befehle im Puffer sein, das sollte der PC schaffen. Eine verrückte Idee am Rande: Soundkarten geben Daten im festen Zeitraster aus - mit der Soundkarte passende Töne an ein Modem schicken... Georg
> Eine verrückte Idee am Rande: Soundkarten geben Daten im festen > Zeitraster aus Deswegen hatte ich die weiter oben genannt.
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.