mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USB - Device


Autor: Dave (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...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.

Autor: Dave (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Potter S. (potter68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen virtuellen COM Port anhand der VID/PID in der Registry suchen ist 
genauso wenig ein Problem.

Autor: ARM ab (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist also nur unschön, falls mehrere Atmels am Rechner hängen.

Auch kein Problem, denn USB-Geräte können eineindeutige Seriennummern 
erhalten.

Autor: M. G. (looking)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CD-Laufwerk? Unwahrscheinlich, das ist nicht beschreibbar. Das wird ein 
"MSD" sein, ein "mass storage device", wie jeder USB-Stick auch.

Autor: M. G. (looking)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-bilder...

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)

Autor: dave (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Potter S. (potter68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Potter S. (potter68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du mir einen Grund nennst, bin ich schlauer.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: termite (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Potter S. (potter68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.