USB: Timeout nach einem Restart

Bernd Gast #3629677
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Jim M. #3629717
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bernd Gast #3629741
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bernd Gast #3630095
Lesenswert?
• ▲
▼ 
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?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
bluppdidupp Gast #3630882
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jim M. #3630991
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Kein Name Gast #3631218
Lesenswert?
• ▲
▼ 
> 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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren