USB CDC - Schnittstelle öffnen, lesen und schreiben

[TUX_der_Pinguin]

Hallo,

ich habe hier ein Sensor der per USB am PC angeschlossen wird. Jetzt steht im beiliegenden Kommunikationsprotokoll das man das Gerät "einfach ansprechen" könnte. Ich frage mich nur wie soll das gehen? Also statt auf einen COM-Port zu zu greifen über Vendor-ID und Device-ID den Zugriff zu regeln.

Das Kommunikationsprotokoll an sich besteht aus dem schreiben und lesen von Bytes auf der Schnittstelle, so wie man das von einer seriellen Schnittstelle (RS232) auch kennt.

Auszug aus dem PDF:

Zitat:

Die USB Sensoren unterstützen eine Teilmenge des USB CDC (Communication Device Class, "http://www.usb.org/developers/devclass_docs/usbcdc11.pdf") Protokolls für die Datenübertragung. Da keine Notwendigkeit für die Auswahl der Baudrate oder anderer RS232 Kommunikationsparameter besteht, werden die betreffenden Eigenschaften irgnoriert. Stattdessen werden die über das USB Interface übertragenen Daten vom Sensor direkt aus der FIFO ausgewertet. Die grundsätzliche Kompatibilität zum CDC Protokoll erlaubt es jedoch, einen CDC class Treiber des jeweiligen Host-Betriebssystems einzusetzen.

[himitsu]

Zitat:

Da keine Notwendigkeit für die Auswahl der Baudrate oder anderer RS232 Kommunikationsparameter besteht, werden die betreffenden Eigenschaften irgnoriert.

Sicher, dass dieses Gerät keinen virtuellen Comport anbietet?

Klingt fast so, als wenn das Gerät über den Standardtreiber im Windows einen Port bereitstellt,
welcher sich an alle USB-CDC-Geräte anhängen dürfte, so lange sie keinen eigenen Treiber installiert haben.
Den Port dürfte man dann im Gerätemanager an diesem Gerät ablesen können.

[TUX_der_Pinguin]

Zitat:

Zitat von himitsu (Beitrag 1478343)

Sicher, dass dieses Gerät keinen virtuellen Comport anbietet?

Klingt fast so, als wenn das Gerät über den Standardtreiber im Windows einen Port bereitstellt,
welcher sich an alle USB-CDC-Geräte anhängen dürfte, so lange sie keinen eigenen Treiber installiert haben.
Den Port dürfte man dann im Gerätemanager an diesem Gerät ablesen können.

Du hast recht, es wird ein Port bereitgestellt und der funktioniert auch. Mich hat nur die Dokumentation total verwirrt, das dort nicht stand "greifen sie über den COM Port auf die Schnittstelle zu". Ich habe jetzt mal wild mit den Schnittstellen Parametern (Baudrate, Datenbits etc.) gespielt und jedesmal klappt die Kommunikation, was ja normalerweise nicht funktionieren dürfte wenn es sich um eine echte serielle Kommunikation handeln würde. Es scheint also so zu sein, wie du auch geschrieben hast, das der Windows Treiber das alles regelt und man irgendwelche Parameter angeben kann.

Dann verbuche ich das mal unter unnötig kompliziert beschrieben, obwohl es doch so einfach ist. Hab mich einfach durch die diversen Aussagen auf die Falsche Spur bringen lassen :spin:

Danke trotzdem

[dummzeuch]

Zitat:

Zitat von TUX_der_Pinguin (Beitrag 1478368)

Dann verbuche ich das mal unter unnötig kompliziert beschrieben, obwohl es doch so einfach ist. Hab mich einfach durch die diversen Aussagen auf die Falsche Spur bringen lassen :spin:

Vermutlich gibt es aber trotzdem eine weitere Schnittstelle, die nicht per virtuellem COM-Port arbeitet. Und die wird den ein oder anderen Vorteil bieten. Ich habe schon mehrfach angesetzt z.B. bei USB-Seriell-Wandlern von FTDI die native Schnittestelle zu nutzen, aber irgendwie bin ich jedes Mal von wichtigerem abgelenkt worden.

Auf der anderen Seite sind COM-Ports eine simple und weit verbreitete Schnittstelle, auch wenn die Artikelschreiber in IT-Magazinen nicht müde werden zu betonen, dass Computer sowas heutzutage nicht mehr bräuchten...

[himitsu]

Eine "echte" Serielle Schnittstelle hat irgendwo "physisch" die Daten "analog/getaktet" im Kabel übertragen.
Virtuelle Schnittstellen, wo die Daten überall voll-"digital" übertragen werden und wo es keine physische "unsynchronisierte" Übertragung gibt, der sind die BAUD-Raten und Dergleichen egal.
Klar, der Treiber könnte auch strikt nur mit einer bestimmten "Taktrate" arbeiten und bei allem Anderen einen Fehler werfen, oder er ignoriert diese Angaben einfach, weil er sie eh nicht benötigt. :zwinker:


z.B. COM-Port von auf TCP/IP+Port
Beides sind "Streams", aber im Ethernet synchronisiert sich die Übertragung von selbst, drum wäre da die BAUD-RATE auch egal.
Der Treiber könnte dann die BAUD nur noch dafür benutzen, um die Übertragung entsprechend zu drosseln, damit sie vom Tempo her gleich ist, aber wer will sowas.

Zitat:

Vermutlich gibt es aber trotzdem eine weitere Schnittstelle

Kann sein, da USB es ja erlaubt, dass man mehrere Klassen unterstützen kann.
z.B. könnte man auch noch HID verwenden.

Insgesamt finde ich es schöner, wenn "Standardschnittstellen" genutzt werden, wo es im System bereits Standardtreiber gibt.
Dann ist man nicht abhängig von speziellen Gerätetreibern, die im nächsten Windows/WindowsUpdate vieleicht nicht mehr funktionieren.
Und da ist CDC nunmal einer der "einfachsten".
https://microchipdeveloper.com/usb:device-classes

Für die Software ist es bei Serial, HID und Ähnlichem dann auch egal, ob die Hardware direkt am USB hängt oder z.B. via BT verbunden ist.