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.
Einen virtuellen COM Port anhand der VID/PID in der Registry suchen ist genauso wenig ein Problem.
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.
> Ist also nur unschön, falls mehrere Atmels am Rechner hängen.
Auch kein Problem, denn USB-Geräte können eineindeutige Seriennummern
erhalten.
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.
CD-Laufwerk? Unwahrscheinlich, das ist nicht beschreibbar. Das wird ein "MSD" sein, ein "mass storage device", wie jeder USB-Stick auch.
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.
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.