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?
Kennt sich damit niemand aus? Jedes bessere USB Gerät erscheint doch heutzutage nicht mehr als virtueller COM Port.
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
:
Bearbeitet durch User
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... :/
:
Bearbeitet durch User
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.