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
HID geht in beide Richtungen. Habe schon mit dem CP2110 gearbeitet (quasi ein cp2102 als HID)
Gast
#5931039
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.
Gast
#5931099
Sebastian R. schrieb: > CDC > + keine Treiber nötig (ab Win10) Wie siehts mit Rueckwaertskompatibilitaet aus? Win7/8? Da koennte ein FTDI einfacher sein.
Gast
#5931119
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 von einem Moderator gelöscht.
Gast
#5931136
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.
Gast
#5931152
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
Gast
#5931168
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.
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
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
Gast
#5931638
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
Gast
#5931642
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.
Gast
#5931650
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
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.
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
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.
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 ;)
Gast
#5931739
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.
Gast
#5932179
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
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.
Gast
#5932399
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.
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.
Gast
#5934065
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.
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.