Forum: Mikrocontroller und Digitale Elektronik FTDI vs. CDC (Virtual Serial Port) vs. HID


von Sebastian R. (lange_leitung)


Lesenswert?

Liebe Gemeinde,

wir diskutieren gerade verschiedene Möglichkeiten, um eine 
Steuerungsplatine für einen Motor an einen PC anzubinden. Aktuell haben 
wir bei unseren Platinen den ATMEGA32U4 im Einsatz, der ja schon eine 
USB-Schnittstelle mitbringt. Nichtsdestotrotz wollen wir die Frage 
grundlegend diskutieren.
Es steht FTDI, CDC und HID zur Diskussion. Als Geschwindigkeit reicht 
USB 2 locker.

FTDI
+ bewährt
- zusätzliche Hardware nötig
- Treiber nötig

CDC
+ keine Treiber nötig (ab Win10)
+ Übertragung in beide Richtungen
- keine zugesicherte Bandbreite

HID
+ keine Treiber nötig
+ sichere Übertragung (Bandbreite und Fehlerkontrolle)
- Übertragung nur in eine Richtung (2. Richtung aber dennoch möglich?!)

Ich möchte euch um eure Meinung und Erfahrung zu den Vor- und Nachteilen 
bitten. Hab ich was falsch verstanden? Gibt es noch mehr Aspekte?
Immer raus damit und vielen Dank!!

Sebastian

von Timmo H. (masterfx)


Lesenswert?

HID geht in beide Richtungen. Habe schon mit dem CP2110 gearbeitet 
(quasi ein cp2102 als HID)

von Stefan F. (Gast)


Lesenswert?

Sebastian R. schrieb:
> CDC
> + Übertragung in beide Richtungen

Das können die beiden anderen auch, also kein Plus-Punkt.

> - keine zugesicherte Bandbreite

Kann gut sein, ich habe allerdings das Bauch-Gefühl, dass sie für den 
Anwendungsfall dennoch schnell genug sein wird und daher irrelevant sein 
könnte.

> Fehlerkontrolle

Sollte bei allen drei Varianten vorhanden sein, oder etwa nicht? Keine 
Ahnung, aber jetzt interessiert mich auch, was die Experten dazu wissen.

Ich hatte mit CDC bislang noch keine Schwierigkeiten.

von Maxe (Gast)


Lesenswert?

Sebastian R. schrieb:
> CDC
> + keine Treiber nötig (ab Win10)
Wie siehts mit Rueckwaertskompatibilitaet aus? Win7/8? Da koennte ein 
FTDI einfacher sein.

von kack win (Gast)


Lesenswert?

Win7 und 8 haben auch CDC Treiber von Windows, laden den aber nicht für 
CDC Geräte. Dieser macht bei hohen Datenraten aber Bluescreens.
Unter Win10 ist das vielleicht gefixed.

Beitrag #5931124 wurde vom Autor gelöscht.
von W.S. (Gast)


Lesenswert?

Sebastian R. schrieb:
> Es steht FTDI, CDC und HID zur Diskussion.

HID sollte man besser für tatsächliche HID-Geräte in Ruhe lassen und 
nicht für sowas wie Motorsteuerungen etc. mißbrauchen wollen. Das geht 
zwar, ist aber dennoch Mißbrauch - oder ist ein Motor etwa ein 
HID-Gerät?

Ansonsten ist FTDI und CDC so ziemlich exakt dasselbe, mit der ausnahme, 
daß man bei den FTDI-D2XX-Treibern auch den direkten Weg wählen kann 
unter Umgehung des OS. Kann man benutzen, hab ich früher auch gemacht, 
ist aber heutzutage nicht mehr nötig. Mit einem ganz normalen CDC kommt 
man genauso zurecht.

W.S.

von fchk (Gast)


Lesenswert?

Sebastian R. schrieb:

