FT232 ähnliches USB mit atmega32u4 unter C

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:
> 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)

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.

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:
> 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 im Beitrag #6912414:
> 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.

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.

c-hater schrieb:
> dass man tatsächlich geholfen hat.

ja. Das verstehe ich nur zu gut.

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.

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.

c-hater schrieb:
> und "usbser.sys"

usbser.sys von 2010 findet sich in C:\Windows\System32\drivers.

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.

also warten auf ein anderes inf.

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."

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?

Abdul K. schrieb:
> Systemwiederherstellung war die Rettung.

Danke für den Hinweis.

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.

Danke Thomas. Mache ich und melde mich morgen.

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?

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.

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.

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.

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.

Thomas Z. schrieb:
> 0x10, 0x01,  // bcdUSB auf usb1.1 umstellen

das hat so geklappt Thomas.

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.

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?

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.

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 !

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