Ich suche nach einer Liste von AVRs, die USB per Hardware unterstützten.
Die Microchip Seite ist keine große Hilfe. Alles, was ich finden kann,
ist "AVR Microcontrollers Peripheral Integration" [1], welche nur
ATmega8/16/32U2 und ATmega16/32U4 listet.
Hinzu kommen DU Devices wie AVR64DU32.
Die Frontseite der AVR-LibC v2.1.0 listet unter USB:
1
at90usb82
2
at90usb162
3
at90usb646
4
at90usb647
5
at90usb1286
6
at90usb1287
7
atmega8u2
8
atmega16u2
9
atmega16u4
10
atmega32u2
11
atmega32u4
12
atmega32u6
also etwas veraltet. Dann gibt's noch avr-mmcus.def [3], wo man nach
RMW suchen kann, weil (einige? alle?) Xmega USB Devices RMW
unterstützen.
Johann L. schrieb:> Unterstützen die alle USB?
Nur die hinten mit u
> Oder vielleicht ist jemand besser darin, ne Liste im Netz zu finden.
Ich fürchte Deine Liste ist schon halbwegs vollständig.
Was genau ist an ATMega*U veraltet? Sind doch noch in Produktion...
Ansonsten gäbe es noch die AVR*DU, z.B. den AVR16DU14, der ist so
brandneu, denn gibts noch nicht mal zu kaufen. Aus dieser Reihe sind bis
dato nur der AVR64DU28 und AVR64DU32 verfügbar
Johann L. schrieb:> ber der hat hinten kein U.
Stimmt. Und trotzdem USB.
Bin selber überrascht. Ein Bruch in der Systematik.
Auf jeden Fall haben aber alle USB mit u hinten und Zahl davor.
Andreas M. schrieb:> Was genau ist an ATMega*U veraltet?
Nix ist veraltet. Nur ist zu erwarten daß sie die nächsten im
Seniorenheim sind... Adäquaten Ersatz hast Du ja genannt.
Welche Voraussetzungen müssen eigentlich am PC erfüllt sein wenn man
dort Daten, praktischerweise über eine virtuelle serielle COM
Schnittstelle, via USB in Empfang nehmen möchte?
Gerhard H. schrieb:> Welche Voraussetzungen müssen eigentlich am PC erfüllt sein
Der PC muss USB haben. Und einen Treiber für das gewünschte Protokoll.
Für virtuelle Serialports (VCP) nimmt man typischerweise das USB-CDC-ACM
Protokoll, welches alle gängigen Betriebssysteme unterstützen.
IMO sind solche VCPs eine Krücke welche die Nachteile von USB mit den
Nachteilen von Serialports verbinden, flexibler, leistungsfähiger und
einfacher zu handlen sind eigene "native" USB-Protokolle.
Niklas G. schrieb:> Und einen Treiber für das gewünschte Protokoll.
Ist das Bestandteil üblicher Software für virtuelle COM-USB
Schnittstellen?
Oder in irgend einer Weise zu implementieren ab USB Sender im
Controller?
> IMO sind solche VCPs eine Krücke welche die Nachteile von USB mit den> Nachteilen von Serialports verbinden, flexibler, leistungsfähiger und> einfacher zu handlen sind eigene "native" USB-Protokolle.
Das mag gut sein- ich möchte aber auf PC-Seite nichts weiter entwickeln
müssen. Es würde ja auch nur um eine für USB lächerlich kleine Datenrate
gehen.
Gerhard H. schrieb:> Ist das Bestandteil üblicher Software für virtuelle COM-USB> Schnittstellen?
Das ist im Betriebssystem implementiert (Windows, Linux, Mac OS). Unter
Windows heißt die Datei z.B. usbser.sys. Auf Anwendungsebene ist es
(nahezu - bis auf das Timing) egal ob es ein "klassischer" oder
virtueller serieller Port ist.
Gerhard H. schrieb:> Oder in irgend einer Weise zu implementieren ab USB Sender im> Controller?
Auf dem Mikrocontroller muss man das natürlich selbst implementieren.
Für die STM32 und auch ESP32 gibt es fertige Bibliotheken die das tun,
für AVR weiß ich nicht. Es ist aber nicht schwer umzusetzen. Weil ja
keine echte serielle Übertragung im Spiel ist, braucht man sich um
Baudrate und Flusskontrolle keine Gedanken zu machen.
Niklas G. schrieb:> Es ist aber nicht schwer umzusetzen.
Na prima. Nach Deinen Infos gehe ich jetzt mal davon aus daß die nötige
Programmierung mit der auf meinem AVR Controller getan ist- und werde
nach entsprechenden Anleitungen Ausschau halten. Irgendwelche Libs
kommen nicht infrage da das in Assembler pur geschehen soll. Danke.
Niklas G. schrieb:> IMO sind solche VCPs eine Krücke welche die Nachteile von USB mit den> Nachteilen von Serialports verbinden, flexibler, leistungsfähiger und> einfacher zu handlen sind eigene "native" USB-Protokolle.
Was denn für Nachteile? USB ACM/CDC ist eigentlich der einfachste Weg,
der auch am wenigsten Aufwand am Betriebssystem erfordert. Denn das ist
nämlich genau das Problem wenn ich ein nicht Standardisiertes USB
Protokoll verwende, ich muss einen Treiber im Betriebssystem
integrieren, bei Linux geht das noch halbwegs einfach, bei Windows ist
das ganz großer Spaß, der Treiber muss nämlich signiert werden. Über
Apple sprechen wir gar nicht erst (Es hat schon einen Grund warum sich
Class Compliant USB immer mehr durchsetzt)
Bei CDC/ACM taucht das Gerät halt einfach als COM Port auf.
Geschwindigkeitseinbußen gibt es keine im Vergleich zu einem eigenen
Protokoll. Und noch viel besser, CDC/ACM funktioniert auch an einem
Smartphone ohne irgend welchen Firlefanz.
Andreas M. schrieb:> bei Windows ist> das ganz großer Spaß, der Treiber muss nämlich signiert werden.
Das hatte ich auch noch irgendwo im Hinterkopf.
Gut möglich daß es bei meiner bevorzugten drahtlosen Anbindung bleibt,
die ist nämlich sehr simpel über entsprechende, seriell ansprechbare
Funkmodule bewerkstelligt (z.B. XBee).
Gerne hätte ich aber die Technologie drahtgebundener USB-Verbindung noch
mit im Hause bzw. meiner Code-Sammlung. Zumal neue AVR-Controller mit
USB (AVR64DUxx) frisch auf dem Markt sind...
Gerhard H. schrieb:> und werde> nach entsprechenden Anleitungen Ausschau halten.
Vielleicht hilft ja meine:
https://www.mikrocontroller.net/articles/USB-Tutorial_mit_STM32#Virtueller_COM-PortGerhard H. schrieb:> Irgendwelche Libs> kommen nicht infrage da das in Assembler pur geschehen soll
Uff, na dann viel Spaß. Das USB-Grundprotokoll erfordert schon einiges
an Statemachines und Auswerten von Nachrichten. Da kann man sich in
Assembler schon gehörig verzetteln, das sind einige Tausend Zeilen. Das
macht in C schon keinen Spaß. Ich würde es mindestens erst einmal in C
umsetzen um die Funktionsweise zu kennen und wenn's denn unbedingt sein
muss dann nochmal in Assembler, insbesondere bei einer
Gerhard H. schrieb:> lächerlich kleine DatenrateAndreas M. schrieb:> Was denn für Nachteile?
Die hast die Nachteile von USB:
- Mehr Aufwand in der Controller-Software
- Controller mit USB benötigt
- ggf. Stromverbrauch?
Und die Nachteile vom Serialport:
- Puffersteuerung macht der Host-Treiber (usbser), was teilweise schwer
zu steuern ist und schnell mal Probleme beim Timing erzeugt und das
Umsetzen von paketbasierten Protokollen erschwert
- Auf PC-Seite den Anfang von Paketen finden, wenn das Gerät
kontinuierlich sendet, ist unschön
- Du hast nur einen Kanal (statt mehreren wie bei nativen
USB-Protokollen)
- Der User muss den Serialport in der Anwendung auswählen - erklär mal
einem Ottonormaluser dass er im Gerätemanager schauen soll welcher
COM-Port jetzt zum Gerät gehört, und warum der jedes Mal anders ist
(außer man hat eine Serialnummer)
- Gerät ist im Gerätemanager nicht leicht zu identifizieren
- In der PC-Anwendung mindestens genau so viel Code nötig wie für USB,
für plattformunabhängige Ansteuerung braucht man genauso eine Library
Spezielle Nachteile von usbser:
- Teilweise gehen Bytes verloren, usbser scheint nicht sehr stabil zu
sein
- Die Vorteile von USB, nämlich einfache elegante Fluss/Paket-Steuerung,
vordefinierte einfache Kommando-Struktur, mehrere parallele Kanäle kann
man nicht nutzen
Andreas M. schrieb:> ich muss einen Treiber im Betriebssystem> integrieren, bei Linux geht das noch halbwegs einfach, bei Windows ist> das ganz großer Spaß
Nö, das geht 100% auf Anwendungsebene.
Andreas M. schrieb:> bei Windows ist> das ganz großer Spaß, der Treiber muss nämlich signiert werden
Nein, dank WinUSB+libusb kann man super einfach aus der Anwendungseben
direkt auf das Gerät zugreifen, genau wie unter linux. Man braucht nur
einen speziellen Deskriptor im Gerät.
Andreas M. schrieb:> nd noch viel besser, CDC/ACM funktioniert auch an einem> Smartphone ohne irgend welchen Firlefanz.
Natives USB auch, zumindest unter Android (UsbManager). Geht sogar noch
besser als Serialport, man kann z.B. die eigene App automatisch starten
lassen wenn das eigene Gerät verbunden wird.
Niklas G. schrieb:> Uff, na dann viel Spaß.> das sind einige Tausend Zeilen
Du machst mir aber Mut :)
Ich hätte die Hardware-Unterstützung auf Controller-Seite
leistungsfähiger eingeschätzt!
Gerhard H. schrieb:> Ich hätte die Hardware-Unterstützung auf Controller-Seite> leistungsfähiger eingeschätzt!
Naja, es macht halt keinen Sinn das High-Level-Protokoll in Hardware
umzusetzen, weil das in Software viel besser geht. Es implementiert ja
auch keiner TCP/IP in Hardware weil die Software in Assembler
geschrieben werden soll...
Christoph db1uq K. schrieb:> Sind das alle
Nein. Die hat der TO in seiner Liste oben schon vollständig im Angebot.
Niklas G. schrieb:> Naja, es macht halt keinen Sinn das High-Level-Protokoll in Hardware> umzusetzen, weil das in Software viel besser geht.
OK. Mehrere Tausend Zeilen sind aber schon der Hammer.
Gerhard H. schrieb:> Mehrere Tausend Zeilen sind aber schon der Hammer.
In C++ sind's viel weniger 😁 USB (insbesondere USB 1.1) ist noch relativ
harmlos, es gibt wesentlich komplexere Protokolle...
Niklas G. schrieb:> es gibt wesentlich komplexere Protokolle...
Zumindest eine simple Datenverbindung hätte ich mir besser von der
Hardware supported gewünscht. Nun, mal schauen was die frische AVR
USB-Hardware dazu so anbietet. Wenn das zur Wissenschaft ausartet werd'
ich es aber bleiben lassen.
Gerhard H. schrieb:> Zumindest eine simple Datenverbindung hätte ich mir besser von der> Hardware supported gewünscht
Wozu, treibt nur den Preis nach oben, kann nachträglich nicht abgeändert
werden, schwer in Software zu erweitern, ein paar KiB mehr Flash sind
billiger.
Der Aufwand für "simple Datenverbindung" und "komplexe Datenverbindung"
ist ähnlich. Beide brauchen Deskriptoren und das Enumerationsprotokoll.
Die Tabelle ist seltsam, wenn ich "Number of USB Modules"=1 auswähle
gibt es 37 Typen. Dann steht aber bei vielen "USB-Interface" none, ich
hatte da vorher nur "Full speed"
Niklas G. schrieb:> schwer in Software zu erweitern
Dafür hab ich keinerlei Bedarf.
Die Grundfunktionalität, ein paar Daten in und her sausen zu lassen
langt völlig. Ohne Anspruch auf zig MByte und MBit...
> Der Aufwand für "simple Datenverbindung" und "komplexe Datenverbindung"> ist ähnlich. Beide brauchen Deskriptoren und das Enumerationsprotokoll.
Da muß ich mich ehrlicherweise erstmal einlesen. Danke Niklas.
Christoph db1uq K. schrieb:> Die Tabelle ist seltsam
Also um gleich den ersten ATxmega128A4U zu nehmen: USB-Interface = none
ist schonmal definitiv falsch.
Gerhard H. schrieb:> Dafür hab ich keinerlei Bedarf.
Aber andere AVR-Kunden schon...
Gerhard H. schrieb:> Die Grundfunktionalität, ein paar Daten in und her sausen zu lassen> langt völlig.
Das Gerät muss sich aber erst einmal beim PC enumerieren, und das ist
ein relativ komplexer Vorgang. Das lässt sich nicht umgehen.
Selbst die V-USB Implementation nutzt Assembler nur für das Bitbanging,
das High-Level-Protokoll ist C.
Niklas G. schrieb:> Das Gerät muss sich aber erst einmal beim PC enumerieren, und das ist> ein relativ komplexer Vorgang. Das lässt sich nicht umgehen.
Das heißt also wenig Hoffnung, daß dieser Vorgang von Hardware überhaupt
unterstützt werden kann...
Gerhard H. schrieb:> Das heißt also wenig Hoffnung, daß dieser Vorgang von Hardware überhaupt> unterstützt werden kann...
Theoretisch schon. Aber sinnvoll/kosteneffektiv? Eher nicht.
Die ESP32S3 haben einen "Hardwired" USB-VCP implementiert. Ich vermute
aber dass da auch ein extrem simpler Prozessor mit ROM-Programm drin
steckt. Den ESP32 in Assembler zu programmieren macht allerdings
überhaupt keinen Sinn.
Niklas G. schrieb:> Den ESP32 in Assembler zu programmieren macht allerdings> überhaupt keinen Sinn.
Na das glaub ich aber auch!
> Aber sinnvoll/kosteneffektiv?
Aus meiner Sicht jedenfalls.
Und ich glaube schon daß das für eine hohe Prozentzahl an Anwendungen
ausreichen würde. Aber wie üblich macht es der Anspruch auf sehr viel
mehr Flexibilität sehr viel mehr kompliziert.
Hier mal die zur USB-Hardware gehörigen Register eines AVR64DU.
Ist ja noch halbwegs überschaubar.
.equ USB0_CTRLA = 0x0C00 ; Control A
.equ USB0_CTRLB = 0x0C01 ; Control B
.equ USB0_BUSSTATE = 0x0C02 ; Bus State
.equ USB0_ADDR = 0x0C03 ; Address
.equ USB0_FIFOWP = 0x0C04 ; FIFO Write Pointer
.equ USB0_FIFORP = 0x0C05 ; FIFO Read Pointer
.equ USB0_EPPTR = 0x0C06 ; Endpoint Configuration Table
Pointer
.equ USB0_EPPTRL = 0x0C06 ; Endpoint Configuration Table
Pointer low byte
.equ USB0_EPPTRH = 0x0C07 ; Endpoint Configuration Table
Pointer hi byte
.equ USB0_INTCTRLA = 0x0C08 ; Interrupt Control A
.equ USB0_INTCTRLB = 0x0C09 ; Interrupt Control B
.equ USB0_INTFLAGSA = 0x0C0A ; Interrupt Flags A
.equ USB0_INTFLAGSB = 0x0C0B ; Interrupt Flags B
.equ USB0_STATUS0_OUTCLR = 0x0C40 ; Endpoint n OUT Status Clear
.equ USB0_STATUS0_OUTSET = 0x0C41 ; Endpoint n OUT Status Set
.equ USB0_STATUS0_INCLR = 0x0C42 ; Endpoint n IN Status Clear
.equ USB0_STATUS0_INSET = 0x0C43 ; Endpoint n IN Status Set
...
.equ USB0_STATUS15_OUTCLR = 0x0C7C ; Endpoint n OUT Status Clear
.equ USB0_STATUS15_OUTSET = 0x0C7D ; Endpoint n OUT Status Set
.equ USB0_STATUS15_INCLR = 0x0C7E ; Endpoint n IN Status Clear
.equ USB0_STATUS15_INSET = 0x0C7F ; Endpoint n IN Status Set
Gerhard H. schrieb:> Und ich glaube schon daß das für eine hohe Prozentzahl an Anwendungen> ausreichen würde.
Ich nicht. Die allermeisten Anwendungen werden Custom Deskriptoren haben
wollen und eigene Befehle implementieren (inkl. VCP!). Und bei sehr
vielen Anwendungen kommt es auf den Preis an. Ein teurerer Controller
der im Endeffekt weniger kann (wegen geringerer Flexibilität) nur damit
man in Assembler arbeiten kann spricht ein sehr kleines Publikum an.
Gerhard H. schrieb:> Ist ja noch halbwegs überschaubar.
Ja. Aber wie gesagt, die Komplexität steckt im High-Level-Protokoll. In
C sind es ca. 1000-2000 Zeilen; in Assembler, wo jeder Speicherzugriff
ein Tanz aus 16bit-Berechnungen ist, noch einige mehr.
Niklas G. schrieb:> nur damit> man in Assembler arbeiten kann spricht ein sehr kleines Publikum an.> In> C sind es ca. 1000-2000 Zeilen; in Assembler, wo jeder Speicherzugriff> ein Tanz aus 16bit-Berechnungen ist, noch einige mehr.
Das weckt zwar meinen Ehrgeiz aber ich denke, für's erste ist es besser,
das nicht zu bestreiten :)
Alles in allem macht es die USB-Schnittstelle aus (meiner)
Entwickler-Sicht nicht attraktiver.
Gerhard H. schrieb:> Alles in allem macht es die USB-Schnittstelle aus (meiner)> Entwickler-Sicht nicht attraktiver
Naja, die meisten verwenden einfach eine fertige Library, meistens in C.
Das ist gut machbar. Im Endeffekt ist es billiger und für den User sehr
komfortabel dank Enumeration und Plug'n'Play.
Niklas G. schrieb:> Naja, die meisten verwenden einfach eine fertige Library, meistens in C.> Das ist gut machbar. Im Endeffekt ist es billiger und für den User sehr> komfortabel dank Enumeration und Plug'n'Play.
Ein Hoch auf die Hochsprache :)
Ich hoffe trotzdem noch auf eine simplere Umsetzung. Das Anstecken
meines Controllers soll einen virtuellen COM-Port zum Datenaustausch
bereitstellen- mehr brauchts nicht. Es hilft auch wenig, wenn die
begrenzten Ressourcen eines AVR bereits zum guten Teil durch das
USB-Handling belegt würden.
Gerhard H. schrieb:> Das Anstecken> meines Controllers soll einen virtuellen COM-Port zum Datenaustausch> bereitstellen- mehr brauchts nicht
Der PC muss halt wissen dass es ein VCP sein soll. Das erfordert eine
Enumeration.
Gerhard H. schrieb:> Es hilft auch wenig, wenn die> begrenzten Ressourcen eines AVR bereits zum guten Teil durch das> USB-Handling belegt würden.
Zum Glück gibt's eine Unzahl an leistungsfähigeren Controllern mit
USB... Dass nur so wenige AVR's USB haben ist schon nicht mehr
zeitgemäß, bei anderen Controllerfamilien gehört USB zur
Quasi-Standardausstattung.
Niklas G. schrieb:> Dass nur so wenige AVR's USB haben ist schon nicht mehr> zeitgemäß
Ich würde an dieser Stelle vorsichtig die Frage stellen, wie zeitgemäß
drahtgebundene Interfaces für Datenübertragungen geringeren Speeds
überhaupt noch sind. Nicht nur, daß die Umsetzung via Funk viel
einfacher ist. Vor allem aber ist die mögliche Mobilität der Hardware
hier der Riesenvorteil.
> bei anderen Controllerfamilien gehört USB zur> Quasi-Standardausstattung
Das soll es und darf es ja gerne, wenn USB ein (beanspruchtes)
Standard-Interface der App sein soll. Mit der Beanspruchung durch
Datenvolumen und Speed sieht es bei 8Bit Apps naturgemäß sowieso
bescheidener aus.
Gerhard H. schrieb:> Ich würde an dieser Stelle vorsichtig die Frage stellen, wie zeitgemäß> drahtgebundene Interfaces für Datenübertragungen geringeren Speeds> überhaupt noch sind.
Tja, im Consumer-Bereich kaum noch. Höchstens für stationäre
Anwendungen. USB-Geräte explizit für Smartphones sind eine absolute
Nische.
Gerhard H. schrieb:> Nicht nur, daß die Umsetzung via Funk viel einfacher ist
Naja, Funkprotokolle sind schon deutlich komplexer, insbesondere WiFi
und auch Bluetooth. Man benutzt nur halt vorgefertigte Komponenten
dafür. Kann man bei USB auch.
Gerhard H. schrieb:> Also um gleich den ersten ATxmega128A4U zu nehmen: USB-Interface = none> ist schonmal definitiv falsch.
USB-Module != USB-Interface ;)
Niklas G. schrieb:> Naja, Funkprotokolle sind schon deutlich komplexer, insbesondere WiFi> und auch Bluetooth. Man benutzt nur halt vorgefertigte Komponenten> dafür. Kann man bei USB auch
Sicherlich. Nur wenn bereits USB-Hardware vorhanden ist liegt es
natürlich nahe die zu nutzen.
Grundsätzlich ließe sich genauso eine serielle Verbindung mit
Seriell/USB Adapter am PC verwenden, was den Software-Aufwand einer
nativen USB Verbindung für den angedachten Einsatz nochmal ordentlich
relativiert...
M. K. schrieb:> USB-Module != USB-Interface ;)
Wo liegt im Sinne obiger Tabelle der Unterschied? Ohne USB-Hardware kein
USB Interface und umgekehrt ...!?
Gerhard H. schrieb:> Grundsätzlich ließe sich genauso eine serielle Verbindung mit> Seriell/USB Adapter am PC verwenden
Da hat man dann aber noch weniger Flexibilität und mehr
Bauteile-Aufwand.
Ich habe bisher immer USB-UART Chips oder CDC Firmware verwendet, weil
ich dazu keine eigene Device-ID benötige. Das ist offenbar für's Hobby
zu teuer.
https://www.usb.org/getting-vendor-id
Man kann dem virtuellen Port (bei CDC Firmware) einen Namen geben,
anhand dessen das Gerät erkennbar wird.
Niklas G. schrieb:> Da hat man dann aber noch weniger Flexibilität und mehr> Bauteile-Aufwand.
Klar. Aus praktischen Gründen wiegt so ein 3 Euro Adapter aber den
Softwareaufwand für den beschriebenen Zweck problemlos auf. Irgendwie
natürlich trotzdem schade um die brachliegende USB Hardware...
Steve van de Grens schrieb:> Ich habe bisher immer USB-UART Chips oder CDC Firmware verwendet, weil> ich dazu keine eigene Device-ID benötige. Das ist offenbar für's Hobby> zu teuer.
Und noch ein Argument gegen USB pur ?!
Vielleicht hätte ich noch dazu sagen sollen daß es "nur" um
Hobby-Einsatz geht.
Gerhard H. schrieb:> Vielleicht hätte ich noch dazu sagen sollen daß es "nur" um> Hobby-Einsatz geht.
Im Hobby-Einsatz kann man sich auch bei wahrscheinlich nie genutzten IDs
bedienen, 0xDEAD : 0xBEEF oder so. Man sollte sie nur leicht ändern
können.
Steve van de Grens schrieb:> USB-UART Chips
Aber ob die Firmware da drin in Assembler implementiert ist?!?!
Gerhard H. schrieb:> Irgendwelche Libs kommen nicht infrage da das in Assembler> pur geschehen soll.
Und warum? Um "moby" zu gefallen? Warum sonst sollte man die Lebenszeit
dafür verschwenden?
Harald K. schrieb:> Warum sonst sollte man die Lebenszeit dafür verschwenden?
Nun Harald, das wär erstens nicht Dein Problem und zweitens ist mir in
diesem Thread einiges klargeworden.
Die Umsetzung hätte ich mir eben einfacher vorgestellt. Ich hoffe das
ist keine Schande.
Evt. bietet Microchip da in den nächsten Monaten ein paar gute
Support-Dokumente zum neuen AVR-DU die das noch etwas einladender
beleuchten.
An USB CDC ist nix kompliziert. Die Implementierung ist lächerlich
einfach, das Aufwändigste ist der CDC Device-Descriptor. Device/Vendor
ID schnappt man sich fürs Hobby einfach irgend eine von
https://github.com/obdev/v-usb/blob/master/usbdrv/USB-IDs-for-free.txt
Da ist sogar eine für CDC-ACM vorgeschlagen. Der Vorteil wenn man ein
Class-Compliant Gerät, als z.B. CDC implementiert ist ja gerade, das die
IDs eigentlich keine Rolle spielen.
Es gibt auch einige Vendor-IDs die quasi verbrannt sind, weil die
Unternehmen nicht mehr existieren. Die kann ebenfalls problemlos für
Hobby benutzen, da diese Unternehmen natürlich keine Product IDs mehr
vergeben können und die Vendor ID auch nicht neu vergeben werden kann,
da es ja noch Produkte/Treiber gibt...
Andreas M. schrieb:> Die Implementierung ist lächerlich einfach
Nicht für jeden, und auch nichT auf jedem Mikrocontroller (z.B.
STM32F103).
Das ist durchaus ein Thema für weit Fortgeschrittene, sofern es keine
copy-pasta werden soll.
Steve van de Grens schrieb:> Nicht für jeden, und auch nichT auf jedem Mikrocontroller (z.B.> STM32F103).
Da muss man jetzt unterscheiden:
Implementation des USB-Treibers, also Senden/Empfangen von Paketen,
Enumerationsprozedur, Bulk-Protokoll: Schon ein gewisser Aufwand, einige
Details die beachtet werden möchten, längliche Statemachines. Das
resultiert in den erwähnten tausenden Zeilen Code.
Implementation von USB-CDC-ACM:
Ziemlich simpel *auf Basis des o.g. Treibers*, solange die Daten nur
intern verarbeitet werden. Wenn ein tatsächlicher UART im Spiel ist ist
das Handling der Baudrate, Flusskontrolle und
Doppel/Ring-Puffer-Implementation auch eine gewisse Fummelei.
Das Erste in C und das zweite in Assembler zu machen wäre auch
ziemlicher Quatsch.
Niklas G. schrieb:> Uff, na dann viel Spaß. Das USB-Grundprotokoll erfordert schon einiges> an Statemachines und Auswerten von Nachrichten. Da kann man sich in> Assembler schon gehörig verzetteln
Ach watt, wenn man flüssig Asm programmieren kann, sind Statemachines
und das Parsen von Strukturen doch keine Problem. Ja, es werden schon
etliche Zeilen mehr werden als bei einer Umsetzung in C, aber sicher
nicht mal doppelt so viele.
> das sind einige Tausend Zeilen.
Ooops. Mein CDC-Device in Asm braucht nicht einige tausend Zeilen,
sondern nur wenige hundert.
Und ein großer Teil davon geht für die ganzen Hilfsmakros drauf, die ich
mir gebastelt habe, um komfortabel USB-Deskriptoren schreiben zu können.
Und ein weiterer recht signifikanter Teil für eben diese Deskriptoren
selber. Die Zeilen für tatsächlichen Code sind deutlich weniger als ein
Drittel der Gesamtzeilenzahl.
> - Controller mit USB benötigt
Nicht zwingend. Inzwischen gibt es sogar Lösungen für Fullspeed ohne
dedizierte USB-Hardware (für AVRnDA/B). Ist aber eine üble Bastelei auf
allen Ebenen. Kann man reproduzierbar zum Laufen bringen, aber der Weg
dahin ist doch recht steinig. Wenig empfehlenswert.
> Und die Nachteile vom Serialport:> - Puffersteuerung macht der Host-Treiber (usbser), was teilweise schwer> zu steuern ist
Nicht wirklich. Gerade unter Windows ist das wirklich sehr schön und
vorbildlich über ein vereinheitlichtes API möglich. Das uralte COMM-API
wird von usbser.sys hervorragend umgesetzt. Natürlich nur im Rahmen der
Möglichkeiten, die USB an sich bietet. Denen allerdings dedizierte
USB-Hardware genauso unterliegt.
> und das> Umsetzen von paketbasierten Protokollen erschwert
Das hängt einzig davon ab, wie geschickt man die "Paketierung" erledigt.
> - Auf PC-Seite den Anfang von Paketen finden, wenn das Gerät> kontinuierlich sendet, ist unschön
Auch dafür gilt: Das hängt einzig davon ab, wie geschickt man die
"Paketierung" erledigt.
> - Du hast nur einen Kanal (statt mehreren wie bei nativen> USB-Protokollen)
Tja "Kanäle" muß man tatsächlich eine Ebene höher (also selber)
implementieren, wenn CDC verwendet. So what? Auf der Strippe werden auch
die USB-"Kanäle" immer schön nacheinander abgehandelt. Es gibt nämlich
nur die eine...
> - Der User muss den Serialport in der Anwendung auswählen
Das ist völliger Quatsch. Genauso, wie man der Anwendung beibringen
kann, ein proprietäres USB-Device zu verwenden, kann man ihr auch
beibringen, einen bestimmten COM-Port anhand der Device-Eigenschaften
(VID:PID:SERIAL) zu wählen. Und ja: das geht natürlich auch, wenn der
Klassentreiber für das Device verwendet wird.
Nur, weil du sowas vielleicht nicht kannst, heißt das nicht, das es
nicht möglich wäre...
> - Gerät ist im Gerätemanager nicht leicht zu identifizieren
Genau so'n Quatsch. Es ist das Gerät, was dort erscheint, wenn ich es
einstöpsele. Aber da die Auswahl ja, wie gesagt, problemlos automatisch
durch die Anwendung erfolgen kann, gibt es für den Anwender ja gar keine
Notwendigkeit, überhaupt in den Gerätemanager zu schauen.
> Spezielle Nachteile von usbser:> - Teilweise gehen Bytes verloren, usbser scheint nicht sehr stabil zu> sein
Kann ich absolut nicht bestätigen. Das wäre mir sicher schon
aufgefallen. Und vielen Millionen anderen Leuten sicher ebenfalls ;o)
Nö, der wesentliche Nachteil von USB-CDC unter Windows ist diese
Situation: COM-Port geöffnet und heftig in Benutzung, aber das USB-Gerät
wird plötzlich "abgemeldet". Sei es durch EM-Störungen oder dadurch,
dass DAU-Dummdödel das Gerät einfach abstöpselt. Mit dieser Situation
kommt Windows selber wirklich garnicht gut klar.
Und Anwendungen muss man wirklich sehr mühsam beibringen, diese
Situation zu erkennen und aufzulösen, weil das OS da praktisch keine
Hilfestellung gibt.
Ob S. schrieb:> Nicht zwingend. Inzwischen gibt es sogar Lösungen für Fullspeed ohne> dedizierte USB-Hardware (für AVRnDA/B).
Magst Du einen Link nennen? Das wäre ja eine attraktive Erweiterung von
V-USB, die endlich auch eine spezifikationskonforme
CDC-Implementierung erlauben würde (denn das ist mit dem von V-USB
verwendeten Low-Speed-USB nicht drin und wird nur von manchen
Betriebssystemen toleriert).
Ob S. schrieb:> Ooops. Mein CDC-Device in Asm braucht nicht einige tausend Zeilen,> sondern nur wenige hundert.
Na dann zeig mal her!
Ob S. schrieb:> Gerade unter Windows ist das wirklich sehr schön und> vorbildlich über ein vereinheitlichtes API möglich.
Wie kann ich dem Treiber sagen, dass er ein einzelnes Byte sofort vom
Controller in die Anwendung befördern soll, ohne es irgendwo (inklusive
auf dem Controller) zu puffern? Dabei auch gern die Timeouts präzise
beachten?
Ob S. schrieb:> Das hängt einzig davon ab, wie geschickt man die> "Paketierung" erledigt.
Das geschickt zu machen ist aber Fummelei.
Ob S. schrieb:> So what?
Mehr Aufwand.
Ob S. schrieb:> ann man ihr auch> beibringen, einen bestimmten COM-Port anhand der Device-Eigenschaften> (VID:PID:SERIAL) zu wählen.
Wie macht man das portabel? PS: Wie sorgt man dafür, dass nicht
irgendeine andere Anwendung versehentlich drauf zugreift? Wie z.B. der
ModemManager unter Linux das bei allen Serial-Ports macht?
Ob S. schrieb:> Nur, weil du sowas vielleicht nicht kannst, heißt das nicht, das es> nicht möglich wäre...
Klar, alles andere am USB-Protokoll ist kein Problem, aber da ist meine
intellektuelle Kapazität erschöpft. Bei libUSB sind es jedenfalls ein
paar Zeilen und automatisch portabel.
Ob S. schrieb:> Es ist das Gerät, was dort erscheint, wenn ich es> einstöpsele.
Total nutzerfreundlich.
Ob S. schrieb:> Kann ich absolut nicht bestätigen. Das wäre mir sicher schon> aufgefallen. Und vielen Millionen anderen Leuten sicher ebenfalls ;o)
Kann auch am miese implementierten ST-Link-VCP liegen, oder an den
.NET-Serial-Klassen. Jedenfalls hatte ich solche Probleme bei nativem
USB nie (kann da nämlich prinzipbedingt nicht auftreten).
Ich habe leider kein Beispiel für AVRs, weil ich bei Kleinzeugs USB fast
nur noch Chinesische CH552 einsetze, die sind 8051 basiert. Musste jetzt
etwas suchen für ein Projekt wo nur CDC drauf ist. Irgendwie hab ich
vorwiegend Multi-Interface: CDC+HID, CDC+ULink.
Jedenfalls, hab ich vor einiger Zeit mal einen UPDI High-Voltage
Programmierer gebaut. Das ist im Prinzip USB<->RS232 dazu noch eine
Ladepumpe für die Spannung, letzteres habe ich bisher aber noch nicht
wirklich gebraucht.
Also 938 Zeilen, hört sich viel an, das Teil macht aber auch
Double-Buffer in beide Richtungen, also während der eine Puffer über
UART rausgeht kann über USB schon das nächste Paket kommen. Der Code
könnte mal aufgeräumt werden, ein Großteil der "Anweisungen" sind auch
einfach nur Registerzugriffe, das Projekt enthält sogar etwas ASM ;-)
(Kann leider nur wenige Standard-Baudraten, das liegt aber an den
Teilern / Takt des CH552, spielt aber für UPDI keine Rolle.)
https://gitlab.com/amesser-group/electronic-devices/usb-updi-hv
Niklas G. schrieb:> Na dann zeig mal her!
Nö.
> Wie kann ich dem Treiber sagen, dass er ein einzelnes Byte sofort vom> Controller in die Anwendung befördern soll, ohne es irgendwo (inklusive> auf dem Controller) zu puffern?
Naja, wirklich "sofort" geht natürlich über USB absolut garnix. USB
basiert auf Polling. Einigen wir uns also darauf, dass "sofort" bedeuten
soll: im nächstmöglichen USB-Cycle. Dann ist es so:
Das musst du dem "Controller" (gemeint ist wohl das USB-Device) das
einfach beibringen. Windows hat über alle Ebenen kein Problem damit.
Ist auch kein Problem für ein selbst implementiertes USB-Device.
Probleme ergeben sich diesbezüglich nur, wenn man's halt nicht selbst
macht...
> Wie macht man das portabel?
Wen interessiert's? >90% ist nunmal sowieso Windows. Für den Rest muss
man halt mit historischen Software-Blähungen wie termios(n) leben und
eine passende in seiner Software applizieren...
> PS: Wie sorgt man dafür, dass nicht> irgendeine andere Anwendung versehentlich drauf zugreift? Wie z.B. der> ModemManager unter Linux das bei allen Serial-Ports macht?
Das ist tatsächlich gelegentlich ein Problem, das muß ich schon zugeben.
Lösung: Rauschmeissen, diesen ganzen historischen Scheiß. Unter Windows
übrigens genauso. Auch da gibt es z.B. immer noch diese klägliche
Erkennung von seriellen Mäusen. Braucht kein Mensch mehr. Seit
Jahrzehnten schon nicht. Ist aber immer noch drinne. Weg mit diesen
Altlasten. Kein Problem unter Windows, kostet genau eine Zeile in der
Console mit Admin-Rechten...
> Ob S. schrieb:>> Nur, weil du sowas vielleicht nicht kannst, heißt das nicht, das es>> nicht möglich wäre...>> Klar, alles andere am USB-Protokoll ist kein Problem, aber da ist meine> intellektuelle Kapazität erschöpft.
Über SetupAPI oder WMI kannst du zu jedem COM-Port auch die
Eigenschaften des darunter liegenden USB-Device ermitteln. Unter Linux
läuft das übrigens ähnlich ab, nur findet man dort die Informationen
statt über bestimmte APIs halt über bestimmte Filesysteme. Das Prinzip
bleibt aber dasselbe.
Ist (OS)-proprietär. Muss man halt für jedes OS anders umsetzen.
"Portabilität" (im C-Sinne) kann man halt dadurch erreichen, dass man
eine lib für Windows und eine Lib für Linux mit gleichem Interface baut
und halt je nach Target die passende includiert. Normales Los eines
wirklichen Programmierers...
> Ob S. schrieb:>> Kann ich absolut nicht bestätigen. Das wäre mir sicher schon>> aufgefallen. Und vielen Millionen anderen Leuten sicher ebenfalls ;o)>> Kann auch am miese implementierten ST-Link-VCP liegen, oder an den> .NET-Serial-Klassen.
An letzterem sicher auch nicht, so viel kann ich schonmal garantieren.
Niklas G. schrieb:> irgendeine andere Anwendung versehentlich drauf zugreift? Wie z.B. der> ModemManager unter Linux das bei allen Serial-Ports macht?
Mittels einer UDEV Regel, hier für den teensy:
Ob S. schrieb:> Auch da gibt es z.B. immer noch diese klägliche Erkennung von seriellen> Mäusen
Die fuhrwerkt scheinbar auch noch ganz aktiv als Geist im Hintergrund.
Da gibts bei der Arbeit mit seriellen PC Ports zuweilen ganz
ungewöhnliche, geisterhafte Effekte- wenn sich etwa plötzlich der
Mauszeiger bewegt.
Ob S. schrieb:> Inzwischen gibt es sogar Lösungen für Fullspeed ohne> dedizierte USB-Hardware (für AVRnDA/B).
Ich wiederhole meine von Dir nicht beantwortete Frage von gestern:
Magst Du einen Link nennen? Das wäre ja eine attraktive Erweiterung von
V-USB, die endlich auch eine spezifikationskonforme
CDC-Implementierung erlauben würde (denn das ist mit dem von V-USB
verwendeten Low-Speed-USB nicht drin und wird nur von manchen
Betriebssystemen toleriert).
Ob S. schrieb:> Nö.
Also leere Behauptungen.
Ob S. schrieb:> Das musst du dem "Controller" (gemeint ist wohl das USB-Device) das> einfach beibringen.
Geht leider nur bei Geräten, bei denen kein echter UART im Spiel ist, wo
die USB-Firmware also die Paketgröße kennt. Bei USB-UART-Adaptern werden
Pakete gerne mal zerhackt und kommen mit komischem Timing an.
Ob S. schrieb:> Windows hat über alle Ebenen kein Problem damit.
Erfahrungsgemäß ist Windows nicht dazu in der Lage Timeouts einigermaßen
konsistent einzuhalten. Und es gibt eben Null Garantie dass Pakete am
Stück in der Anwendung ankommen. Natürlich kann man damit umgehen, aber
es ist eben Aufwand. Bei Nativ-USB entfällt das.
Ob S. schrieb:> Lösung: Rauschmeissen, diesen ganzen historischen Scheiß
CDC-ACM ist ja bekanntlich ausschließlich für Analog-Modems gemacht,
d.h. es ist vollkommen legitim für dem ModemManager auf alle ACM-Geräte
zuzugreifen, weil er korrektereweise annehmen kann, dass das alles
Modems sind.
Ob S. schrieb:> Kein Problem unter Windows, kostet genau eine Zeile in der> Console mit Admin-Rechten...
Was wenn es ein Normalo-User auf einem Unternehmensrechner ist, der
keine Adminrechte hat (sehr häufig)?
Ob S. schrieb:> dass man> eine lib für Windows und eine Lib für Linux mit gleichem Interface baut
Gibt's bei USB halt fix und fertig.
Andreas M. schrieb:> Mittels einer UDEV Regel, hier für den teensy:
Praktisch, hilft aber eben auch nur bei diesen spezifischen Anwendungen.
Bei Nativ-USB nicht nötig.
Thread beobachten
Seitenaufteilung abschalten