Unter Win7-64Bit benutze ich USB-USART Adapter (CP2102 & FT232) um von einem externen Geräten zu lesen. Softwaretechnisch gibt es keine Probleme und die Adapter tun was sie sollen. Jedoch tritt dabei eine hohe CPU Last im System Process auf (~3% , 1 Core ist mit ~25% dauernd am rödeln). Der Port wird mit 9600,8,N,1 no flow control gelesen. Das Phänomen tritt gleichermassen bei dem eigenen Programm als auch beim lesen über Tera Term auf. Die Systemlast wird auch nicht durch eigene I/O Aktivitäten verursacht. Es reicht nach dem CreateFile() [*] den eigenen Prozess mit dem Debugger anzuhalten, der System Prozess rödelt weiter munter vor sich hin solang der Port offen ist. Ebenso kann man die Rx/Tx Leitungen abziehen so dass auf der USART Seite keinerlei I/O Aktivität auftritt. Der Process Explorer zeigt dass der System Thread: ntoskrnl.exe!ExQueueWorkItem+0x80 die CPU Last zieht. https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-exqueueworkitem Da das Phänomen sowohl bei dem CP2102 als auch bei einem FT232 auftritt scheint es eher durch eine gemeinsame Treiberschicht verursacht zu sein. Tritt das Problem bei euch auch auf? Oder hat jemand eine Idee wonach man noch weiter suchen könnte? [*] geöffnet wird mit CreateFile( com, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED, NULL ); Gelesen wird in einem eigenen Thread (aber wie gesagt reicht es ja schon CreateFile() aufzurufen um die CPU Last im System Prozess zu erzeugen).
Angehängte Dateien:
Du koenntest mal versuchen, an die Statuspins des RS-232 feste Pegel zu legen, und das Verhalten dabei zu bebeobachten.
Motopick schrieb: > Du koenntest mal versuchen, an die Statuspins des RS-232 > feste Pegel zu legen, und das Verhalten dabei zu bebeobachten. Einfach ein 5cent Stück zwischen die Pins klemmen, so sind dann alle Beinchen auf 0. Daran wirds aber nicht liegen, der RS232 Treiber hält die Pins auf vorbestimmten Pegeln.
> der RS232 Treiber hält > die Pins auf vorbestimmten Pegeln Es geht natuerlich nur um Eingangspins. Permutiere die Kombinationen einmal durch. So viele sind es ja nicht. Vielleicht erlebst du dann eine Ueberraschung :). Es koennte auch empfehlenswert sein, HW-Flowcontrol auszuschalten. > Einfach ein 5cent Stück zwischen die Pins klemmen Fuer zuverlaessige Aussagen muss man auch zuverlaessig bauen. Und nicht so einen Murks.
Motopick schrieb: >> der RS232 Treiber hält >> die Pins auf vorbestimmten Pegeln > > Es geht natuerlich nur um Eingangspins. > Permutiere die Kombinationen einmal durch. > So viele sind es ja nicht. > Vielleicht erlebst du dann eine Ueberraschung :). > Es koennte auch empfehlenswert sein, HW-Flowcontrol auszuschalten. >> Einfach ein 5cent Stück zwischen die Pins klemmen > > Fuer zuverlaessige Aussagen muss man auch zuverlaessig bauen. > Und nicht so einen Murks. Aha. Murks ist also, wenn du weisst, dass definitiv alle Pins auf 0 sind. Was in diesem Fall aber irrelevant ist, den Test kann man sich sparen. Da floatet nichts und müllt das System mit Anfragen zu. Du könntest ja auch empfehlen die Maus mal abzustecken, die "ruckelt" und müllt das System mit Anfragen zu. Dadurch dass Mäuse früher mal am RS232 hingen kann das ja irgendwelche Querverbindungen zum USB-232 Treiber haben --- Genauso weit hergeholt und genauso Quatsch wie floatende Pins nahc einem RS232 Treiber. // edit: Der hält auch die Eingänge auf vorbestimmten Pegeln. Schau dir mal ein Datenblatt an. z.B. MAX232.
:
Bearbeitet durch User
> den Test kann man sich sparen
Wenn du so sicher bist, dass die statische(!) Belegung
der Eingangspins keinen Einflauss hat...
Ich habe im uebrigen keine Vermutung bzgl. floatender Signale
geaeussert. Ebenso ging es nicht darum, ausschliesslich eine '0'
auf die Pins zu legen.
Nun bist du mit deinem Wissen ganz allein (im Wald).
Wenn du es schon verabscheust, so einen einfachen Test durchzufuehren.
Aber warum traegst du dein Problem dann ueberhaupt vor?
Meinst du, dass hier irgendjemand etwas an der Lastsituation
auf deiner CPU aendern koennte?
Angehängte Dateien:
-
CP2102_Flow_Control_Pins.png
160 KB -
FT232BM_Flow_Control_Pins.png
130 KB
> Status Pins auf feste Pegel legen
Im DB des CP2102 ist angegeben dass die Flow Control Input Pins, wenn
nicht benötigt, offen gelassen werden können.
Ebenso gibt FTDI in der AN232B-02 an dass diese intern mit Pull Ups
versehen sind.
Eine zwangsweise Beschaltung gab auch keine Veränderung.
> Eine zwangsweise Beschaltung gab auch keine Veränderung.
Dann hast du mein volles Bedauern.
Ein Prolific hatte eine ebensolche/aehnliche Macke und war
mit den Statussignalen "ruhig" zu stellen.
Ha, die Ursache ist gefunden! Der Verursacher ist ein "Lindy USB 3.0 Aktivverlängerungskabel". Wird dieses durch ein normales USB 2.0 Verlängerungskabel ausgetauscht ist Ruhe im Karton. Wieso das Aktivverlängerungskabel solche Auswirkungen haben kann ist mir schleierhaft. Das Kabel hat doch keinen eigenen Treiber im System und sollte aus Sicht des BS transparent sein, oder? Der reine Datenverkehr lief ja ohne Störungen.
Hast du denn keinen USB-Packet-Sniffer?
>Hast du denn keinen USB-Packet-Sniffer?
Nö, hatte bisher noch keinen Bedarf.
Link / Empfehlung?
Muss ich mal auf anderen Rechner gucken. Kann aber dauern.
K. M. schrieb: > Ha, die Ursache ist gefunden! > Der Verursacher ist ein "Lindy USB 3.0 Aktivverlängerungskabel". > > Wird dieses durch ein normales USB 2.0 Verlängerungskabel ausgetauscht > ist Ruhe im Karton. Mäßig spannend. > Wieso das Aktivverlängerungskabel solche Auswirkungen haben kann ist mir > schleierhaft. > Das Kabel hat doch keinen eigenen Treiber im System und sollte aus Sicht > des BS transparent sein, oder? "Aktiv"-Verlangerungskabel läßt darauf schließen, dass es zumindest einen Hub enthält. Wie sonst sollte es "aktiv" sein können? Und wenn es einen Hub enthält, kann folgende Situation eintreten: 1) OS erkennt einen "Standard-Hub" und benutzt den dafür verfügbaren Treiber. Was es darf und sogar sollte. 2) Der verschissene Hub verhält sich aber nicht wirklich standardmäßig (was er eigentlich tun sollte) Sprich: Billich-Schrott aus China. You got, what you paid for. No mercy. Aber abschließend noch ein Hinweis: Windows als wirklich benutzerfreundliches OS kann im Gerätemanager die ganze Scheiße auch als Baum darstellen. Spätestens in dieser Darstellung wärst du über den Hub im Kabel gestolpert... Sowas Komfortables wie den Windows Geräte-Manager wünsche ich ich mir auch im Standard-Lieferumfang von Linux...
> Wireshark. Danke, schau ich mir mal an. Wireshark scheint USB jedoch unter Win nicht direkt zu unterstützen. https://gitlab.com/wireshark/wireshark/-/wikis/CaptureSetup/NetworkMedia nur über den Umweg über USBPcap https://desowin.org/usbpcap/
>"Aktiv"-Verlangerungskabel läßt darauf schließen, dass es zumindest einen Hub enthält Die Produktbeschreibung spricht von Elektronik zur Signalverstärkung. https://www.lindy.de/?&pi=43155 >im Gerätemanager .... als Baum darstellen. Spätestens in dieser Darstellung wärst du über den Hub im Kabel gestolpert... Nö, da erscheint im Device Manager nichts, im Gegensatz zu einem echten Hub. >Sprich: Billich-Schrott aus China. You got, what you paid for. 22€ ? Btw. Lindy ist eine deutsche Firma. https://en.wikipedia.org/wiki/Lindy_Electronics
> nur über den Umweg über USBPcap Ist doch beim Netzwerk genau dasselbe. Ohne Treiber kein Schnueffi. Frueher™ aks Wireshark dieses Stoeckchen noch nicht holen konnte, gab es immerhin schon USBlyzer und USBtrace. > Link / Empfehlung? Womit die Frage denn auch beantwortet ist. Beide sind auch empfehlenswert. Aber eben nicht fuer lau. > >Sprich: Billich-Schrott aus China. You got, what you paid for. > 22€ ? > Btw. Lindy ist eine deutsche Firma. Ich wuerde mal auf 99 % Import tippen. und 1 % Eigenentwicklung. Garbage In, Garbage Out
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.