> CDC
> + keine Treiber nötig (ab Win10)
.inf-File für ältere Windows-Versionen

> + Übertragung in beide Richtungen
hast Du immer
> - keine zugesicherte Bandbreite
gibts nur bei isochronen Transfers - CDC benutzt Bulk.


> HID
> + keine Treiber nötig
> + sichere Übertragung (Bandbreite und Fehlerkontrolle)
> - Übertragung nur in eine Richtung (2. Richtung aber dennoch möglich?!)
falsch. Du kannst mit einem Full Custom HI Device in beide Richtungen 
übertragen.
- Interrupt-Transfers, daher max 64kB/s Datenrate bei FS möglich, Bulk 
Transfers (CDC-ACM) können die gesamte mögliche Bandbreite verwenden.
+ ist für den Benutzer einfacher, weil das jeweilige Gerät automatisch 
zugewiesen wird - Du musst keinen COM-Port auswählen. Das mit dem 
COM-Port auswählen geht zwar auch per Software und SetupAPI, ist aber 
mehr Aufwand.
+ Du kommunizierst mit Paketen, nicht per kontinuierlichem Datenstrom. 
Daher entfällt das Problem der Synchronisierung, wenn Daten verloren 
gehen sollten mangels Handshake.


Andere Möglichkeit: virtuelles Ethernet per RNDIS oder CDC-ECM
+ keine speziellen Treiber nötig
+ bekanntes API (Sockets)
+ Zugriff per Browser etc möglich
+ Bulk-Transfers, daher hohe Geschwindigkeit.

Für sowas würde ich dann aber eher keinen AVR nehmen, sondern was 32 
Bittiges.

fchk



>
> Ich möchte euch um eure Meinung und Erfahrung zu den Vor- und Nachteilen
> bitten. Hab ich was falsch verstanden? Gibt es noch mehr Aspekte?
> Immer raus damit und vielen Dank!!
>
> Sebastian

von jemand (Gast)


Lesenswert?

Aus meiner Sicht ist ein Aspekt, der gegen USB-Lösungen auf dem µC (Als 
HID, CDC) spricht, die Komplexität und der Speicherverbrauch der 
USB-Stacks.

Der FTDI hängt halt über ein UART dran, was nur ein wenige Zeilen Code 
ist. Für Bastelprojekte habe ich schon in einigen Fällen einfach einen 
FT232 dazugebaut, und das trotz Controllern mit USB-Fähigkeit.
Weil ich manchmal schlicht keine Lust hatte, mich mit den USB-Stacks zu 
plagen. Nicht in der Freizeit, nicht um 3€ zu sparen.

Bitte nicht falsch verstehen: Ich bin kein genereller USB-Feind - ich 
habe selber schon mehrere Projekte mit CDC im Controller umgesetzt.

Mir gehts nur drum, dass das ein guter Grund für einen FT232 sein 
könnte.

von Jim M. (turboj)


Lesenswert?

In der Aufzählung fehlt was: WinUSB.

Vorteile:

Keine Treiberinstallation (für den Nutzer) ab Windows 8 mit MS OS 
Descriptors[1].
Spart einen Endpoint gegenüber CDC.
Platformübergreifendes API verfügbar (LibUSB unterstützt WinUSB als 
Backend).
Deutlich mehr Performance als FTDI oder HID - und je nach Programmierung 
vielleicht sogar CDC.

Win7 bräuchte ein .inf oder besser gleich Zadig, läuft aber im Januar 
ohnehin aus.

[1] Mit den M$ OS Deskriptoren kann ein USB Gerät dem Windows sagen 
welchen Treiber es haben will.

Siehe: 
https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-defined-usb-descriptors

von Frank K. (fchk)


Lesenswert?

Jim M. schrieb:
> In der Aufzählung fehlt was: WinUSB.
[...]
> Deutlich mehr Performance als FTDI oder HID - und je nach Programmierung
> vielleicht sogar CDC.

