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.
Was genau ist an ATMegaU veraltet? Sind doch noch in Produktion... Ansonsten gäbe es noch die AVRDU, 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
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?
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.
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.
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.
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.
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.
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.
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...
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
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
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.
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.
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...
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.
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"
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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...
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.
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
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...
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.
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.
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).
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?
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?
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.
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.)
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...
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...
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.
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).
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.
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.
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.
