Forum: Mikrocontroller und Digitale Elektronik AVRs mit USB?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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.
1
awk -F\" '/RMW/  { print $2; }' avr-mcus.def
spuckt aus:
1
atxmega32c3
2
atxmega16a4u
3
atxmega16c4
4
atxmega32a4u
5
atxmega32c4
6
atxmega64a3u
7
atxmega64a4u
8
atxmega64b1
9
atxmega64b3
10
atxmega64c3
11
atxmega64a1u
12
atxmega128a3u
13
atxmega128b1
14
atxmega128b3
15
atxmega128c3
16
atxmega192a3u
17
atxmega192c3
18
atxmega256a3u
19
atxmega256c3
20
atxmega384c3
21
atxmega128a1u
22
atxmega128a4u

Unterstützen die alle USB?

Oder vielleicht ist jemand besser darin, ne Liste im Netz zu finden.
____________________________________________________________

[1] 
https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/Brochures/AVR-Microcontrollers-Peripheral-Integration-30010135.pdf
[2] https://www.nongnu.org/avr-libc/user-manual/index.html
[3] 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/avr/avr-mcus.def

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

...dann kann man in Device-Packs suchen (aber nicht nur nach USB, weil 
es z.B. für ATmega88 USBS gibt: "USART Stop Bit Select".)
1
grep -l '"USB"' atpack/microchip/atdf/*.atdf | awk -F'[/\.]' '{ print $4 }'
1
ATxmega128A1U
2
ATxmega128A3U
3
ATxmega128A4U
4
ATxmega128B1
5
ATxmega128B3
6
ATxmega128C3
7
ATxmega16A4U
8
ATxmega16C4
9
ATxmega192A3U
10
ATxmega192C3
11
ATxmega256A3BU
12
ATxmega256A3U
13
ATxmega256C3
14
ATxmega32A4U
15
ATxmega32C3
16
ATxmega32C4
17
ATxmega384C3
18
ATxmega384D3
19
ATxmega64A1U
20
ATxmega64A3U
21
ATxmega64A4U
22
ATxmega64B1
23
ATxmega64B3
24
ATxmega64C3
25
AVR64DU28
26
AVR64DU32

von Gerhard H. (hauptmann)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Aber zum Beispiel in ATxmega128B1.atdf gibt es:
1
<module name="USB" id="I3005" version="XMEGAAU">
aber der hat hinten kein U.

Beitrag #7649555 wurde vom Autor gelöscht.
von Andreas M. (amesser)


Lesenswert?

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

von Gerhard H. (hauptmann)


Lesenswert?

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.

: Bearbeitet durch User
von Georg M. (g_m)


Angehängte Dateien:

Lesenswert?

USB-C.

von Gerhard H. (hauptmann)


Lesenswert?

Georg M. schrieb:
> USB-C.

Bei microchipdirect schon bestellbar!

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Bei AVR Dx können alle DU-Varianten USB.  Nicht so einfach sind die mit 
Xmega im Namen.

von Veit D. (devil-elec)


Lesenswert?


von Gerhard H. (hauptmann)


Lesenswert?

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?

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Andreas M. (amesser)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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-Port

Gerhard 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 Datenrate

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

von Christoph db1uq K. (christoph_kessler)


Angehängte Dateien:

Lesenswert?

Man kann sich eine Gesamttabelle anzeigen lassen und weit hinten steht 
eine Spalte "USB Interface". Sind das alle, oder habe ich falsch 
angekreuzt?

von Gerhard H. (hauptmann)


Lesenswert?

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!

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Christoph db1uq K. (christoph_kessler)


Angehängte Dateien:

Lesenswert?

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"

von Gerhard H. (hauptmann)


Lesenswert?

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.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
von Gerhard H. (hauptmann)


Lesenswert?

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.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von M. K. (sylaina)


Lesenswert?

Gerhard H. schrieb:
> Also um gleich den ersten ATxmega128A4U zu nehmen:  USB-Interface = none
> ist schonmal definitiv falsch.

USB-Module != USB-Interface ;)

von Gerhard H. (hauptmann)


Lesenswert?

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 ...!?

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Steve van de Grens (roehrmond)


Lesenswert?

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.

: Bearbeitet durch User
von Gerhard H. (hauptmann)


Lesenswert?

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.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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?!?!

von Harald K. (kirnbichler)


Lesenswert?

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?

von Gerhard H. (hauptmann)


Lesenswert?

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.

: Bearbeitet durch User
von Andreas M. (amesser)


Lesenswert?

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

von Gerhard H. (hauptmann)


Lesenswert?

Andreas M. schrieb:
> Die Implementierung ist lächerlich einfach,

Du meinst in Hochsprache und mit Lib :)

von Steve van de Grens (roehrmond)


Lesenswert?

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.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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

: Bearbeitet durch User
von Andreas M. (amesser)


Lesenswert?

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.
1
~/Projekte/Elektronik/usb-updi-hv/firmware$ cloc *.c
2
       6 text files.
3
       6 unique files.                              
4
       0 files ignored.
5
6
github.com/AlDanial/cloc v 1.96  T=0.01 s (1014.5 files/s, 219142.0 lines/s)
7
-------------------------------------------------------------------------------
8
Language                     files          blank        comment           code
9
-------------------------------------------------------------------------------
10
C                                6            190            168            938
11
-------------------------------------------------------------------------------
12
SUM:                             6            190            168            938
13
-------------------------------------------------------------------------------

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

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Andreas M. (amesser)


Lesenswert?

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:
1
ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789B]?", ENV{ID_MM_DEVICE_IGNORE}="1", ENV{ID_MM_PORT_IGNORE}="1"
2
ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789A]?", ENV{MTP_NO_PROBE}="1"

von Gerhard H. (hauptmann)


Lesenswert?

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.

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

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

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

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.