Wo soll die herkommen? Bulk Transfers sind bei USB alle gleich schnell, 
egal ob über CDC (-ACM, -EEM, -ECM), fullcustom wie FTDI oder semicustom 
per WinUSB. HID hat einen geringeren Durchsatz, ja, weil es Interrupt 
Transfers benutzt.

fchk

von Andreas L. (Gast)


Lesenswert?

Sebastian R. schrieb:
> Aktuell haben
> wir bei unseren Platinen den ATMEGA32U4 im Einsatz

Hallo Sebastian,

aus einem gerade abgeschlossenen Projekt bei dem ein ATMega32U4 zur 
Schrittmotorsteuerung > 25 kHz eingesetzt wurde, möchte ich zu Bedenken 
geben, dass die Priorität der beiden USB Interrupts hart verdrahtet ist 
und noch über der sämtlicher Timer IRQ liegt. Jedes trennen/verbinden 
der USB-Verbindung gefolgt von einer BUS-Enumeration zerstörte den 
Bewegungsablauf Prozess komplett.

Insbesondere für eine mögliche ESD-Konformität habe ich diese 
Eigenschaft der integrierten USB-Schnittstelle des ATMega in schlechter 
Erinnerung.

Abhilfe schaffte schlussendlich ein per UART angesetzter FT232RL.

Viele Grüße

Andreas

von Niklas Gürtler (Gast)


Lesenswert?

Jim M. schrieb:
> In der Aufzählung fehlt was: WinUSB.

Dem würde ich stark zustimmen. W.S. hat es richtig formuliert:

W.S. schrieb:
> oder ist ein Motor etwa ein HID-Gerät?

CDC-ACM ist eigentlich nur für Analog-Modems gedacht. Beide 
Möglichkeiten sind nur unflexible Krücken. Bei CDC hat man immer das 
Problem den richtigen COM Port zu finden, Paketanfänge zu erkennen, 
Handshake zu implementieren, dass man den Puffer im OS Treiber nicht gut 
kontrollieren kann... Mit einem "richtigen" USB Gerät erhält man die 
volle Flexibilität des USB Protokolls, mit beliebig konfigurierbaren 
Endpoints.

In meinem USB-Tutorial mit STM32 habe ich geschrieben, wie man mit 
WinUSB ohne jegliche Treiber Installation oder Konfiguration auf eigene 
USB Geräte zugreift (unabhängig von STM32). Wie schon erwähnt ist das 
dank libusb auch portabel.

Andreas L. schrieb:
> dass die Priorität der beiden USB Interrupts hart verdrahtet

Das ist dann aber ein Problem des ATmega. Bei anderen Controllern wie 
z.B. STM32 sind die Interrupt Prioritäten einstellbar, und 
verschachtelte Interrupts sind auch möglich.

von Andreas L. (Gast)


Lesenswert?

Niklas Gürtler schrieb:
> Das ist dann aber ein Problem des ATmega.

Hallo Niklas,

vollkommen richtig. Insofern war meine Bemerkung o.B.d.A. auch nur dem 
Umstand geschuldet, dass eingangs von einem ATMega die Rede war. Den 
Zusatz "grundlegend diskutieren" hatte ich überlesen.

Grüße

Andreas

von Sebastian R. (lange_leitung)


Lesenswert?

jemand schrieb:
> Der FTDI hängt halt über ein UART dran, was nur ein wenige Zeilen Code
> ist. Für Bastelprojekte habe ich schon in einigen Fällen einfach einen
> FT232 dazugebaut, und das trotz Controllern mit USB-Fähigkeit.
> Weil ich manchmal schlicht keine Lust hatte, mich mit den USB-Stacks zu
> plagen. Nicht in der Freizeit, nicht um 3€ zu sparen.

