es geht um die Inbetriebnahme eines 32u4-Boards unter Win7 64bit. Auf dem Board läuft usb_serial.c von Paul Stoffregen. Im Gerätemanager taucht ein USB-Gerät auf mit gelbem Rufzeichen. Es fehlt der passende Treiber. Frage: Welchen Treiber soll ich passend zu Win7 64bit nehmen? Hat jemand einen Link zu einem passenden INF-file?
Matthias W. schrieb: > es geht um die Inbetriebnahme eines 32u4-Boards unter Win7 64bit. Auf > dem Board läuft usb_serial.c von Paul Stoffregen. Im Gerätemanager > taucht ein USB-Gerät auf mit gelbem Rufzeichen. Es fehlt der passende > Treiber. > > Frage: Welchen Treiber soll ich passend zu Win7 64bit nehmen? Hat jemand > einen Link zu einem passenden INF-file? Blöde Frage. Zeigt, dass du eigentlich keine Ahnung von der Sache hast und somit eigentlich nicht ermächtigt wärst, überhaupt irgendwas mit USB zu machen. Also: Windows7 erwartet ein *.inf-File, in dem eine passende HardwareID als unterstützt angeboten wird. Sprich: du musst einfach nur rauskriegen, mit welcher HW-ID sich das Gerät bei Windows meldet (das macht man, indem man den Gerätemenager benutzt) und die dann in irgendein *.inf-File schreiben, welches letztlich nur den generischen Treiber für serielle USB-Geräte lädt. Dafür kannst du unzählige Vorlagen finden. Z.B. all das, was als Treiber für Programmieradapter mit STK500v2-kompatibler Schnittstelle agiert. Aber auch viele andere Geräte haben nur genau sowas. Die Auswahl an geeigneten Vorlagen ist also riesengroß.
http://ww1.microchip.com/downloads/en/DeviceDoc/MCP2221%20Windows%20Driver%202014-10-09.zip Dann suchst Du Dir eine VID/PID-Kombination aus dem .inf und packst die in Deinen AVR-Sourcecode, compilierst und flashst neu. Du änderst auf gar keinen Fall die .inf. Dann wird nämlich das zugehörige Microsoft-Zertifikat im zugehörigen .cat ungültig, und dann lädt Windows den Treiber nicht mehr ohne Verrenkungen. fchk
Frank K. schrieb: > Du änderst auf gar keinen Fall die .inf. Dann wird nämlich das > zugehörige Microsoft-Zertifikat im zugehörigen .cat ungültig, und dann > lädt Windows den Treiber nicht mehr ohne Verrenkungen. Das gilt nicht für Windows7. Da ist das noch kein Problem. Und Windows10 will eh' niemand, der noch alle Latten am Zaun hat.
Matthias W. schrieb: > usb_serial.c von Paul Stoffregen kenn ich nicht Matthias W. schrieb: > Im Gerätemanager taucht ein USB-Gerät auf mit gelbem Rufzeichen. dafür kann es verschiedene Ursachen geben. Enumeriert das Device? Prüf das mit UsbView. W7 sollte ein Std konformes CDC Device von alleine finden. Ansonsten hilft Zadig. Thomas
Das ist also ein Teensy 2.0 - warum fragst Du nicht mal bei PJRC nach?
Thomas Z. schrieb: > W7 sollte ein Std konformes CDC Device von alleine > finden. Nein. Windows7 hat keinen class driver für USB-ACM. Oder vielmehr: hat ihn schon, benutzt ihn aber nicht in diesem Sinne. Nö, das will schön exakt die kompatiblen Hardware-IDs in irgendeiner *.inf sehen. Für jedes verschissene Device extra.
c-hater schrieb: > Windows7 erwartet ein *.inf-File, in dem eine passende HardwareID > als unterstützt angeboten wird. Sprich: du musst einfach nur > rauskriegen, mit welcher HW-ID sich das Gerät bei Windows meldet das kann ich auslesen, kein Problem !
Frank K. schrieb: > Dann suchst Du Dir eine VID/PID-Kombination aus dem .inf und packst die > in Deinen AVR-Sourcecode, compilierst und flashst neu. Danke für den Hinweis Frank !
Thomas Z. schrieb: > Ansonsten hilft Zadig. Danke ! Zadig hatte ich mal verwendet. War etwas seltsam im Verhalten weil es lange dauerte und nicht sauber beendete - ging dann aber doch. Danke für den Hinweis. Ich hatte das Tool schlicht mittlerweile vergessen !
Rudolph R. schrieb: > Das ist also ein Teensy 2.0 - warum fragst Du nicht mal bei PJRC nach? jein. Es ist ein ProMicro-Board für 3.5€ aus China. Auf der Seite von PJRC fand ich auf die Schnelle einfach kein INF. ich habe ein zip von der Seite wo die c-Dateien drin sind und die Header - aber das INF eben nicht. bei LUFA ist ein INF im Verzeichnis dabei - nur weiß ich nicht ob ich das nehmen soll.
Matthias W. schrieb: > bei LUFA ist ein INF im Verzeichnis dabei - nur weiß ich nicht ob ich > das nehmen soll. Probiere es doch einfach aus.
c-hater schrieb: > du musst einfach nur > rauskriegen, mit welcher HW-ID sich das Gerät bei Windows meldet bei Eigenschaften von USB Serial steht: USB\VID_16C0&PID_047A&REV_0100 die Datei LUFA USBtoSerial.inf alleine hilft nicht: im Fenster Treibersoftware aktualisieren - USB Serial steht dann: USB Serial konnte nicht installiert werden Die Treibersoftware für das Gerät wurde nicht gefunden. Wenn Sie den Hersteller... viele werden das wohl in der Arduino-Umgebung probieren. Da wird ein Treiber wohl gefunden werden. Ich nehme jedoch WinAVR.
:
Bearbeitet durch User
ich habe es endlich wieder im Netz gefunden: die von mir genutzten Dateien usb_serial.c und usb_serial.h aus USB Serial, Version 1.7 sind in www.pjrc.com/teensy/usb_serial.html dabei steht: WARNING: obsolete, use Teensyduino for new projects. ich habe den C-Code in mein Projekt mittels Makefile eingebunden. als Windows-Treiber kann man dies herunterladen: Windows Driver Installer. Dahinter liegt eine Datei serial_install.exe. das werde ich erst mal versuchen.
in der Datei usb_serial.c steht: #define VENDOR_ID 0x16C0 #define PRODUCT_ID 0x047A
Matthias W. schrieb: > als Windows-Treiber kann man dies herunterladen: Windows Driver > Installer. Dahinter liegt eine Datei serial_install.exe. Du machst es genau richtig... Damit holst du dir mit Sicherheit unerwünschte Programme auf den Rechner. Ich glaube c-hater hatte Recht. Du solltest die Finger von USB lassen solange du nicht weißt was du tust. Ich versteh immer noch nicht was dir an zadig nicht gefällt. Thomas
Thomas Z. schrieb: > Damit holst du dir mit Sicherheit > unerwünschte Programme auf den Rechner. das sehe ich nicht so Thomas. das ist doch genau der Mann der dieses Programm zu dem ich den passenden Treiber suche ins Netz gestellt hat. Warum soll ausgerechnet er ein unerwünschtes Programm auf seiner Seite posten? Das macht doch gar keinen Sinn ! Sein Geschäftsmodell ist es doch Platinen zu entwickeln und zu verkaufen - in Verbindung mit dazu passender Software die keinen Ärger macht - denn sonst zerstört er sein eigenes Geschäftsmodell. Das will er mit Sicherheit nicht.
Thomas Z. schrieb: > was dir an zadig nicht gefällt. das habe ich oben geschrieben. Natürlich kann ich es ein weiteres Mal probieren.
Was macht man eigentlich mit HID-Geräten die eigentlich ja keinen besonderen Treiber brauchen, aber die Seriennummer im USB-Deskriptor einkodiert haben? Ich habe einfach die Seriennummer in die inf-Datei gemogelt und dann im Testsigningmodus installiert. Weil natürlich das Zertifikat nicht mehr passte.
pumuggl schrieb: > Was macht man eigentlich mit HID-Geräten die eigentlich ja > keinen besonderen Treiber brauchen, aber die Seriennummer > im USB-Deskriptor einkodiert haben? > > Ich habe einfach die Seriennummer in die inf-Datei gemogelt > und dann im Testsigningmodus installiert. > Weil natürlich das Zertifikat nicht mehr passte. Die Seriennummer ignorieren. HID ist ein Classdriver die brauchen keine SN. Die SN dient unter win dann nur dazu damit win erkennen kann, dass die Treiber schon mal (für einen anderen USB Port) installiert wurden. Win startet dann den Treiber Dialog nicht mehr. Das das leider das etwas seltsame Verhalten unter win bei USB Treiberinstallationen. Meins Wissens ist die SN zwingend nur bei Memory Devices vorgeschrieben. Bei CDC kann man mit der SN erreichen, dass immer der gleiche Com Port benutzt wird egal an welchem USB Port das Device hängt. Thomas
> Die Seriennummer ignorieren.
Ja, dann ignoriert W aber auch das angeschlossene Gerät
oder ist maulig das es keine passenden Treiber für das
Gerät gäbe.
Ich habe mich da auch täuschen lassen.
Es gibt doch noch ein sys-File, also einen Treiber.
Also kein HID. Tschuldigung.
Mit der SN im inf-File klappt die Installation und
das angeschlossene Gerät funktioniert auch.
Aber danke für die Auskunft.
pumuggl schrieb: > Was macht man eigentlich mit HID-Geräten die eigentlich ja > keinen besonderen Treiber brauchen, aber die Seriennummer > im USB-Deskriptor einkodiert haben? Einfach nichts. Entweder ist's ein von Windows direkt unterstütztes HID-Gerät, dann kümmert sich Windows selber um alles weitere (und die Seriennummer ist praktisch Wurscht). Oder das ist halt nicht der Fall, dann ist es Aufgabe der Anwendung, die das Device über's HID-API benutzen möchte, irgendwas mit der Seriennummer anzufangen. Sie kann die für irgendwas benutzen, sie kann sie aber auch genauso weitgehend ignorierieren, wie Windows das für unterstützte Standardgeräte tut. Die normale Verwendung von Windows selber ist: Hat ein Gerät eine Seriennummer, wird diese zur Identifikation des Exemplars genutzt. Hat es keine, wird statt dessen die Busadresse benutzt. Sinnvoll ist, wenn eigene Handler das genauso halten. Noch sehr viel sinnvoller ist: Wenn man in eigenen Devices eine Seriennummer verfügbar macht, dann sollte diese auch wirklich eindeutig sein...
pumuggl schrieb: > Ja, dann ignoriert W aber auch das angeschlossene Gerät > oder ist maulig das es keine passenden Treiber für das > Gerät gäbe. Das widerspricht allem was ich bisher über inf Dateien und Treiberinstallationen unter win gesehen habe. USB Treiber werden über das vid/pid Combo per inf geladen. In einigen seltenen Fällen noch über die Revision (Device Version im Deskriptor). Mir ist auch gar nicht bekannt wie man die SN in ein inf bekommen könnte. Kannst du dazu mehr sagen? Das würde mich schon interessieren. Thomas
Angehängte Dateien:
-
1111.png
8,7 KB
> wie man die SN in ein inf bekommen könnte.
Z.B. mit einem Editor.
Aus dem geänderten inf-File:
1 | ; Blackhawk USB560/USB560M/USB560BP JTAG Emulator |
2 | %bh560usb.DeviceDesc% = bh560usb.Dev, USB\VID_0B1E&PID_8007&REV_0100 |
3 | %bh560usbm.DeviceDesc% = bh560usb.Dev, USB\VID_0B1E&PID_8007&REV_0200 |
4 | %bh560usbml.DeviceDesc% = bh560usb.Dev, USB\VID_0B1E&PID_8007&REV_0201 |
5 | %bh560ubp.DeviceDesc% = bh560usb.Dev, USB\VID_0B1E&PID_8007&REV_0300 |
6 | %bh560usbm.DeviceDesc% = bh560usb.Dev, USB\VID_0B1E&PID_8007&REV_0400 |
7 | %bh560usbm.DeviceDesc% = bh560usb.Dev, USB\VID_0B1E&PID_8007&HD1111 |
8 | %bh560usbml.DeviceDesc% = bh560usb.Dev, USB\VID_0B1E&PID_8007&REV_0401 |
Die Zeile mit: USB\VID_0B1E&PID_8007&HD1111 macht den Unterschied. Sonst mag er den Treiber nicht. Aber ich muss mich ja nicht beklagen. Alles funktioniert soweit.
das Installieren mit serial_install.exe hat geklappt. Das gelbe Warnzeichen im Gerätemanager ist weg. Es meldet sich Teensy USB Serial (COM5). So weit so gut. Nur leider gelingt es bisher scheinbar nicht Zeichen über USB auszugeben. Entweder stimmt die Baudrate nicht oder es kommt nichts. Über die normale serielle Schnittstelle kann ich Ausgaben machen und mit hterm anzeigen lassen. Über USB geht bisher nichts. Die Programmierung über USB per AVRDUDE geht. Dazu muss man Reset drücken und warten bis sich der Bootloader auf COM4 meldet und dann AVRDUDE starten bevor COM4 wieder verschwindet. Wie bekomme ich nun die USB-Ausgabe zum Laufen?
Matthias W. schrieb: > Wie bekomme ich nun die USB-Ausgabe zum Laufen? Erstmal einen Loop-Back Test mit Terminalprogramm machen. Siehe http://stefanfrings.de/mikrocontroller_buch2/Einblick%20in%20die%20moderne%20Elektronik.pdf Kapitel 6
Stefanus F. schrieb: > Erstmal einen Loop-Back Test mit Terminalprogramm machen. Danke für den Link Stefanus ! ich schau in die Datei mal rein. Loop-Back verstand ich so daß man Sender und Empfänger verbindet und so sehen kann ob das was man gesendet hatte auch ankommt. bei der seriellen Schnittstelle und beim FTDI-board kann ich das machen. Aber wie bei USB? das ist mir momentan nicht klar. der Code von www.pjrc.com/teensy/usb_serial.html ist ja kein Hexenwerk. Ich nutze die beiden Dateien usb_serial.c und das .h dazu. Dazu gibt es noch eine out-Funktion die zur Ausgabe usb_serial_putchar(c) verwendet. Eben da kommt nichts. Auch usb_serial_putchar_nowait(c) klappt nicht. da wird irgendwo ein Fehler sein. Nur eben wo. Es ist mein erster Versuch mit solchem USB-Kram. Auf eine eigene lange Erfolgsgeschichte damit kann ich nicht bauen.
Matthias W. schrieb: > Loop-Back verstand ich so daß man Sender und Empfänger verbindet und so > sehen kann ob das was man gesendet hatte auch ankommt. genau > bei der seriellen Schnittstelle und beim FTDI-board > kann ich das machen. Aber wie bei USB? Ach so. Sorry, ich habe zwei Threads durcheinander geworfen. Dachte, dein Mikrocontroller wäre als USB-UART programmiert, also mit herausgeführten Rx und Tx Pins. Wenn nicht, müsste der Loop-Back per Software implementiert werden. Alles was die Firmware vom USB Port empfängt, schickt sie wieder zurück. Ich denke, dass die Baudrate in diesem Fall keine Rolle spielt.
c-hater schrieb: > Für jedes verschissene Device extra. Kannst du deine grundlose Fäkalsprache bitte zu Hause lassen?
Stefanus F. schrieb: > Sorry, ich habe zwei Threads durcheinander geworfen. das kann passieren - trotzdem Danke für den Willen zu helfen. > Dachte, > dein Mikrocontroller wäre als USB-UART programmiert, also mit > herausgeführten Rx und Tx Pins. nein. Ich will das USB-Interface des 32u4 zur Ausgabe nutzen - so wie es das Beispielprogramm von Paul Stoffregen macht. > Wenn nicht, müsste der Loop-Back per Software implementiert werden. > Alles was die Firmware vom USB Port empfängt, schickt sie wieder zurück. > Ich denke, dass die Baudrate in diesem Fall keine Rolle spielt. es sollte kein Hexenwerk sein das Beispiel zum Laufen zu bekommen. Hier ist nicht mehr der richtige Ort das zu diskutieren weil das INF-Thema ja gelöst ist. Ich mach einen neuen Thread für das USB-Thema auf. Danke Dir und Euch für die Beiträge !
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.