Hallo, Ich bin dabei ein Gerät mit AVR uC zu entwickeln. Im Moment ist es noch per RS232 Schnittstelle mit dem PC verbunden. Das ist natürlich nicht sonderlich modern, und in meinem Fall auch nicht unbedingt günstig. Ich möchte den Controller per USB an den PC anschließen und auf dem PC einen eigenen Treiber benutzen (z.B. um den Controller als virtuelles MIDI-Gerät zu installieren) Wunschvorstellug: - Datenrate muss nicht hoch sein, geringe Latenz ist wichtiger - Natürlich möglichst einfach realisierbar sein - Eigener Treiber lässt sich entwickeln (also kein virtueller COM-Port oder über DLL) - Ich komme irgendwie günstig an eine Vendor ID + PID (1500 Euro sind definitv zu viel). - Das ganze sollte dann unter Umständen auch kommerziell verteibbar sein (nur vielleicht, in Kleinserie) - im Moment nur Hobby, aber bei Planung will ich es nicht außer Acht lassen Die FTDI Chips lassen sich ja einfach per UART ansprechen. Mehr brauche ich auch nicht. Und eine Vendor ID gibts auch. Leider gibts keine Möglichkeit eigene Treiber zu schreiben oder ein DDK ? Die Software USB Lösungen (Igor und Co) für AVR sind interessant, aber es gibt keine Vendor ID (?), kommerzieller Vetrieb ungewiss (?) und nicht so leistungsfähig. Dafür gibt es einen Beispieltreiber, ein AVR ist günstig und gibt's im DIP Gehäuse. An andere USB Controller habe ich mich noch nicht ran gewagt - Die Datenblätter erschlagen einen ja und es gibt weder Vender Id noch sind sie einfach realisierbar (?) Wie realisiert man also am besten ein eigenes USB Gerät mit eigenem Treiber ? Möglichst günstig natürlich. Und einfach. Und überhaupt :)
Eigene Vendor-ID gibt`s bei www.usb.org Ist allerdings mit "Gebühren" verbunden und nicht unbedingt lohnend für Mini-Serie. Da sind die FTDI schon die optimale Lösung da es hier nen kostenfreie SubID gibt und keine weiteren Kosten entstehen.
Schau dir vieleicht mal diese Lösung an : http://www.obdev.at/products/avrusb/ Ist auch OpenSource gibts aber auch auf Lizenzbasis, wenn ich recht gesehen hab. Gruß
Hallo Sascha.. melde Dich dochmal bei mir. markus.cords@online.de
Die Vendor-ID dürfte noch das kleinste Problem bei der Aufgabenstellung sein. Der "eigene Treiber" ist der Knackpunkt - Devicetreiber für Windows schreiben sich nicht mal eben von selbst, und für so etwas wie ein USB-Midi-Device ist ein solcher erforderlich.
Hallo, wenn ich mich richtig erinnere, könnte das mit den FTDIs aber auch gehen. FTDI sollte jedenfalls nix dagegen haben, dass Du Dir einen eigenen Treiber schreibst. Habe ich aber noch nie gemacht. Ich nutze für die FTDIs immer die d2xx-Treiber. FTDI schreibt aber nicht vor, dass Du ihre Treiber verwenden musst. Wende Dich da mal an den Support, evtl. helfen die Dir weiter. Gruß, Sebastian
Die Verwendung von FTDI-Bausteinen hindert einen zwar nicht daran, für die einen eigenen Devicetreiber zu schreiben, das aber liefe auf ein Neuerfinden des Rades hinaus, da die über USB transferierten Daten und also die Grundfunktion fest durch den FTDI-Chip vorgegeben sind. Das hat also allenfalls stark eingeschränkten Nutzen. Sinnvoll ist eine derartige Entwicklung nur, wenn auch das USB-Gerät selbst programmiert werden kann, wie es bei µCs mit integriertem USB-Device-Controller der Fall ist (Cypress AN2131, neuere Atmel-ARMe etc.). Auch hier kann man sich dank libusb/libusb-win32 die Treiberentwicklung glücklicherweise sparen; wer schon mal die "Dokumentation" des Windows-DDK gesehen hat, wird die Formulierung verstehen ...
> und für so etwas wie ein USB-Midi-Device ist ein solcher > erforderlich. Es ist natürlich ein Treiber erforderlicher, aber nicht notwendigerweise ein eigener. Wenn ich das richtig sehe, kann man zumindest unter Windows den eingebauten verwenden, so man sich an die 'Device Class Definition for MIDI Devices' hält. Allerdings ist noch gar nicht klar, welches System der OP überhaupt verwendet; das wurde noch gar nicht erwähnt.
Nun, wenn die 'Device Class Definition for MIDI Devices' verwendet werden soll, dann kann erst recht nichts mit einem FTDI-Chip angefangen werden, denn der implementiert die nicht.
>>Schau dir vieleicht mal diese Lösung an : >>http://www.obdev.at/products/avrusb/ Ja, dafür hatte ich mich auch schon interessiert. >>Die Vendor-ID dürfte noch das kleinste Problem bei der Aufgabenstellung sein. Der "eigene Treiber" ist der Knackpunkt - Devicetreiber für Windows schreiben sich nicht mal eben von selbst, und für so etwas wie ein USB-Midi-Device ist ein solcher erforderlich. Ist die Vendor-ID wirklich das kleinste Problem ? Ich weiß nich wie "leicht" man eine eine kommt, ohne sich zu verschulden. Den Treiber zu entwickeln macht wahrscheinlich nicht soo viel Spass, aber ich habe schon ein paar Erfahrungen mit Treiberentwicklung gemacht. Zielsystem ist erstmal Windows (2000/XP). Vorgefertigte Treiber gehen leider nicht, weil es kein echtes MIDI-Gerät wird, sondern nur ein virtuelles.
Solange Du das Gerät nicht kommerziell vertreibst, ist die Vendor-ID im Grunde genommen wurscht; Du solltest eine aussuchen, die von einem möglichst obskuren Hardwarehersteller verwendet wird, damit ist die Wahrscheinlichkeit gering, daß es Probleme geben könnte.
>>Solange Du das Gerät nicht kommerziell vertreibst, ist die Vendor-ID
im Grunde genommen wurscht;
Das ist mir bekannt. Nur bei der Planung will ich den kommerziellen
Vertrieb nicht ganz außer Acht lassen, auch wenn es noch unsicher ist.
Brainstormmodus an Mal so eine dumme Idee, ich weiß nicht, ob das umsetzbar ist. Gibt es evtl. die Möglichkeit, Windows einen virtuellen Midi-Port vorzugaukeln, und die dorthin geschickten Daten über die d2xx-Treiber zum FTDI zu senden? Die über d2xx emfangenen Datan werden ebenso an den virtuellen Midi-Port gesendet. Brainstormmodus aus Ist ein bisschen OT, aber trotzdem die Frage: Wenn das ^ geht, hat jemand einen Link zu einer Beschreibung für sowas? Ich bin (lose) auf der Suche nach der Möglichkeit, einen virtuellen Parallelport zu implementieren. Gruß, Sebastian
Ein Beispiel für einen -allerdings anders aufgebauten- virtuellen Parallelport gibt es inclusive Quelltexten hier: http://www-user.tu-chemnitz.de/~heha/bastelecke/Rund%20um%20den%20PC/USB2LPT/ Das ist ein sehr interessanter USB-Parallelport-Adapter, vor allem, was der zugehörige Windows-Devicetreiber so macht ...
>>Gibt es evtl. die Möglichkeit, Windows einen virtuellen Midi-Port
vorzugaukeln, und die dorthin geschickten Daten über die d2xx-Treiber
zum FTDI zu senden? Die über d2xx emfangenen Datan werden ebenso an den
virtuellen Midi-Port gesendet.
Das ist eben der Umweg, den ich nicht gehen möchte. Du müsstest neben
deinem Parallelporttreiber auch noch eine Anwendung, besser einen
Dienst schreiben, der die Daten vom FTDI Treiber zu deinem
Paralleltreiber schaufelt.
Es würde dann so aussehen:
FTDI Treiber -> (D2XX) Dein Dienst -> Dein Paralleltreiber
Was ich suche wäre:
FTDI Treiber + Paralelltreiber in einem
bzw. Midi in meinem Fall.
Es muß doch nicht immer und überall auf Biegen und Brechen eine USB <-> UART Bridge verbaut werden. Für ein MIDI-Gerät eignet sich sowas nun mal nicht. Wenn Du Dich ganz einfach an die MIDI DCD hälst, wird es mit Sicherheit deutlich weniger kompliziert (Du brauchst keinen eigenen Windows-Treiber und es funktioniert auch auf Nicht-Windows-Systemen). Externe USB-Controller gibt es genug, z.B. Nationals USB9604 oder Philips PDIUSBD12 (die Bezeichnungen stammen aus meinem Gedächtnis, bitte nicht darauf festnageln). Noch einfacher wird es, wenn Du Dich von den AVRs löst. Inzwischen gibt es einige Controller verschiedenster Hersteller mit USB OnChip, die auch mit FLASH daherkommen und sich auch im System programmieren/ debuggen lassen.
. "Inzwischen gibt es einige Controller verschiedenster Hersteller mit USB OnChip, die auch mit FLASH daher- kommen und sich auch im System programmieren/ debuggen lassen." O ja, der AT91SAM7S64 zum Beispiel. Ist auch gar nicht so teuer ...
Mit dem Gedanken an AT91SAM7S64 hatte ich auch schon gespielt. Aber das wär dann doch wieder ne Nummer größer als ein "popeliger" AVR. Was mich wirklich nervt ist diese Sache mit der Vendor ID/PID. Von FTDI bekommt man ja eine PID für lau, wenn man ihre Chips verwendet. Aber was macht man, wenn man z.B. dem AT91SAM7S64 verwendet ? 1500Euro kann ich dafür sicher nicht blechen.
> Was mich wirklich nervt ist diese Sache mit der Vendor ID/PID.
Aber wieso nur? Solange sich das ausschließlich auf Deinem Rechner
abspielt, ist das so wie Rufus sagt, da kannst Du fünfe gerade sein
lassen. Während der Entwicklungszeit gilt das sowieso. Und wenn Du
wirklich kommerziell werden solltest, macht sich ein eigener Vendor
Identifier natürlich besser. Da die Kosten dafür eh nur einmal
auflaufen, ist das eigentlich auch gar nicht so schlimm. Durch den
Varkauf dieses Geräts (und aller anderen, die damit fertigen kannst),
kommt das Geld auch wieder zurück.
Wenn Du das dann aber wirklich noch immer nicht willst, fragst Du im
Forum 'Markt' gesondert nach, ob Du für eine Flasche Bier den VID
eines Anderen mitbenutzen darfst. Beispielweise könnte ich Dir einen
PID abgeben, den Du unter meinem VID benutzen darfst. Da gibt es dann
sicherlich noch andere (z.B. Markus Cords?), die Dir in der Not mal
einen PID überlassen würden (jedenfalls solange da nicht täglich
nachgefragt wird).
@ Rene wo weist Du das ich eine VendorID habe ??? lg, markus
Ich dachte Aufgrund Deines geheimnisvollen Postings "Der will ihm bestimmt 'nen PID anbieten und hat keine Lust, daß noch 50 Andere auch gleich 'nen PID haben wollen" Da habe ich gut geraten, wie mir scheint. :-))
Hallo Rufus, danke für den Link. Prima. Sebastian
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.