Da hast Du Recht. Den ganzen USB-Kram spart man isch, aber dafür 
benötigt man halt zusätzliche Hardware und Treiber.
Mit dem USB-Kram muss man sich ja nur einmal rumschlagen, dann kann 
man´s für neue Projekte kopieren.

von Sebastian R. (lange_leitung)


Lesenswert?

Andreas L. schrieb:
> Jedes trennen/verbinden
> der USB-Verbindung gefolgt von einer BUS-Enumeration zerstörte den
> Bewegungsablauf Prozess komplett.

Wie meinst Du das? Nach einem Trennen/Verbinden startet der 
Programmablauf bzw. Bewegungsprozess doch eh neu. Wo war da das Problem?


> Insbesondere für eine mögliche ESD-Konformität habe ich diese
> Eigenschaft der integrierten USB-Schnittstelle des ATMega in schlechter
> Erinnerung.

Hat das zu Problemen im Prüflabor, oder auch in der Funktionalität der 
Baugruppe oder anderer Baugruppen geführt?


Danke für den WinUSB Hinweis. Das nehme ich mal in die Liste auf.

Sebastian

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Andreas L. schrieb:
> Insbesondere für eine mögliche ESD-Konformität habe ich diese
> Eigenschaft der integrierten USB-Schnittstelle des ATMega in schlechter
> Erinnerung.

PS: Sollte man nicht sowieso ESD-Dioden zusätzlich verbauen? Da gibt's 
doch extra IC's passend für USB.

von Bauform B. (bauformb)


Lesenswert?

jemand schrieb:
> Aus meiner Sicht ist ein Aspekt, der gegen USB-Lösungen auf dem µC
> (Als HID, CDC) spricht, die Komplexität und der Speicherverbrauch
> der USB-Stacks.
>
> Der FTDI hängt halt über ein UART dran, was nur ein wenige Zeilen Code
> ist. Für Bastelprojekte habe ich schon in einigen Fällen einfach einen
> FT232 dazugebaut, und das trotz Controllern mit USB-Fähigkeit.
+1
Mit dem FT232RL braucht man nur 2 Optokoppler für eine solide 
Potentialtrennung. Der FT bekommt seine Versorgung per USB. 
Potentialtrennung zwischen USB/PC und wirklichem Leben ist immer gut ;)

von Bob (Gast)


Lesenswert?

Andreas L. schrieb:
> Abhilfe schaffte schlussendlich ein per UART angesetzter FT232RL.

Nur so am Rande, FTDI ist da schon lange etwas weiter, FT230XS-R zum 
Beispiel sind etwas kompakter und deutlich günstiger.

von Andreas L. (Gast)


Lesenswert?

Niklas G. schrieb:
> Sollte man nicht sowieso ESD-Dioden zusätzlich verbauen?

Hallo Niklas,

die sind verbaut und begrenzen die ESD induzierten Spannungsspitzen auf 
ein für die Hardware überlebenswichtiges Niveau. Allerdings verhindern 
sie nicht, dass das differentielle Leitungspaar kurzzeitig auf ein 
gemeinsames Potenzial geht und der USB so einen Reset oder einen 
sonstigen unzulässigen Zustand erkennt. Ein Neuaufbau der Verbindung ist 
dann die Folge.

Grüße

Andreas

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Andreas L. schrieb:
> Ein Neuaufbau der Verbindung ist
> dann die Folge.

Das klingt ja auch korrekt... Bei eingesteckten USB-Kabel sollten ja 
auch keine ESDs auf den Datenleitungen auftreten, und jeder USB-Konforme 
Controller müsste die Verbindung dann zurücksetzen.

von Stefan F. (Gast)


Lesenswert?

Niklas Gürtler schrieb:
> Bei CDC hat man immer das
> Problem den richtigen COM Port zu finden

Sowohl Windows als auch Linux können die COM-Ports mit ihren 
ausgeschriebenen Namen auflisten. Diese kann Software benutzen, um den 
richtigen Port zu finden.

> Paketanfänge zu erkennen, Handshake zu implementieren,
> dass man den Puffer im OS Treiber nicht gut kontrollieren kann

Kann gut sein, die COM Ports verfolgen ja eher den Ansatz gepufferter 
Streams.

von Detlev T. (detlevt)


Lesenswert?

Sebastian R. schrieb:
> HID
> + keine Treiber nötig

Ich bin da einmal mit einem FT260 auf die Nase gefallen. (u.a.) USB zu 
Serial Umsetzer mit HID, deshalb kein Treiber nötig. Klang ja schön.

ABER: Es wird kein virtueller COM-Port zur Verfügung gestellt. Man kann 
ihn nur mit einem selbstgeschriebenen Programm und der FTDI-Api 
benutzen. Irgendwo habe ich die Information dann auch gefunden, nur 
leider halt zu spät.

von W.S. (Gast)


Lesenswert?

Sebastian R. schrieb:
> Wie meinst Du das? Nach einem Trennen/Verbinden startet der
> Programmablauf bzw. Bewegungsprozess doch eh neu. Wo war da das Problem?

Eigentlich ist das gar kein problem, sondern muß lediglich auf der 
PC-Seite Beachtung finden.

Einen richtigen COM-Port macht man vom Programm her auf und benutzt ihn. 
Wenn mal das Kabel gezogen und wieder gesteckt wird, dann gibt es 
allenfalls einige wirre Zeichen (in welcher Richtung auch immer), die 
man mittels eines geeigneten Protokolls herauswirft.

Bei einem VCP geht das anders. Zieht man da das Kabel und steckt es 
wieder, dann ist auf der PC-Seite die vormalige Verbindung getrennt und 
sie verbindet sich auch nicht wieder von selbst. Sowas muß man dann im 
PC-Programm selbst machen, nachdem das OS mit allem Gedöns wie 
Enumeration etc. fertig ist.

Das muß man eben auf der PC-Seite beachten.

Auf der Geräteseite muß man ohnehin bei Anwendungen, die irgendwelche 
längeren Prozesse beinhalten, von vornherein eine Strategie einbauen, 
was das Gerät denn tun soll, wenn die Verbindung zum PC mal stockt oder 
gar abreißt.

Viele Bastler hier im Forum denken an so etwas überhaupt nicht - bis 
hin, daß sie irgendwelche daten rein binär übertragen wollen.



> Danke für den WinUSB Hinweis. Das nehme ich mal in die Liste auf.

Lieber nicht. Sowas geht in Richtung Frickelei.

W.S.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

W.S. schrieb:
> Auf der Geräteseite muß man ohnehin bei Anwendungen, die irgendwelche
> längeren Prozesse beinhalten, von vornherein eine Strategie einbauen,
> was das Gerät denn tun soll, wenn die Verbindung zum PC mal stockt oder
> gar abreißt.

Das ist zum Glück im Gegensatz zu UART sehr leicht zu erkennen - am 
Ausbleiben der SOF Pakete und entsprechenden Interrupts durch die 
USB-Peripherie.

W.S. schrieb:
> Viele Bastler hier im Forum denken an so etwas überhaupt nicht - bis
> hin, daß sie irgendwelche daten rein binär übertragen wollen.

Warum auch nicht? Binär ist leichter, effizienter und eindeutiger zu 
parsen, und die übertragenen Daten werden sowieso nie ungeparst 
angezeigt. Die durch die USB-Spezifikation vorgegebenen Datenformate 
(insb. Deskriptoren) sind auch alle binär.

W.S. schrieb:
> Lieber nicht. Sowas geht in Richtung Frickelei.

Warum? Damit habe ich nur gute Erfahrungen gemacht. Nicht jeder kann 
sich die Entwicklung richtiger Treiber mit Zertifikat leisten.

: Bearbeitet durch User
Bitte 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
Noch kein Account? Hier anmelden.
Lade...