Hallo,
ich mache gerade folgendes Projekt:
mit einem at90usb162 steuere ich ein s65 Display an. Ich verwende es
dazu, um titel, laufzeit, fortschritt,... usw. von winamp anzuzeigen.
die pc - anbindung funktioniert usb. soweit funtkioniert es auch
wunderbar.
meine display-platine ist als usb-hid device angebunden. dazu verwende
ich den stack von atmel. zusätzlich wollte ich vom pc noch bilder an das
display schicken. auch das funktioniert - jedoch extrem langsam. mein 1.
aufbau war mit serieller schnittstelle und damit konten mit 38.4 kbaud
die bilder in einer akzeptablen zeit übertragen werden. mir ist halbwegs
klar, warum es als hid device so langsam geht - es werden ja pro request
max. 8 byte übertragen und hid ist sowieso nicht ausgelegt, dass man
größere daten überträgt.
was ich nun gerne hätte: eine andere "generische" device class, für die
ich keinen treiber schreiben brauche, jedoch eine halbwegs akzeptable
datenrate zusammenbringe. ein cdc (serielle schnittstelle) device ist
suboptimal, da man dann von der pc-applikation den seriellen port
auswählen müsste, was sich für ein usb-device etwas widersprechen würde.
gibt es vl. irgend einen "generischen" treiber, wo ich einen in- und
-out endpoint habe (interrupt, bulk, isynchronous... vorerst nicht so
wichtig) und einfach wie bei einer seriellen schnittstelle daten
reinschicken kann, die wie bei einer seriellen schnittstelle
nacheinander am device herauskommen ?
libusb will ich nicht unbedingt verwenden.
ich hoffe ihr könnt mein problem nachfolziehen und danke schon mal für
die hilfe.
lg,
dave
>...mir ist halbwegs>klar, warum es als hid device so langsam geht - es werden ja pro request>max. 8 byte übertragen...
Im Fullspeed-Modus kannst du für jeden EP pro Request bis zu 64 Bytes
übertragen und das jede Millisekunde. Vermutlich ist der Atmel Stack
aber anders konfiguriert, da man diese Datenrate nicht braucht.
>...und hid ist sowieso nicht ausgelegt, dass man>größere daten überträgt...
Das stimmt, man erreicht aber trotzdem recht brauchbare Datenraten.
>...was ich nun gerne hätte: eine andere "generische" device class, für die>ich keinen treiber schreiben brauche, jedoch eine halbwegs akzeptable>datenrate zusammenbringe...
Für Windows kenne ich bis auf HID nichts. Für alles andere würde ich
WinUSB verwenden.
Mars schrieb:
> Für alles andere würde ich> WinUSB verwenden.
danke für den hinweis, habe mir WinUSB angesehn und scheint sehr
brauchbar für meine anforderungen
Hallo Dave (Gast),
wo siehst Du den Widerspruch bei einem virtuellen COM-Port? Es gibt doch
nichts Einfacheres als über CreateFile(), ReadFile(), WriteFile() auf
eine Schnittstelle zuzugreifen!
Im Übrigen brauchst Du auch bei einem HID-Gerät diese Funktionen. Hier
kommt allerdings noch hinzu, dass Du (relativ) umständlich erst einmal
ein Handle auf Dein Gerät erzeugen musst. Das entfällt bei der
CDC-Klasse.
Eine (vernünftige) Alternative zu diesen beiden Optionen gibt es nicht.
Gruß Potter
>wo siehst Du den Widerspruch bei einem virtuellen COM-Port? Es gibt doch>nichts Einfacheres als über CreateFile(), ReadFile(), WriteFile() auf>eine Schnittstelle zuzugreifen!>Im Übrigen brauchst Du auch bei einem HID-Gerät diese Funktionen. Hier>kommt allerdings noch hinzu, dass Du (relativ) umständlich erst einmal>ein Handle auf Dein Gerät erzeugen musst. Das entfällt bei der>CDC-Klasse.
Eine Open, Read, Write und Close Funktion wirst du bei jedem Device,
egal welche Schnittstelle es implementiert benötigen.
Allerdings hast du bei der CDC das zusätzliche Problem den richtigen
COM-Port zu finden. Dem Anwender einfach einen Auswahldialog mit COM1
bis COM99 zu präsentieren ist einfach nicht mehr zeitgemäß. Und auf das
spielt wohl der Threadersteller an.
Bei der HID-Klasse ist es in der Tat aufwändiger das Device zu finden.
Allerdings muss man diesen Code auch nur einmal schreiben bzw. aus dem
Internet kopieren. Dafür ist es ein leichtes das richtige Device anhand
der VID&PID zu finden ohne den Anwender fragen zu müssen.
Mars schrieb:
> Allerdings hast du bei der CDC das zusätzliche Problem den richtigen> COM-Port zu finden. Dem Anwender einfach einen Auswahldialog mit COM1> bis COM99 zu präsentieren ist einfach nicht mehr zeitgemäß. Und auf das> spielt wohl der Threadersteller an.
Naja, man braucht ja nur die installierten COM Ports anzuzeigen. Ist ja
unter Windows kein Problem.
Und über die Eigenschaften kann man die auch soweit eingrenzen, daß man
nicht die Onboardschnittstellen anzeigt.
Ist also nur unschön, falls mehrere Atmels am Rechner hängen.
Insofern ist das schon die beste Lösung.
Dave schrieb:
> Hallo,>> ich mache gerade folgendes Projekt:>> mit einem at90usb162 steuere ich ein s65 Display an. Ich verwende es> dazu, um titel, laufzeit, fortschritt,... usw. von winamp anzuzeigen.> die pc - anbindung funktioniert usb. soweit funtkioniert es auch> wunderbar.
Sehr interessantes Projekt. Wärst Du bereit, weitere Infos zu posten?
- Zugriff auf Winamp-Infos
- evtl. Schaltplan und Sourcecode?
Danke.
Bzgl. "generische" device class:
Digitale Bilderrahmen melden sich oft als CD-Laufwerk und transferieren
dann Daten über SCSI-Protokoll.
Rufus t. Firefly schrieb:
> CD-Laufwerk? Unwahrscheinlich, das ist nicht beschreibbar. Das wird ein> "MSD" sein, ein "mass storage device", wie jeder USB-Stick auch.
Zumindest die "kleinen" Bilderrahmen (1,5" oder 2,4" Bilddiagonale)
melden sich oft als CD-Laufwerk. Siehe z.B. auch hier:
http://forum.ubuntuusers.de/topic/digitaler-bilderrahmen-nicht-schreibbar/
Die Bilder werden nicht als normale Dateien übertragen, sondern über
eine spezielle PC-Software per SCSI-Befehlen. Diese Software ist meist
auf dem digitalen Bilderrahmen gespeichert und wird per Menü vom
Bilderrahmen aus gestartet (AutoStart-Funktion einer CD)
Mars schrieb:
> Allerdings hast du bei der CDC das zusätzliche Problem den richtigen> COM-Port zu finden. Dem Anwender einfach einen Auswahldialog mit COM1> bis COM99 zu präsentieren ist einfach nicht mehr zeitgemäß.
genau das meine ich. es sieht einfach "professioneller" aus, wenn man
keine com-ports hat. funktionieren würde es eh genauso mit cdc.
Ralf Handrich schrieb:
> Im Übrigen brauchst Du auch bei einem HID-Gerät diese Funktionen. Hier> kommt allerdings noch hinzu, dass Du (relativ) umständlich erst einmal> ein Handle auf Dein Gerät erzeugen musst. Das entfällt bei der> CDC-Klasse.
für hid device gibt es von atmel quellcode für den avr und eine
windows-dll, mit der man auf sein hid-device zugreifen kann. das ist
relativ unkompliziert und funktioniert ja auch schon.
M. G. schrieb:
> Sehr interessantes Projekt. Wärst Du bereit, weitere Infos zu posten?> - Zugriff auf Winamp-Infos> - evtl. Schaltplan und Sourcecode?> Danke.
ja, würde ich machen. vorher muss ich aber noch den code etwas
aufräumen, da ich erst mal wert auf funktionalität und nicht schönen
quellcode gelegt habe ;-) für den zugriff auf winamp von einem externen
programm gibts eine schöne doku + beispiele auf http://dev.winamp.com/
Du hast davon gesprochen, das Du die LIBUSB nicht nehmen wolltest. Da
bin ich davon ausgegangen, dass Du auf API-Funktionen zurückgreifst.
Umso besser, wenn es schon eine fertige LIB gibt.
Dein erster Aufbau war mit serieller Schnittstelle. Da hast Du ja die
Arbeit schon getan! Warum nicht ein kleines Protokoll einfügen, bei dem
Du alle vorhandenen COM-Ports öffnest, zwei Bytes rausschickst und auf
eine Antwort wartest?
> Warum nicht ein kleines Protokoll einfügen, bei dem> Du alle vorhandenen COM-Ports öffnest, zwei Bytes rausschickst und auf> eine Antwort wartest?
Das ist Pfusch. Sollte man auf keinen Fall so machen.
a) es dauert je nach Anzahl der verfügbaren Schnittstellen eine ganze
Weile
b) angeschlossene Geräte könnten auf die gesendeten Daten mit Störungen
aller Art reagieren
Mechanismen, wie man die gewünschte Schnittstelle feststellen kann, ohne
alle anderen zu befummeln, wurden bereits genannt.
@ Christian R:
die suche in der Registry ist auch nur ein Notnagel, nur weil die suche
über die SetupAPI von M$ kaum bis garnicht dokumentiert ist, heist das
noch lange nicht, das man das auch so machen sollte.
Die geräte sind in einer art Baumstruktur organisiert. eignentlich so
ähnlich wie im Gerähtemanager, nur das dort teile der äste fehlen, und
ggf wo anders wieder auftauchen.
1. suchen des USB Device Kontens anhand VID und PID. ggf Seriennummer.
2. hocharbeiten bis zu dem punkt, wo der Name des Virtual Com Ports
bekannt ist und auslesen.
oder, die vorhandenen Com Ports "öffnen", und dem pfad nach Unten
folgen, bis man entweder im root landet, oder an dem unter 1 gefundenen
USB Device Knoten.
Ich hate ein ähnliches Problem: welche Laufwerksbuchstaben gehöhren zu
welchem USB Device. für MSD gibt es irgendwo im netz ein paar code
schnipsel.
war glaubich auf www.codeproject.com .
Ich muss aber auch sagen, die SetupAPI ist nicht gerade einfach zu
verstehen.
gruss termite
@rufus
zu a) eine ganze Weile ist relativ. Wenn Du da von Millisekunden
sprichst, wäre das tragbar.
zu b) möglich, ist mir aber noch nicht vorgekommen.
Die eleganteste Lösung ist es wohl trotzdem nicht.
