Win7: USB-USART Adapter erzeugt hohe CPU Last im System Prozess

OP #7412251
Lesenswert?

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).

#7412352
Lesenswert?

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.

#7412364
Lesenswert?

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.

#7412369
Lesenswert?

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?

OP #7412370
Lesenswert?

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.

Angehängte Dateien:
OP #7412378
Lesenswert?

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.

#7412831
Lesenswert?

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...

OP #7412950
Lesenswert?

"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

#7412969
Lesenswert?

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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren