USB: Timeout nach einem Restart

[Bernd (Gast)]

Hallo,

bei meinem aktuellen Projekt setze ich einen ARM7 Controller ein. Dieser 
besitzt einen USB-Device, welchen ich als USB CDC initialisiert habe. 
Über das Hyperterminal kann ich mich mit dem Device verbinden, Daten 
übertragen und Daten lesen. U. a. kann ich auch einen Befehl übertragen, 
der den ARM7 Controller neu starten lässt.

Nach einem solchen Neustart kann ich jedoch nicht mehr auf den 
virtuellen Comport mittels Hyperterminal zugreifen. Im Gerätemanager 
wird das Gerät weiterhin richtig erkannt und angezeigt.

Bei einem Neustart ist der USB-Device für kurze Zeit nicht mit dem 
Computer verbunden, da der 1k5 Widerstand nicht aktiv ist. Wenn diese 
Zeitspanne zu kurz ist, wird das Device anscheinend nicht mehr richtig 
konfiguriert in Windows. Wenn ich z. B. in der Main ganz am Anfang einen 
Breakpoint setze und ein paar Sekunden warte und erst dann den ARM7 
konfiguriere (einschließlich der USB-Schnittstelle) wird der Device 
anschließend auch wieder vom Hyperterminal erkannt.

Weiß jmd von euch wie groß dieses Delay zwischen "USB-Device verbunden" 
und "USB-Device nicht verbunden" sein muss?

Gruß
Bernd

[Jim M. (turboj)]

Bernd schrieb:
> Nach einem solchen Neustart kann ich jedoch nicht mehr auf den
> virtuellen Comport mittels Hyperterminal zugreifen. Im Gerätemanager
> wird das Gerät weiterhin richtig erkannt und angezeigt.

Bekannter Bug im COM-Subsystem von Windoof. Du müsstest Hyperterminal 
beenden (oder den COM Port schliessen) bevor der Reset "fertig" ist 
und das USB Gerät sich neu angemeldet hat. Tut man dies nicht, ist der 
"Name" (COMXY) blockiert.


Bernd schrieb:
> groß dieses Delay zwischen "USB-Device verbunden"
> und "USB-Device nicht verbunden" sein muss

Bis das Programm (Hyperterminal) den Zustand "ist weg" erkennt und den 
Port schliesst. Ich würde mich nicht allzusehr wundern, wenn das wenig 
deterministisch ist - und aus dem Bauch heraus einige 10 Sekunden 
ansetzen.

[Bernd (Gast)]

Jim Meba schrieb:
> Bekannter Bug im COM-Subsystem von Windoof. Du müsstest Hyperterminal
> beenden (oder den COM Port schliessen)

ich hab diesen Zustand sogar, wenn ich gar nicht mit dem Hyperterminal 
verbunden bin.

PC läuft, USB-Device wird angeschlossen und bootet. Jetzt wird das 
Device in der Auswahl im Hyperterminal angezeigt. Ich verbinde mich 
allerdings nicht mit dem Device, sondern resette den Device über meinen 
Debugger. Anschließend wird das Device nicht mehr in der Auswahl des 
Hyperterminals angezeigt. Der Device Manager hat gar nicht mitgekriegt, 
dass der Device kurzzeitig weg war.

Meine Windows-App hab ich unter Qt programmiert und verwende QSerialPort 
- hier habe ich das gleiche Phänomen.

[Bernd (Gast)]

Bernd schrieb:
> Anschließend wird das Device nicht mehr in der Auswahl des
> Hyperterminals angezeigt.

also nach einem Reset des Devices - sprich Neustart.

[Bernd (Gast)]

wie zeitaufwändig ist es eigentlich einen eigenen CDC Treiber für 
Windows zu programmieren, der diesen Bug nicht besitzt?

Bis jetzt hab ich keinerlei Erfahrungen sammeln können im Bereich der 
Windows-Treiberprogrammierung. Ist sowas innerhalb eines Tages 
umzusetzen oder benötigt man eine längere Einarbeitungszeit?

[bluppdidupp (Gast)]

Ich würde lieber von CDC auf HID/WinUSB umsteigen, dann kann man sich 
das Treiber schreiben ganz sparen (zumindest bei HID, bei WinUSB so 
richtig erst ab Win8).
Die Anwendung könnte das Gerät dann anhand von DeviceID und Product-ID 
dann auch selbst erkennen oder Dropdownliste aller COM-Ports oder 
sonstige Tricksereien ;D

[Jim M. (turboj)]

Bernd schrieb:
> wie zeitaufwändig ist es eigentlich einen eigenen CDC Treiber für
> Windows zu programmieren, der diesen Bug nicht besitzt?

Sehr zeitaufwändig, da das Problem im "Seriellen" Teil liegt, der nicht 
wirklich dynamisches Ab- und Anstecken zulässt. Früher waren diese Art 
von Ports nunmal fest verbaut.

Es ist wesentlich einfacher, die Zielapplikation auf Libusb oder WinUSB 
umzustellen, wenn man den Quellcode hat.

[Kein Name (Gast)]

> Früher waren diese Art von Ports nunmal fest verbaut.

Kann nicht der wirkliche Grund sein.

Unter Linux behandelt zumindest der Kernel die Unterbrechungen halbwegs 
sinnvoll. Mit einem Breakpoint kann man natürlich ein Timeout beim 
Connect erzeugen. Aber Pullup ausschalten oder Stecker raus-rein und man 
bekommt ein Device.