Hallo,
für ein zukünftiges Projekt möchte ich einen ATmega16U2 einsetzen und
das USB Interface zum Datenaustausch mit dem PC verwenden. Dabei scheint
die LUFA Bibliothek ziemlich beliebt zu sein. Da mehrere MB Daten
zwischen µC und PC ausgetauscht werden, soll es für den PC eine Software
geben mit der man Lese/Schreibvorgänge starten und in Dateien umleiten
kann.
Jetzt könnte man natürlich die "Virtual Serial Device" Klasse von LUFA
nutzen. Da mein PC aber ohnehin schon mit virtuellen COM Ports zugemüllt
ist habe ich mich gefragt, ob man das nicht auch ohne virtuelle COM Port
machen kann. Also der µC meldet sich beim Anstecken an den PC als ein
USB Gerät an und die Software für den PC stellt fest, dass ein
entsprechend programmierter µC angeschlossen ist und kann sich mit
Diesem verbinden. Am besten sollte dies direkt mit Standardtreibern
funktionieren. Kann man so etwas mit dem ATmega16U2 und LUFA
realisieren?
sebi707 schrieb:> Also der µC meldet sich beim Anstecken an den PC als ein> USB Gerät an und die Software für den PC stellt fest, dass ein> entsprechend programmierter µC angeschlossen ist und kann sich mit> Diesem verbinden. Am besten sollte dies direkt mit Standardtreibern> funktionieren. Kann man so etwas mit dem ATmega16U2 und LUFA> realisieren?
Ja, geht - sogar vergleichsweise einfach im Gegensatz zu Standardklassen
(wie CDC).
Man muss sich halt im Klaren sein, das man auf der Hostseite selbst eine
Applikation entwickeln darf. Dafuer hat man (fast) beliebige Freiheiten
im Protokolldesign.
Fuer die Applikation auf Hostseite gibt es libusb.
Die meisten VUSB Projekte machen das (notgedrungen, da lowspeed USB und
damit kein bulk) so.
Letzter Punkt von http://matrixstorm.com/avr/tinyusbboard/#examples
Nachtrag: Wenn es (unter Windows) komplett ohne Treiber auskommen soll,
faellt man z.B. auf HID zurueck.
MfG
sebi707 schrieb:> Kennt sich damit niemand aus?
Das Problem ist nicht ganz trivial. "Es soll mit Standardtreibern
funktionieren" lässt vermuten, dass dir der USB Bus noch nicht so ganz
klar ist. In der Wikipedia findest du einen recht guten Artikel darüber.
Lies ihn und überlege dann, welche der Standard Klassen für dich in
Frage kommt. Dann findest du heraus, welche Funktionen dein Client
können muss und kannst den Aufwand abschätzen. Und du kannst sehen, ob
LUFA deine Klasse unterstützt (und wie es geschieht).
Jedes USB Gerät braucht einen Treiber. Da gibt es (IMO bessere)
Alternativen zu VCOM, Google Stichworte: WinUSB, Libusb, Libusb-win32.
WinUSB braucht auch nicht viel mehr als eine .inf Datei auf modernem
Windows,
ab Win8 kann man das USB Gerät gar so programmieren dass es automagisch
den WinUSB Treiber lädt (WCID).
Für die höheren Ebene der Software gibt es genügend Beispiele im Netz zu
finden.
Hi,
je nachdem, wie du es genau vorhast, würde ich dir entweder ein
Standard-HID oder Mass Storage (bzw. Bulk Transfer) empfehlen. Ersteres
habe ich selbst schon gemacht und geht relativ einfach, mit letzterem
habe ich noch keine Erfahrung.
Das Standard-HID ist vergleichsweise einfach, wenn du z.B. ein
Request-Response-"Verfahren" machst, bekommst du die Anfrage in einer
Methode, baust den Response zusammen und schickst ihn zurück an den PC.
Dürfte sogar noch einfacher als ein virtueller COM-Port/CDC sein.
Weiterer Pluspunkt: Keinerlei Treiber nötig, das Betriebssystem bringt
alles mit. Nachteil: eher langsam.
Mass Storage dürfte aufgrund von Bulk transfer deutlich schneller sein,
aber ist vermutlich auch etwas komplizierter, weil du auf dem
Mikrocontroller etwas mehr machen musst (Dateisystem - wenn man es so
nennen will - bereitstellen, Dateigrößen vorab berechnen, etc.).
Dann gibt's da noch den reinen Bulk transfer, von dem ich nur weiß, dass
es ihn gibt und dass er am schnellsten sein dürfte. Wie es genau
funktioniert kann ich allerdings nicht sagen. In den LUFA-Downloads
gibt's aber Beispiele.
Noch ein Tipp: in Atmel Studio gibt's ein Plugin für LUFA, das die
Arbeit etwas erleichtern soll.
Noch ein anderer Tipp: Nimm den Atmega32u2 - der ist unwesentlich teurer
aber du musst dir deutlich weniger Gedanken über Speicher machen. (Tipp:
Lass den DFU-Bootloader drin, der ist kompakt, gut und stört bei 32KByte
nicht wesentlich!)
HTH
Chris
Edit: Würde dir gerne ein Beispiel geben, darf es allerdings nicht, da
es eine Auftragsarbeit war... :/
Chris R. schrieb:> entweder ein> Standard-HID oder Mass Storage (bzw. Bulk Transfer) empfehlen. Ersteres> habe ich selbst schon gemacht und geht relativ einfach, mit letzterem> habe ich noch keine Erfahrung.
Keine Erfahrung mit Mass Strorage, aber trotzdem eine Empfehlung? WTF?
USB Mass Storage macht man i.A. nur, wenn da auch wirklich ein
Massenspeicher wie eine SD Karte am µC dran hängt. Weil da noch SCSI
dazwischen liegt, ist das nämlich recht kompliziert.
Bulk Transfer nimmt man, wenn einem die max. 64kB/sec bei Full Speed von
HID nicht reichen. Viele Protokolle wickeln darüber ihnen Datenverkehr
ab, z.B. VCOM oder auch Mass Storage. Das kann man mittels WinUSB oder
LibUSB direkt benutzen.
Ok erstmal Danke für alle Antworten. Über die verschiedenen USB Klassen
hab ich mal so grob drüber geguckt. Mass Storage scheint mir auch eher
was zu sein Falls es um mehrere Dateien geht. In meinem Fall gibt es nur
einen Datensatz der vom µC zum PC oder umgekehrt übertragen wird. HID
hatte ich übersprungen, da ich dachte, dass es nur für Eingabegeräte
ist. Werde ich mir nochmal genauer anschauen.
Stephan B. schrieb:> Fuer die Applikation auf Hostseite gibt es libusb.
Und wie sieht es auf der Deviceseite aus? Gibts da ein Stichwort für USB
Geräte abseits der Standardklassen?
Chris R. schrieb:> Noch ein anderer Tipp: Nimm den Atmega32u2
Hab ich gestern auch gesehen. Die Software für den µC ist zwar abgesehen
von dem USB Kram so einfach wie es fast nur geht aber mehr Speicher kann
nie Schaden.
sebi707 schrieb:> Und wie sieht es auf der Deviceseite aus? Gibts da ein Stichwort für USB> Geräte abseits der Standardklassen?
Dafuer gibt es, wie du bereits angefordert hast, LUFA.
Statt Deviceklassen (Logik die auf einen bis vielen Endpunkten
aufsitzt), nimmst du einfach "pure" Endpunkte (z.B. Bulk oder gar
isochron) als "bitpipes".
Eine sehr grobe Analogie zu den Endpunkte sind die Portadressen aus der
Netzwerkwelt.
MfG
