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!
:
Verschoben durch User
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.
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/hardware/dn707976(v=vs.85).aspx
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?
Der längste Thread zu diesem Thema findet sich unter https://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_devices/windows-10-serial-usb-problems/438de66f-7294-4c06-b4fb-89b45d005ca0?page=2 Wenn man aber ein bisschen sucht, tauchen noch einige Postings mher auf, die das gleiche Problem beschreiben.
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 ...
Rufus Τ. F. schrieb: > Rufus Τ. F. schrieb: > Naja, das ist anderthalb Jahre alt. ...und das letzte Update des usbser.sys fand laut MS 2015 statt.
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.
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.