es geht darum mit Atmega32u4 (der USB hat) unter C mit Win 7 64bit einen Sensor auszulesen. Das Verhalten soll dabei ähnlich unkompliziert sein wie der FT232 auf Arduino nano3. als Beispiel für USB mit 32u4 nutze ich das Beispiel "USB Serial" von http://www.pjrc.com/teensy/index.html mit Dateien usb_serial.c, usb_serial.h, example.c, Makefile. Es gibt auch einen Win-Treiber serial_install.exe der sich mit Teensy meldet. Siehe das usb_serial.zip. Das Beispiel geht. Nur gibt es ein paar unschöne Sachen gegenüber der Lösung mit FT232 wo ich fragen möchte ob jemand eine Abhilfe kennt. bei FT232 macht der Standardtreiber CDM21218_Setup.exe keinen Installierstress. Beim Anstecken erscheint im Gerätemanager oben bei den Anschlüssen "USB Serial Port (COM6)". beim 32u4 mit Zadig 2.4 zur Treiberinstallation wurde USB erkannt. Nur dauerte die Installation ewig und es kamen Entschuldigungsmeldungen dass das 5min dauern könne (Netzwerk war keines dran). Am Ende brach das dann ab und der Rechner hängte, was mir bereits früher mit Zadig passierte. Beim Anstecken erscheint im Gerätemanager leider nicht ganz oben sondern schwer zu finden ganz unten unter "Universal Serial Bus devices" der Eintrag "USB Serial" leider ohne Angabe welcher Com-Port das nun ist. 3 Sachen stören mich: - die ewig lange Warterei mit Zadig 2.4 + das Hängen am Ende - der Eintrag ganz unten statt oben bei den Anschlüssen - die fehlende Angabe welcher COM das ist Frage: Gibt es Möglichkeiten möglichst nahe an das Verhalten mit dem FT232 zu kommen? Was muss ich dazu am Code ändern? Was läuft mit Zadig schief?
Hallo, was für ein Stress? Aber den Stress machst du und nicht Atmegea32u4 und USB-Serial Beispiel-Software von PJRC für Atmega32u4. Lass einfach das Programm "serial_install.exe" von PJRC laufen und gut is es. Dann hast du das Verhalten wie von FTDI. Vergiss ZADIG und Co. (der richtige CDC-Treiber für das Beispiel von PJRC mit Atmega32u4 ist usbser.sys) Gruss
Stefan schrieb: > Aber den Stress machst du geht das nicht auch ein wenig freundlicher? hier in diesem Forum wurde mir empfohlen Zadig zu verwenden. sich widersprechende Ratschläge und Überheblichkeit sind ungut. Fakt ist daß das Atmega2560-Board keinerlei Stress macht und dabei als USB ein Atmega16u2 verbaut ist. Als Treiber ist da ein inf-file nutzbar.
Matthias W. schrieb: > Fakt ist daß das Atmega2560-Board keinerlei Stress macht und dabei als > USB ein Atmega16u2 verbaut ist. Als Treiber ist da ein inf-file nutzbar. Den Stress macht eigentlich Wixdos10! Denn das ist, was unsignierte *.inf selbst dann nicht (dauerhaft) akzeptiert, wenn sie nur systemeigene Treiber auf eine neues Gerät anwenden. Zadig macht im Prinzip nichts anderes, als so eine *.inf zu generieren und zu signieren, damit Wixdos10 zufrieden ist. Aber natürlich muss man Zadig mit den richtigen Informationen füttern, damit es die korrekte *.inf generiert. Und das liegt beim Benutzer und dessen Kompetenz. Die dir wohl fehlt...
Matthias W. schrieb: > hier in diesem Forum wurde mir empfohlen Zadig zu verwenden. Zadig wird in aller Regel nur verwendet um LibUsb oder WinUsb an ein Device zu binden was keiner der üblichen Klassen entspricht. In allen anderen Fällen ist Zadig eher kontraproduktiv. Wenn den Device der CDC Klasse entspricht ist in aller Regel nur eine inf (bis Win7) notwendig Unter W10 ist auch diese nicht mehr notwendig. W10 ordnet so einem Device direkt usbser.sys zu. Das funktioniert inzwischen ziemlich problemlos solange in der FW die relevanten CDC Requests eingebaut sind, und so ein Device taucht dann unter den COM Ports im Geräte Manager auf. Wenn eine gültige Seriennummer eingebaut ist auch immer unter der gleiche Comportnummer (beim gleichen PC)
Thomas Z. schrieb: > Wenn den Device der CDC Klasse entspricht ist in aller Regel nur eine > inf (bis Win7) notwendig Unter W10 ist auch diese nicht mehr notwendig. > W10 ordnet so einem Device direkt usbser.sys zu. So die holde Theorie. Die Praxis sieht leider anders aus. Wixdos10 akzeptiert leider längst nicht alles, was CDC-konform ist (und deshalb tatsächlich auch problemlos mit usbser.sys läuft). Erst die Nachhilfe mit Zadig sorgt dafür, dass der Kram läuft.
c-hater schrieb: > So die holde Theorie. Die Praxis sieht leider anders aus. Das entspricht nicht den Erfahrungen die ich mache (auf diversen Plattformen) Wenn die Deskriptoren passen habe ich noch keine Ausfälle erlebt. Selbst ohne IAD was für CDC eigentlich mantory ist wird usbser.sys geladen. (W10, ACM) Es ist allerdings immer ein zus. Interrupt EP notwendig dar keinerlei Funktion hat.
c-hater schrieb: > natürlich muss man Zadig mit den richtigen Informationen füttern, > damit es die korrekte *.inf generiert. vielleicht kannst/willst Du dazu ein paar Hinweise geben.
Thomas Z. schrieb: > Wenn den Device der CDC Klasse entspricht ist in aller Regel nur eine > inf (bis Win7) notwendig Danke für den Hinweis Thomas. Eine passende inf-Lösung wäre mir am liebsten. So wie beim mega2560-Board. Dazu passend sah ich hex-Dateien für den 16u2. Nur habe ich ja einen 32u4. Es wäre da wohl ein C-Quellcode davon nötig um diesen für den 32u4 anzupassen.
Matthias W. schrieb: > vielleicht kannst/willst Du dazu ein paar Hinweise geben. Die wurden dir schon von jemand anders gegeben, hier: Beitrag "Re: FT232 ähnliches USB mit atmega32u4 unter C" Wenn auch nicht sehr auffällig, eigentlich wollte der Mann wohl "seine" Lösung propagieren, aber im Kern enthält sie aber doch den Knackpunkt. Die Sache in den Klammern...
c-hater schrieb: > und deshalb tatsächlich auch problemlos mit usbser.sys läuft wenn ein gelbes Rufzeichen da ist und daher der Treiber fehlt so kann man den ja suchen lassen und dazu ein Verzeichnis angeben. Nur muss darin dann wohl ein passendes inf zu finden sein? Alleine usbser.sys wird bei Win 7 64bit wohl nicht reichen.
c-hater schrieb: > Die wurden dir schon von jemand anders gegeben Du meinst ich soll "serial_install.exe" nehmen, fertig?
Matthias W. schrieb: > c-hater schrieb: >> und deshalb tatsächlich auch problemlos mit usbser.sys läuft > > wenn ein gelbes Rufzeichen da ist und daher der Treiber fehlt so kann > man den ja suchen lassen und dazu ein Verzeichnis angeben. Nur muss > darin dann wohl ein passendes inf zu finden sein? Alleine usbser.sys > wird bei Win 7 64bit wohl nicht reichen. Du Idiot solltest lesen lernen. Natürlich reicht usbser.sys alleine nicht. Man braucht auch eine *.inf (unter Windows7 sogar zwingend und in jedem Fall, bei Wixdos10 nur unter bestimmten Umständen, warum auch immer) Der Vorteil von Win7 ist: das ist auch mit einer nicht signierten *.inf zufrieden. Dazu brauch man sowas wie Zadig nicht, das kann man mit Notepad selber schreiben. (bzw. sinnvoller: eine entsprechende Vorlage entsprechend des USB-Target abändern).
Matthias W. schrieb: > c-hater schrieb: >> Die wurden dir schon von jemand anders gegeben > > Du meinst ich soll "serial_install.exe" nehmen, fertig? Stand das in Klammer? Nö. Sprich: du kannst oder willst nicht lesen! Merkbefreit.
Matthias W. schrieb: > wenn ein gelbes Rufzeichen da ist und daher der Treiber fehlt so kann > man den ja suchen lassen und dazu ein Verzeichnis angeben. Nur muss > darin dann wohl ein passendes inf zu finden sein? Alleine usbser.sys > wird bei Win 7 64bit wohl nicht reichen. Ja klar neben usbser.sys brauchst du auch die passende inf Datei. Dort legst du fest auf welche vid/pid usbser.sys angebunden wird. Die inf Datei schreibst du selbst dann geht zumindst eine manuelle Installation. Ob du die hex datei einfach auf einer anderen MCU benutzen kannst, kann ich nicht sagen. Das geht vermutlich nicht.
c-hater schrieb: > Sprich: du kannst oder willst nicht lesen! Merkbefreit. vielleicht kannst Du Deine Agressionen mäßigen. Auch ohne solche Anfälle ist es sicher möglich das Nötige zu klären.
c-hater schrieb: > Man braucht auch eine *.inf (unter Windows7 sogar zwingend... ok. Also doch. Und wo nehme ich die nun her? Gibt es dazu ein für Laien verständliches Tutorial, einen Leitfaden, ein einfach versteh- und abwandelbares Beispiel? Ich bin ja gerne bereit das auszuprobieren wenn es nicht das Win 7 dabei zerschießt.
Matthias W. schrieb: > c-hater schrieb: >> Sprich: du kannst oder willst nicht lesen! Merkbefreit. > > vielleicht kannst Du Deine Agressionen mäßigen. Auch ohne solche Anfälle > ist es sicher möglich das Nötige zu klären. Könntest du anfangen zu LESEN? Dann gäbe es den Anlass für solche Aggressionen einfach nicht mehr. Dann würde man vielmehr denken, dass der eigene Aufwand irgendwas gebracht hat, dass man tatsächlich geholfen hat.
Thomas Z. schrieb: > Dort > legst du fest auf welche vid/pid usbser.sys angebunden wird. Die inf > Datei schreibst du selbst dann geht zumindst eine manuelle Installation. Danke Thomas. Du bist da der USB-Fachmann, ich der Laie. Was ich habe ist das inf-File das beim atmega2560 dabei war. Vielleicht lässt sich das brauchbar an meine Anwendung anpassen? Was meinst Du?
c-hater schrieb: > Könntest du anfangen zu LESEN? ich lese die ganze Zeit aufmerksam was Du schreibst.
Matthias W. schrieb: > Was ich habe > ist das inf-File das beim atmega2560 dabei war. Vielleicht lässt sich > das brauchbar an meine Anwendung anpassen? Was meinst Du? nun ja ich kenne weder dein inf file noch die Deskriptoren. Stell die halt mal ein und dazu den Output von UsbTreeView als txt
Thomas Z. schrieb: > Ob du die hex datei einfach auf einer anderen MCU benutzen kannst, kann > ich nicht sagen. Das geht vermutlich nicht. die hex-Dateien von Github für den 16u2 gehen wohl nicht ohne weiteres für den 32u4. Deswegen wäre ein dokumentierter C-Quellcode als Basis nützlich, den man dann anpassen könnte. das hex disassemblieren, analysieren und ändern ist nicht das was ich da vorhatte.
Matthias W. schrieb: > c-hater schrieb: >> Man braucht auch eine *.inf (unter Windows7 sogar zwingend... > > ok. Also doch. Wieder so ein Ding: Du hast nicht erwähnt, dass die Sache sich unter Windows7 abspielt. Wieder eine blanke Verhöhnung aller Hilfswilligen mit eine Arroganz, die durch was eigentlich berechtigt ist? Kompetenz kann es nicht sein... > Und wo nehme ich die nun her? Es gibt sicher Tausende, wenn nicht Millionen mögliche Quellen. Nicht zuletzt wohl das Zielsystem, also deine eigene Windows7-Installation. Was hindert dich z.B. daran, C:\Windows\inf nach Dateien zu durchsuchen, die *.inf heißen und "usbser.sys" irgendwo im Inhalt haben?
Thomas Z. schrieb: > kenne weder dein inf file hier die Inf-Dateien und cat-Dateien aus dem Verzeichnis wo Win 7 den passenden Treiber für den 16u2 fand.
c-hater schrieb: > Wieder so ein Ding: Du hast nicht erwähnt, dass die Sache sich unter > Windows7 abspielt. natürlich. Lies doch bitte, oben steht: "unter C mit Win 7 64bit..." > Wieder eine blanke Verhöhnung aller Hilfswilligen mit > eine Arroganz, die durch was eigentlich berechtigt ist? warum diese Unterstellungen? wem nützt das?
c-hater schrieb: > Was hindert dich z.B. daran, C:\Windows\inf nach Dateien zu durchsuchen, > die *.inf heißen und "usbser.sys" irgendwo im Inhalt haben? niemand. Frage danach und ich mache es ! die inf. sind im zip zu finden.
Thomas Z. schrieb: > den Output von UsbTreeView was meinst Du damit. UsbTreeView ist keines installiert, ich kenne das Programm bisher nicht. Die Konfiguration die PJRC nutzt müsste doch aus der C-Datei usb_serial.c im obigen zip zu ersehen sein?
hier das usb_serial.c mit den Eintragungen von PJRC für das Teensy-Beispiel.
Matthias W. schrieb: > UsbTreeView ist keines installiert, man kann es sein dass du etwas kompliziert bist. UsbTreeView kann man mit google finden das braucht auch keine Installation und zeigt an was für Deskriptoren dein Device so hat. In der gezeigten inf habe ich z.B keine Einträge für PID_047A gefunden. Diese ist aber in denem usb_serial angegeben.
1 | #define VENDOR_ID 0x16C0
|
2 | #define PRODUCT_ID 0x047A
|
hier nun die Ergebnisse mit USBTreeView bei atmega2560 und bei 32u4.
Thomas Z. schrieb: > In der gezeigten inf habe ich z.B keine Einträge für PID_047A gefunden. > Diese ist aber in denem usb_serial angegeben. das inf. ist für den mega2560 gedacht und usb_serial war für den Teensy.
hier der Text mit Copy&Paste den USBTreeView liefert beim 2560 und beim 32u4. beim 2560 steht: Vendor ID 0x2341 Product ID 0x0042 USB 1.1 Friendly Name Arduino Mega 2560 (COM7) beim 32u4 steht: Vendor ID 0x16C0 (Van Ooijen Technische Information) Product ID 0x047A USB 2.0 -> wrong, Device is full speed only einen Friendly Name gibt es da nicht. Daher fehlt wohl die Angabe (COMx)
Es wäre denkbar in usb_serial.c die Vendor ID 0x16C0 und Product ID 0x047A zu ändern in Vendor ID 0x2341 und Product ID 0x0042. macht das denn Sinn? liefe das dann mit dem anderen inf? oder gibt das neue Probleme? es wäre auch möglich anstelle des offenbar falschen Eintrags USB2 dort USB1.1 einzutragen. Macht das denn Sinn? PJRC wird sich doch etwas gedacht haben? und wie bekommt man den "Friendly name" hinein?
> system32\DRIVERS\WinUSB.sys (Version: 6.1.7601.17514 Date: 2010-11-21) sagt mir dass mit Zadig WinUsb zugewiesen wurde, mach das rückgängig. > USB 2.0 -> wrong, Device is full speed only das ist nicht problematisch, wenn auch unschön. Dir fehlt einfach noch ein passendes inf. Es gibt hier im Forum ein inf von W.S. das du anpassen kannst. Finde das im Moment aber nicht. Ev hat Stefanus einen link. Das arduino inf würde ich nicht ändern weil sonst die cat Datei invalide wird.
Thomas Z. schrieb: > man kann es sein dass du etwas kompliziert bist. für Dich ist das alles selbstverständlich, für mich Neuland. Sorry ! natürlich habe ich es dann gefunden und angesehen.
Thomas Z. schrieb: > sagt mir dass mit Zadig WinUsb zugewiesen wurde, mach das rückgängig. kannst Du mir einen Hinweis geben wie das rückgängig zu machen ist? Windows merkt sich ja vieles. Manches wird man nicht mehr leicht los weil das im System irgendwo eingetragen wurde.
Matthias W. schrieb: > kannst Du mir einen Hinweis geben wie das rückgängig zu machen ist? Zadig starten und dort uninstall für das Device wählen.
Matthias W. schrieb: > kannst Du mir einen Hinweis geben wie das rückgängig zu machen ist? Du meinst auf "USB Serial" klicken und deinstallieren? "Die Treibersoftware für dieses System löschen." Windows merkt sich das meines Wissens trotzdem noch irgendwo.
Thomas Z. schrieb: > Zadig starten und dort uninstall für das Device wählen. Zadig 2.4 ist gestartet. In der Zeile steht "USB Serial". Darunter ist der Treiber angegeben. In den Menüpunkten oben sehe ich kein uninstall. Unten auch nicht. Auf dem großen Button steht "Reinstall Driver". Als weitere Optionen sehe ich nur "Install Driver", "Install WCID Driver" und "Extract Files". Wie werde ich das wieder los?
Matthias W. schrieb: > Windows merkt sich das meines Wissens trotzdem noch irgendwo. naja das geht auch im Gerätemanager (ausgeblendete Geräte ein) und abgestecktem Device. Im Prinzip musst du irgendwie die pnf Datei im Win Ordner löschen (oem20.pnf in deinem Fall). Das bewirkt dass der Treiber Dialog beim Anstecken neu startet. UsbTreeView sagt ja dass oem20.inf benutzt wird die löschst du am besten auch. Du kanst auch in der Registry rumfummeln das ist aber bei deinem Stand gefährlich.
Thomas Z. schrieb: > Dir fehlt einfach noch ein passendes inf. ok. > Es gibt hier im Forum ein inf von W.S. das du anpassen kannst. Finde das > im Moment aber nicht. Ev hat Stefanus einen link. vielleicht meldet er sich ja. > Das arduino inf würde ich nicht ändern weil sonst die cat Datei invalide > wird. ok. Dann besser lassen.
Thomas Z. schrieb: > die pnf Datei im Win Ordner löschen (oem20.pnf) > oem20.inf löschst du am besten auch. gemacht. > Du kanst auch in der Registry rumfummeln das ist aber bei deinem Stand > gefährlich. das hatte ich auch schon mal gemacht. Für den Pfad bei WinAVR.
Thomas Z. schrieb: > Das bewirkt dass der Treiber Dialog beim Anstecken neu startet. die beiden Dateien sind nicht mehr zu sehen. Der Treiber-Dialog startet trotzdem nicht und es gibt auch kein gelbes Rufzeichen. Er hat also noch einen Treiber. Ein oem20.cat ist noch da. nun habe ich den Treiber gelöscht. Es erscheint nun wieder oben "USB Serial" mit gelbem Rufzeichen. Ein neuer Treiber könnte versucht werden falls er nicht wieder den alten nimmt den er noch kennt.
Etwas Grundlagen: für eine Treiber Installation braucht es immer eine sys und eine inf. Zusätzlich ev noch cat für Zertifizierungen. Win baut dann noch die pnf damit das laden später schneller geht. Diese pnf ist auch die Ursache warum es schwer ist sowas wieder los zu werden. (deine Reste) Ich hab die inf gefunden das kannst du als Basis benutzen Beitrag "Re: STM32F103 USB CDC von W.S."
:
Bearbeitet durch User
Ich hatte auch mal den Fehler gemacht zadig zu installieren. Die Systemwiederherstellung war die Rettung.
Thomas Z. schrieb: > Diese pnf ist auch die Ursache > warum es schwer ist sowas wieder los zu werden. (deine Reste) danke für diese Hinweise. > Ich hab die inf gefunden das kannst du als Basis benutzen prima. es gibt offenbar Änderungsbedarf daran wie ich las. "CopyINF=win7-driver.inf" "Die VID/PID lautet 0x0416 / 0x5011 und wird an mehreren Stellen in der INF Datei verwendet." ist die Frage ob ich diese VID/PID dann in den Quelltext von PJRC übernehme. Oder ich übernehme diese Infos von PJRC und schreibe dieselben VID/PID dann in die Inf-Datei. Was meinst Du macht da Sinn?
du trägst einfach deine VID/PID aus der usbserial.c überall in die inf ein und vergibst sinnvollerweise auch eigene Namen. Es ist auch sinnvoll einen anderen Namen für die inf Datei selbst zu setzen.
Matthias W. schrieb: > es geht darum mit Atmega32u4 (der USB hat) unter C mit Win 7 64bit einen > Sensor auszulesen. Würde man heutzutage eher via USB HID denn als serial Port machen - deutlich unkomplizierter. Insbesondere wenn es ein Sensor mit <1000Hz Abtastrate ist. Die App macht man dann mit HIDAPI: https://github.com/libusb/hidapi Serielle Treiber unter Windoof sind Kacke, denn man muss dann umständlich den COM Port rauspfremeln, und Bluetooth Classic COM Ports beissen sich mit "echten" in Windows 7 und Windows 10.
Jim M. schrieb: > Serielle Treiber unter Windoof sind Kacke, denn man muss dann > umständlich den COM Port rauspfremeln Danke Jim für die Hinweise. Erst möchte ich nun sehen wie das mit dem Inf geht um zu lernen. Wenn das klappt schaue ich das andere an.
Thomas Z. schrieb: > du trägst einfach deine VID/PID aus der usbserial.c überall in die inf > ein und vergibst sinnvollerweise auch eigene Namen. Es ist auch sinnvoll > einen anderen Namen für die inf Datei selbst zu setzen. das habe ich gemacht. Ist das so ok aus Deiner Sicht?
im Verzeichnis der Treiber die ich für atmega2560 nutzte sind Dateien arduino.inf, arduino-org.inf, genuino.inf, wobei mir nicht klar ist wie Windows da die richtige Datei wählt, denn Einträge zu mega2560rev3.name="Arduino Mega 2560" bzw. "mega2560rev3.name="Genuino Mega 2560" finden sich in allen 3 Dateien. Zu jeder dieser .inf gibt es auch eine .cat. In der Datei arduino_gemma.inf wird auf die Dateien libusb0.dll, libusb0_x86.dll verwiesen. In 3 Unterordnern amd64, ia64, x86 liegen libusb0.dll, libusb0.sys, libusb0_x86.dll.
in der Arduino.inf sind neben atmega2560 auch Einträge für leonardo, lilypadUSB, unoR3 usw. Leonardo ist ja ein 32u4. Das könnte daher nützlich sein. es wird unterschieden zwischen: leonardo.bootloader.name="Arduino Leonardo bootloader" leonardo.sketch.name="Arduino Leonardo" das obere ist der Eintrag für den Bootloader zum Laden eines Programms, in den man kommt nach Reset. das untere ist der Eintrag für das User-Programm (sketch). im inf sollten daher beide Einträge sein. es gibt auch diese beiden Zeilen mit VID und PID: %leonardo.bootloader.name%=DriverInstall, USB\VID_2341&PID_0036 %leonardo.sketch.name%=DriverInstall, USB\VID_2341&PID_8036&MI_00 beim unteren Eintrag für das Laufenlassen des Sketch steht hinten nach PID noch ein MI_00 dabei. es sind 3 Device-Listen aufgeführt die ähnlich aussehen: [DeviceList] [DeviceList.NTamd64] [DeviceList.NTia64]
wenn man den USBTreeView anschaut beim atmega2560 so steht da: Vendor ID : 0x2341 (Arduino SA) Product ID : 0x0042 Friendly Name : Arduino Mega 2560 (COM7) COM-Port : COM7 (\Device\USBSER000) deswegen wird auch COM7 in Klammern angezeigt. im Vergleich dazu zeigte USBTreeView beim 32u4 nach Zadek-Arbeit: Vendor ID : 0x16C0 (Van Ooijen Technische Informatica) Product ID : 0x047A also keine Angabe zu Friendly Name und COM-Port. Daher wohl das Problem.
Jim M. schrieb: > deutlich unkomplizierter. Insbesondere wenn es ein Sensor mit <1000Hz > Abtastrate ist. das wäre beim CO2-Sensor der Fall. Unkompliziert klingt gut. Gibt es für die Vorgehensweise ein empfehlenswertes Tutorial?
:
Bearbeitet durch User
nun um ehrlich zu sein ich kenn mich mit dem Arduino Zeug und Atmel nicht sonderlich aus. Die MI_XX Einträge werden bei Compound Devices verwendet. Das sind Usb Devices bei denen die Funktion(en) nicht auf Device Ebene zugeordnet werden sondern auf Interface Ebene. Sowas setzt eine entsprechende FW vorraus. Die Sache mit COM7 verstehe ich ehrlich gesagt nicht, da nach meiner Erfahrung die Com Portnummer von Windows bei der Installation generiert wird. Die cat Dateien sind Zertifizierungen die ab W8.1 zwingend für die Installation sind. Mir ist auch klar dass das sich alles ziemlich kompliziert anhört, aber Treiber unter Win war noch nie ganz einfach. Die entsprechenden Dokus sind verstreut im DDK zu finden. Keine einfache Kost. Die inf Datei habe ich mir angesehen, ich würde sagen probiers aus.
1 | -------------- CDC Interface Descriptor --------------- |
2 | bFunctionLength : 0x04 (4 bytes) |
3 | bDescriptorType : 0x24 (Interface) |
4 | bDescriptorSubType : 0x02 (Abstract Control Management Functional Descriptor) |
5 | bmCapabilities : 0x06 |
6 | D7..4 : 0x00 (Reserved) |
7 | D3 : 0x00 (not supports the notification Network_Connection) |
8 | D2 : 0x01 (supports the request Send_Break) |
9 | D1 : 0x01 (supports the request combination of Set_Line_Coding, Set_Control_Line_State, Get_Line_Coding, and the notification Serial_State) |
10 | D0 : 0x00 (not supports the request combination of Set_Comm_Feature, Clear_Comm_Feature, and Get_Comm_Feature) |
11 | Data (HexDump) : 04 24 02 06 .$.. |
ich hab mir dein Descriptor Output noch mal angeschaut. Da ist Bit 2 im bmCapabilities gesetzt (break support). Keine Ahnung ob ein AVR das kann und was dafür für Requests in der FW notwendig sind. Gefunden habe ich in usb_serial.c auf die schnelle nichts. Der Error bei Device Qualifier Descriptor würde verschwinden wenn die USB Version auf 1.1 gestellt wird. Das ist aber nicht notwendig da der Request ja korrekt abgelehnt wird.
Kernel Taliban schrieb: > Wieso muss man mit Windows so viel frickeln? mir wäre auch lieber wenn das so einfach ginge, dass man als Laie das auch verstehen kann ! leider ist es nicht so.
Kernel Taliban schrieb: > Wieso muss man mit Windows so viel frickeln? Weil Microsoft und Hardware-Nahe Programmierung zwei Welten sind, die noch nie zusammen gehörten. Microsoft hat alles immer nur dazu gekauft und irgendwie ins DOS/Windows hinein gefrickelt. Wenn Microsoft etwas ändert, dann sind das Kacheln, runde Ecken, durchsichtige Fenster und noch nervigere Updates. In der Linux Welt diskutieren und probieren ganze Entwicklerteams jahrelang, wie man gewisse Altlasten loswerden kann. Dafür wird Linux oft ins lächerliche gezogen. Aber am Ende ziehen sie es durch und es funktioniert.
Thomas Z. schrieb: > Der Error bei Device Qualifier Descriptor würde verschwinden wenn die > USB Version auf 1.1 gestellt wird. kannst Du mir sagen wo das umstellen kann?
Thomas Z. schrieb: > Die inf Datei habe ich mir angesehen, ich würde sagen probiers aus. es funktioniert. Immerhin meldet sich nun das Gerät und ein COM steht auch dabei. wenn man wüsste wie das mit cat zu machen ist könnte man auch das versuchen. leider gab es Stress beim Versuch eine Verbindung mit hterm zu dem angezeigten COM herzustellen. Mal klappte es bei meiner Softwarevariante und dann wieder 10x nicht. Manchmal findet Hterm den angezeigten COM nicht. Mit dem FT232 hatte ich nie so viel Stress.
unschön ist dass sich der 32u4 nun als COM8 meldet. Was ist mit den ganzen COMs dazwischen? Offenbar merkt sich Windows all das. Wie wird man das Gemerke nur wieder los?
Stefan ⛄ F. schrieb: > Aber am Ende ziehen sie es durch und es funktioniert. das hört sich ja gut an.
Thomas Z. schrieb: > Da ist Bit 2 im bmCapabilities gesetzt (break support). Danke für den Hinweis. Keine Ahnung ob das eine Bedeutung für meine Anwendung hat.
Matthias W. schrieb: > beim 32u4 mit Zadig 2.4 zur Treiberinstallation Matthias W. schrieb: > hier in diesem Forum wurde mir empfohlen Zadig zu verwenden. Also, Zadig ist - mal einfach gesagt - eine Möglichkeit, einen Treiber gegen den Willen des OS in selbiges hineinzuprügeln. Wenn so etwas nicht zwingend erforderlich ist, dann verzichte lieber darauf, derartige Holzhämmer zu verwenden. Und nochwas: das an den USB gesteckte Gerät sagt dem PC beim Enumerieren, was es ist und damit, was für einen Treiber es benötigt. Das alles steckt in den Konfigurationsdaten im Treiber des Gerätes. Wenn du das entsprechend änderst, dann kann dein Gerät auch ohne halsbrecherische Installation am PC gut funktionieren, meine Virtual COM Ports auf verschiedenen µC, die sich alle mit 'Nuvoton' anmelden, machen das vor. Und das seit Jahren. Beispielsweise. W.S.
Stefan ⛄ F. schrieb: > In der Linux Welt diskutieren und probieren ganze Entwicklerteams > jahrelang, wie man gewisse Altlasten loswerden kann. Nanana. In der Linux-Welt diskutieren die Leute eher, wie man obsolete Software-Altlasten behalten kann. So herum. Nur bei der Hardware ist man so unflexibel, daß da am liebsten alles, was älter ist als 2 Jahre, nicht mehr unterstützt wird. Siehe den Thread über 'horizon'. W.S.
W.S. schrieb: > das an den USB gesteckte Gerät sagt dem PC beim > Enumerieren, was es ist und damit, was für einen Treiber es benötigt. > Das alles steckt in den Konfigurationsdaten im Treiber des Gerätes. Du meinst die Einträge in der usb_serial.c? > Wenn du das entsprechend änderst, dann kann dein Gerät auch ohne > halsbrecherische Installation am PC gut funktionieren, die Einträge habe ich leicht geändert, so dass sich das Gerät nun mit USB-CO2 meldet. > meine Virtual COM > Ports auf verschiedenen µC, die sich alle mit 'Nuvoton' anmelden, machen > das vor. Und das seit Jahren. Beispielsweise. prima. Ein Problem sehe ich ggf. wenn man verschiedene Sensoren nutzen will und dazu keine anderen VID/PID dazu hat.
Matthias W. schrieb: > kannst Du mir sagen wo das umstellen kann?
1 | ...
|
2 | 0x10, 0x01, // bcdUSB auf usb1.1 umstellen |
3 | ...
|
Das Erstellen der cat files ist im DDK (Driver Development Kit) beschrieben. W7 und W8? erlauben noch selfsigned. Seit W10 muss das eine zertifizierte Stelle gegen Geld machen. Das dein COM Port die Nr 8 bekommt war zu erwarten. COM7 ist durch deinen Arduino belegt, Windows nimmt dann die nächste noch unbelegte Nummer. Wenn beide Ports aus der Registry entfernt sind wird dein Device bei COM3 angelegt. Da Win den Comport anlegt sind die Descriptoren prinzipiell richtig. Wenn du also Probleme mit hterm hast, kann das daran liegen dass Class Requests nicht korrekt arbeiten. Ich würde mal das Bit für den BreakSupport auf 0 setzen. Ansonsten kannst du dein Device auch mal gegen usb2cv bzw usb3cv von usb.org testen. Dort gibts auch Test Routinen für CDC. Die Tools sind allerdings etwas hakelig.
:
Bearbeitet durch User
Thomas Z. schrieb: > Das Erstellen der cat files ist im DDK (Driver Development Kit) > beschrieben. W7 und W8? erlauben noch selfsigned. Seit W10 muss das eine > zertifizierte Stelle gegen Geld machen. danke für den Hinweis Thomas. > Wenn beide Ports aus der Registry entfernt sind wird dein Device bei > COM3 angelegt. wonach soll ich in der Registry suchen? Hast Du ein Beispiel wie das aussieht und was ich da ändern soll. > Wenn du also Probleme mit hterm hast, kann das daran liegen dass Class > Requests nicht korrekt arbeiten. Ich würde mal das Bit für den > BreakSupport auf 0 setzen. ok. als Baudrate für hterm sollte doch passen was im Gerätemanager eingetragen ist. es ging besser als ich noch eine DTR-Abfrage eingebaut habe die PJRC in einem Beispiel nutzte. Jedenfalls kommt nun das erste Zeichen was ich schickte.
Matthias W. schrieb: > wonach soll ich in der Registry suchen? > Hast Du ein Beispiel wie das aussieht und was ich da ändern soll. unter Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB sind alle VID/PID Combos aufgeführt dort musst du die beiden Einträge für deine beiden CDC devices löschen. Die devices sollten da nicht angesteckt sein. Danach bekommst du beim Anstecken wieder den Treiber Dialog und danach sollte dein Device unter COM3 verfügbar sein. > als Baudrate für hterm sollte doch passen was im Gerätemanager > eingetragen ist. So wie den C Code lese gibt es keinerlei Funktionen um die Baudrate weiter zu verarbeiten. Der VCP ist rein virtuell und nicht mit einem UART verbunden. Insofern hinkt der Vergleich zu einem FTDI etwas der ja einen UART bereitstellt.
:
Bearbeitet durch User
Thomas Z. schrieb: > So wie den C Code lese gibt es keinerlei Funktionen um die Baudrate > weiter zu verarbeiten. Der VCP ist rein virtuell und nicht mit einem > UART verbunden. ja. Im C-Code für das Senden von Bytes über USB ist keine Geschwindigkeitseinstellung vorgesehen. Man kann theoretisch also in einer Schleife maximal schnell senden. nur muss das ja das Terminalprogramm dann auch empfangen können. Und dazu muss man hterm ja eine Baudrate vorgeben. Und diese Baudrate muss wohl zu dem passen was im PC bei USB-Serial dann eingetragen ist.
leider hat das 32u4-Board einen 5V-Spannungsregler und ist daher nicht einfach per Jumper auf 3.3V umstellbar. So muss ich den Pegel anpassen für die 3.3V des RS232-CO2-Sensors.
Matthias W. schrieb: > nur muss das ja das Terminalprogramm dann auch empfangen können. Und > dazu muss man hterm ja eine Baudrate vorgeben. Und diese Baudrate muss > wohl zu dem passen was im PC bei USB-Serial dann eingetragen ist. Das kann ich nicht nachvollziehen. Das Terminalprogramm empfängt die Zeichen immer so schnell, wie sie herein kommen. Es hat keine eingebaute Bremse, die nur eine bestimmte Baudrate zulässt. Bei einem CDC Device hat die Baudrate nach meinem Kenntnisstand überhaupt keine Funktion. Die tatsächliche Übertragungsrate wird nur vom USB Stack und den Programmen begrenzt. Wenn ein Puffer voll läuft, gehen je nach Implementierung entweder Zeichen verloren oder die Übertragung stoppt. Du kannst das gerne mit der Implementierung von ST (in Cube MX) oder W.S (verbesserte Version: http://stefanfrings.de/stm32/stm32f1.html#vcpnohal) ausprobieren. Die Baudrate ist jedoch bei USB-UART Adaptern relevant um die Übertragungsrate der UART Schnittstelle zu konfigurieren.
Stefan ⛄ F. schrieb: > Bei einem CDC Device hat die Baudrate nach meinem Kenntnisstand > überhaupt keine Funktion. Du meinst es ist dann vollkommen egal was im Gerätemanager im Feld Baudrate dann eingetragen ist?
Matthias W. schrieb: > Du meinst es ist dann vollkommen egal was im Gerätemanager im Feld > Baudrate dann eingetragen ist? Ja.
Stefan ⛄ F. schrieb: > Die tatsächliche Übertragungsrate wird nur vom > USB Stack und den Programmen begrenzt. auffallend war bisher daß beim Anstecken im Gerätemanager stets zuverlässig der Eintrag USB-CO2, der über die inf-Datei erreicht wurde erschien. das Verbinden damit über hterm gelang oft nicht. Es konnte passieren dass nach Aufruf von Hterm und klicken auf "R" kein COM8 angezeigt wurde. Daher konnte man sich auch nicht damit verbinden. erst nach Abstecken und Neuanstecken des Moduls war ein neuer Versuch sinnvoll.
Wenn du USB Gerät trennst während sein COM Port in einem Programm geöffnet ist, dann blockiert der COM Port so lange, bis er geschlossen wird. Bis dahin kann er auch durch aus/ein-Stecken nicht neu erstellt werden.
Stefan ⛄ F. schrieb: > Matthias W. schrieb: >> Du meinst es ist dann vollkommen egal was im Gerätemanager im Feld >> Baudrate dann eingetragen ist? > > Ja. genauso ist es jedes mal wenn du in Hterm die Baudrate (oder Bits/Parity) änderst löst das auf dem USB einen ClassRequest aus ( CDC_SET_LINE_CODING). Dieser wird von usb_serial.c zwar angenommen und in cdc_line_coding gespeichert. macht aber sonst nichts. An der Stelle müsste man z.b eingreifen wenn nur bestimmte Baudraten, die z.B der AVR beherscht, erlauben wollte. Alle anderen Baudraten wurden dann mit einem STALL beendet, was dann in HTERM eine Fehlermeldung auslösen würde, dass sich die Baudrate nicht ändern lässt. Hier in diesem Beispiel sind einfach alle Settings erlaubt.
Stefan ⛄ F. schrieb: > dann blockiert der COM Port so lange, bis er geschlossen > wird. Danke für den Hinweis Stefan. Wie soll ein normaler User der so ein Modul nutzt mit all den Problemen klarkommen die da auftreten können? Wie einfach waren die Dinge früher als ich meine GPIB-Geräte zusammensteckte und unter HPBASIC ansprechen konnte im Vergleich dazu !
Matthias W. schrieb: > Wie soll ein normaler User der so ein Modul nutzt mit all den Problemen > klarkommen die da auftreten können? Dafür kann das Modul nichts. Es ist eine Eigenart von Windows, die alle File-Handles betrifft. Sozusagen einer der zahlreichen unnötigen Egotrips von Microsoft. Sie machen es anders, weil man kann. Nicht weil es für irgend wen gut ist.
Stefan ⛄ F. schrieb: > Dafür kann das Modul nichts. ja. Der User ist halt genervt und lässt seinen Frust dann ggf. am Lieferanten des Moduls aus. Wem ist damit genützt? Danke für Eure Hinweise !
Matthias W. schrieb: > Wie soll ein normaler User der so ein Modul nutzt mit all den Problemen > klarkommen die da auftreten können? welches Modul. Du hast hier ein USB Device mit einer halb fertigen FW. Da gibts eben Einschränkungen. Es gibt ja nicht ohne Grund fertige Bausteine z.B von FTDI. Die Fa. hat dann die Vorarbeiten was Treiber und HW angeht für dich schon gemacht. Dann funktioniert das aus Applikationssicht problemlos. Wie gesagt teste dein Device mal gegen usb2cv. Du wirst verwundert sein was da an Warnmeldungen und Fehlermelungen kommen werden. Spätestens wenn du 2 dieser Module mit der gleichen FW betreibst wird es sowieso knallen da beide dann die gleiche SN haben ->"12345". Ein weiteres Problem ist der fehlende IAD Deskriptor der eigentlich bei VCP vorgeschrieben ist. Auch wenn das noch funktioniert kann niemand sagen wie lange sowas noch funktioniert. IAD ist bei MS seit XP SP3 implementiert. Wenn du an diesen VCP einen seriellen Uart von deinem Sensor anschliesen willst ist diese FW völlig ungeeignet ein fertiger Baustein wäre die bessere Lösung. Zusätzlich kann man ein USB Uart nur begrenzet mit einer festverbauten Schnittstelle vergleichen, schlieslich kannst du den Uart jederzeit durch Ausstecken entfernen. Deine Software muss auf sowas vorbereitet sein
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.