Hi,
ich habe hier einen Beaglebone Black, welcher mit einer
Bare-Metal-Software betrieben wird. Diese verwendet u.a. die
USB-Schnittstelle als serielles Interface, sprich wenn das Gerät an
einen PC-angeschlossen wird, taucht dort ein neuer COM port (bzw. ein
/dev/ttyACM) auf.
Das funktioniert bisher problemlos mit allen Linux-Versionen und mit
Windows bis Version 7. Windows 8 wurde nie getestet, Windows 10 macht
Probleme:
1. Der COM-Port lässt sich manchmal nicht öffnen, was sich aber durch
mehrfache Versuche umgehen lässt - irgendwann klappt es dann mit exakt
den gleichen Parametern wie vorher (das Problem wurde schon
detaillierter untersucht: die aktuellen Parameter der seriellen
Schnittstelle werden mit GetCommState() emittelt, setzt man dann exakt
die gleichen Parameter wieder mittels SetCommState(), verweigert Windows
diese als ungültig - klingt also nach einem Windows-Bug). Lustigerweise
funktioniert GetCommState()/SetCommState() irgendwann, wenn man es nur
oft genug wiederholt.
2. Während des Betriebes scheint die Verbindung auch immer mal
abzureißen (das Problem konnte bisher leider noch nicht näher untersucht
werden). Ein Neustarten des Gerätes und der Host-Software behebt das
Problem zumindest kurzzeitig, Windows verpasst dem COM-Port dabei keine
neue Nummer.
Hat irgend jemand eine Idee, was sich unter Windows 10 in der Ecke
geändert haben könnte? Iat das wirklich ein Windows-Bug oder hat MS für
serielle Schnittstellen dieser art irgend was neues, inkompatibles
eingeführt?
Jede Idee und jeder Hinweis ist willkommen!
IMHO ist das weder ein Problem irgendeines Mikrocontrollers noch von
Digitalelektronik, sondern liegt an dem PC Betriebssystem oder dort
verwendeten Treibern.
Harstad schrieb:> GetCommState()/SetCommState()
deutet imho darauf hin, dass du das Programm zum Zugriff auf die
Schnittstelle selbst geschrieben / kompiliert hast. Kann es sein, dass
dein Compiler nicht auf Windows-10 Stand ist und falsche/alte
Bibliotheken mitbringt? Ich hatte solche Effekte des öfteren mit LCC32
und Windows XP / Windows 7.
Möglicherweise ist dein USB Treiber auch buggy. Versuch es einfach mal
mit einem anderen Adapter und damit Treiber.
Georg G. schrieb:> Harstad schrieb:>> GetCommState()/SetCommState()>> deutet imho darauf hin, dass du das Programm zum Zugriff auf die> Schnittstelle selbst geschrieben / kompiliert hast. Kann es sein, dass> dein Compiler nicht auf Windows-10 Stand ist und falsche/alte> Bibliotheken mitbringt? Ich hatte solche Effekte des öfteren mit LCC32> und Windows XP / Windows 7.
Gute Frage, ich arbeite windowsseitig mit Visual Studio 2012 - gibt es
dafür irgend welche Win10-Support-Addons? Mir wäre noch nichts
aufgefallen...
> Möglicherweise ist dein USB Treiber auch buggy. Versuch es einfach mal> mit einem anderen Adapter und damit Treiber.
Es ist der Standard-Windows-Treiber. Das INF-File macht nichts weiter,
als eine VID/PID festzulegen und dann per
ServiceBinary=%12%\usbser.sys
auf den Windows-eigenen Treiber zu verweisen.
Dr. Gurgel meint
youcan use vs2012 for, however ,if you want to make "universal apps"
which win 10 can run, then you should use vs2015..... but if you have
the option, you can get vs2015 anyways ( its free ). You can write
applications that run on win7 as well as the latest win10 – Keith
Nicholas Oct 6 '15 at 2:37
MS wird bestimmt einiges von W7 zu W10 verändert haben, nicht nur die
Farben der Oberfläche.
Georg G. schrieb:> MS wird bestimmt einiges von W7 zu W10 verändert haben, nicht nur die> Farben der Oberfläche.
Das ist sicher, nur welchen Einfluss könnte der Compiler haben, wenn die
API gleich geblieben ist (bzw. sein sollte)?
Die Einsprungpunkte bleiben gleich, die verwendeten Strukturen bleiben
gleich - was könnte ein VS2015-Compiler da noch anders machen?
Ich habe mit VS2015 mal fix angesehen, da gibt es beim Platform Toolset
lediglich die Möglichkeit, eine eigene Variante für "XP" auszuwählen -
eine Unterscheidung weiterer Windowsversionen gibt es allerdings
nicht...
Harstad schrieb:> die aktuellen Parameter der seriellen> Schnittstelle werden mit GetCommState() emittelt, setzt man dann exakt> die gleichen Parameter wieder mittels SetCommState(), verweigert Windows> diese als ungültig - klingt also nach einem Windows-Bug
Windows 10 verschärft an einigen Stellen das USB-Timing auf die Minima
in der Spec. Eventuell trifft Dich das hier - IIRC haben GetCommState()
und SetCommSate() Auswirkungen, es werden USB Kommandos verschickt und
empfangen.
Ich würde bei einem Fehler in den xxxCommState() Funktionen die serielle
Schnittstelle ganz zu machen und erst so 10-30 Sekunden später wieder
öffnen.
Ansonsten könnte man auch mit dem Microsoft Message Analyzer mal
nachsehen was auf dem USB wirklich passiert. Könnte ja sein, dass eins
der USB CDC Kommandos nicht korrekt implementiert ist - und altes
Windoof das ignoriert hat.
bluppdidupp schrieb:> Bei passenden Deskriptoren braucht man btw bei win10 keine eigene> *.inf> mehr für die usbser.sys:> https://msdn.microsoft.com/de-de/library/windows/h...
Klingt gut, beraubt einen aber der Möglichkeit, das eigene Gerät im
Devicemanager eindeutig zu identifizieren - die heißen dann halt alle
nur noch COMx und der Benutzer weiß nicht wirklich, was welches Gerät
ist.
Interessant aber zu lesen, das MS die usbser.sys tatsächlich komplett
neu geschrieben haben will :-/
So, inzwischen bin ich unter answers.microsoft.com fündig geworden: es
gibt im usbser.sys von Windows 10 tatsächlich ein ungelöstes Problem.
Betroffen sind auch sämtliche 3D-Drucker, wenn die Daten per USB
übertragen werden.
Den entsprechenden Thread hat Microsoft in diesem Forum irgendwann
einfach zu gemacht. Lösung? Fehlanzeige.
Deswegen: gibt es eventuell eine alternative (freie) Implementierung des
usbser.sys, auf die ich umsteigen könnte?
Harstad schrieb:> So, inzwischen bin ich unter answers.microsoft.com fündig geworden: es> gibt im usbser.sys von Windows 10 tatsächlich ein ungelöstes Problem.
Magst Du einen Link auf diese Information setzen?
Naja, das ist anderthalb Jahre alt.
Obendrein ist hier von einem Microsoft-Treiber die Rede, aber von
Geräten, die FTDI-UARTs verwenden (Arduino Mega).
Diese Kombination aber funktioniert - ich nutze FTDI-UARTs an mehreren
Windows-10-Rechnern, ohne Probleme. Auch im Zusammenhang mit einem
3d-Drucker. Das verwendete Windows 10 ist in der Zwischenzeit von 1511
auf das "Creator's Update" aktualisiert worden, mit den üblichen
Zwischenschritten.
Dieser "answers"-Thread stellt aufgrund der sehr unpräzisen
Problemschilderungen mehr Fragen als er beantwortet.
Microsoft schafft es hier anscheinend, sich an das technische Niveau des
Apple-Supports anzunähern ...
Harstad schrieb:> Klingt gut, beraubt einen aber der Möglichkeit, das eigene Gerät im> Devicemanager eindeutig zu identifizieren - die heißen dann halt alle> nur noch COMx und der Benutzer weiß nicht wirklich, was welches Gerät> ist.
Mittels "OS Descriptor" sollte auch das gehen:
https://wiki.kucia.net/doku.php?id=projects:winusb
...der Answers-Thread ist wirklich katastrophal ^^
Die Leute schreiben ja nicht einmal dabei, ob der MS-Treiber überhaupt
verwendet wird oder ein Fremdanbieter-Treiber ;D
>Then the USB fails with a code 43 "a request for the USB device descriptor
failed"
z.B. hört sich eher nach nicht standardkonformen Endgerät oder
schlechtem Kabel oder Controller-Problem an.
Ich kenne so ein Verhalten von meiner virtuellen Maschine und einem USB
to Serial Gerät.
Wenn ich in den Settings der VM USB3 einstelle, habe ich auch so ein
Verhalten.
Wenn ich USB2 einstelle, funktioniert alles wie gewohnt.
