Hallo!
Ich habe vor, ein USB-Gerät zu bauen, das keiner gängigen
USB-Geräteklasse zuzuordnen ist. Es sollen in erster Linie Audiodaten
sowohl vom PC zum Gerät als auch in die andere Richtung übertragen
werden, allerdings soll das ganze kein Audiointerface sein. Zusätzlich
sollen nicht ganz so datenintensive Steuerinformationen vom PC an das
Gerät übertragen werden können. Das Gerät soll sowohl einen A/D-Wandler
als auch einen D/A-Wandler enthalten.
Meine Frage als ziemlicher Anfänger auf diesem Gebiet ist: Wie ist solch
ein Gerät in groben Zügen aufgebaut? Ich bin bei meinen bisherigen
Recherchen auf den FX2 von Cypress und den ISP1581 von NXP gestoßen. Wie
würde ein A/D-Wandler mit solch einem Baustein verbunden werden? Oder
gibt es vielleicht sogar Microcontroller mit integriertem USB-Anschluss,
die leistungsfähig genug sind, um zwei Audio-Datenströme zu handhaben
und gleichzeitig noch andere Aufgaben erledigen können?
Werde ich mir einen eigenen Treiber für so was schreiben müssen, oder
gibt es für USB-Geräte, die beliebige Daten hin und her-transferieren,
eventuell Standardtreiber?
Eine grobe Skizze des Aufbaus einer solchen Hardware würde mir schon
sehr weiterhelfen. Vielleicht hat jemand hier im Forum ja schon etwas
ähnliches gemacht (es muss ja nicht audiospezifisch sein - prinzipiell
geht es dabei ja einfach um die übertragung von Datenströmen) und kann
mir die richtige Richtung, in die ich weiterforschen sollte, aufzeigen
(oder kennt vielleicht sogar ein im Netz beschriebenes Projekt, das
ähnlichkeit mit meinem Vorhaben hat).
Gruß Thorsten
Warum willst du kein audio-interface für den Audio teil nehmen?
Du müsstets dann nurnoch in dein gerät nen Hub (als chip oder gerät, is
eratmal wurst) stopfen und die steuerungssignale mit nem einfach µC (AVR
+ V-USB?) empfangen und ausführen....
Die meisten AD- und DA-Wandler für Audio werden mit I²S oder TDM
angeschlossen. Das sollte der Prozessor nach Möglichkeit in Hardware
können, sonst wirds unangenehm.
Ich würde mal die dsPIC33 genauer ansehen.
Grüße,
Peter
Kannst dir auch mal den neuen Cypress FX3 anschauen. Hat gleich USB 3.0
und I2S Hardware Interface für Audio. Standard-Treiber gibts dann
entweder von Cypress direkt, da kannst du einfach Daten zu/von den
Endpoints übertragen oder wie ich finde wesentlich eleganter über
WinUSB. Das ist ein generischer USB Treiber der in Windows integriert
ist. Geht für alle Geräte, außer isochrones Streaming. Aber eventuell
wäre genau das für dich interessant, isochroner Datentransfer erlaubt
garantierte Bandbreite, ideal für Audio/Video.
>Ich habe vor, ein USB-Gerät zu bauen, das keiner gängigen
USB-Geräteklasse zuzuordnen ist.
>Meine Frage als ziemlicher Anfänger auf diesem Gebiet ist:
Vergiss es. Sowas ist fuer Experten schon eine grosse Herausforderung.
Du hast leider absolute Null Chance.
Poly Oschi schrieb:>>Ich habe vor, ein USB-Gerät zu bauen, das keiner gängigen>> USB-Geräteklasse zuzuordnen ist.>>Meine Frage als ziemlicher Anfänger auf diesem Gebiet ist:>>> Vergiss es. Sowas ist fuer Experten schon eine grosse Herausforderung.> Du hast leider absolute Null Chance.
Da muss ich leider zustimmen.
Als Grundlageneinstieg (!) kannst du dir mal das hier anschauen
http://www.beyondlogic.org/usbnutshell/usb1.shtml
Um genau was damit zu machen wirst du dir irgendwann mal die 700 Seiten
USB Orginal reinziehen müssen ...
Das würde ich jetzt nicht so sehen. Bei Microchip gibts schon ein Audio
Example für die USB-Schnittstelle. Daraus sollte sich schon was basteln
lassen. Vielleicht darf es ja doch ein Standard-USB-Audiodevice sein,
das würde die Sache für den Anfang erheblich erleichtern.
Soool wild ist das auch nicht. Für USB Audio Devices gibts jede Menge
Code-Beispiele und wenn man eh was eigenes machen will, kann man sich an
den Endpoints beliebig austoben. Einarbeitung ist natürlich nötig, aber
ist keine Hexerei, wenn man einen µC mit integriertem USB nimmt. Für
Audio und gleichzeitige Datenübertragung ist vielleicht ein Composite
Device sinnvoll.
Danke für die schnellen Antworten! Ich hatte mir schon gedacht, dass das
ganze kein einfaches Unterfangen sein wird. Die Flinte ins Korn werfen
wollte ich allerdings trotzdem nicht voreilig. Zu meiner
Selbsteinschätzung als „Anfänger“ sollte ich vielleicht noch ergänzend
sagen, dass sich das auf den Themenbereich Hardware-Bauen und USB an
sich bezog. Programmierkenntnisse sind berufsbedingt in recht solider
Form vorhanden.
Der FX3 macht den Eindruck, als wäre das Projekt damit auf ziemlich
komfortable Weise umzusetzen (sofern man jemand wäre, der wüsste, wie
man mit sowas umgeht), allerdings geht das wiederum schon fast in
Richtung „mit Kanonen auf Spatzen schießen“.
Ein standard Audio-Interface wäre für das, was ich vorhabe, leider nicht
das richtige. Das Gerät soll vom Betriebssystem nicht als Soundkarte
erkannt werden, und ich brauche die Audio-Rohdaten für die
Weiterverarbeitung in einer proprietären Anwendung so latenzfrei wie
möglich.
Die Seite beyondlogic.com macht einen sehr interessanten eindruck, danke
für den Link! Werde ich mir auf jeden Fall mal zu Gemüte führen.
Da die Umsetzung des Projekts nicht sonderlich zeitkritisch ist (Es
handelt sich um eine fixe Idee, die ein Freund und ich seit einiger Zeit
haben), werde ich mich so nach und nach weiter an das Thema rantasten.
@Christian: Ein Composite-Device? Hast Du ein Beispiel für so was parat?
Beispiele für Composite Devices gibts überall. Der UMTS-Stick mit
integriertem Flash-Speicher, der Drucker mit HID für die Tasten
usw....programmiert wird das über verschiedene Interfaces. Klar, der FX3
ist ein Bolide, aber das HW-I2S Interface und der ARM Core ist halt
schick. Der FX2 tuts auch, ist aber wesentlich beschränkter und ein
oller 8051. Ansonsten tuts je nach gewünschter Datenrate auch ein
AT90USB oder XMega mit USB.
Verstehe! Das ganze als Composite-Device zu gestalten könnte durchaus
sinnvoll sein. Und danke auch für die Erwähnung des XMega, der scheint
geschwindigkeitsmäßig für die Samplerate, die mir vorschwebt (24 bit,
96khz mono) zumindest für einen Prototypen durchaus schnell genug zu
sein (wenn man den Werten in diesem Newsletter Glauben schenken kann:
http://www.msc-ge.com/en/news/pressroom/newsletter/atmel/nl/7105-INT.html
).
Thorsten K. schrieb:> Ich habe vor, ein USB-Gerät zu bauen,Thorsten K. schrieb:> so latenzfrei wie> möglich.
Widerspricht sich leider.
Selbst mit Feuerdraht800, ASIO-Treibern und anderen Tricks kommt man,
mit guter Software in professionellem Anspruch auf 4-5ms. OK, das sind
Turnaround-Zeiten(CPU->Analogausgang->Analogeingang->CPU), aber ist
leider so. Und die Leute die sowas entwickeln, machen das nicht erst
seit gestern.
Thorsten K. schrieb:> um zwei Audio-Datenströme zu handhaben> und gleichzeitig noch andere Aufgaben erledigen können?>> Werde ich mir einen eigenen Treiber für so was schreiben müssen, oder> gibt es für USB-Geräte, die beliebige Daten hin und her-transferieren,> eventuell Standardtreiber?
Wenn Hardware-Bauen nicht so dein Ding ist, du aber mit Software "alles
was dein Herz begehrt" hinbekommst, dann schau dir doch mal einige
günstige USB-Audiointerfaces an. Denen einen eigenen proprietären
Treiber zu verpassen(vid/pid in einer inf-Datei zu den eigenen Treibern
angeben). Das geht dann so: Gerät anstecken, Gerätemanager auf und
Betriebssystem-Treiber gegen eigenen Treiber austauschen, fertig.
Latenzfrei ist in diesem Zusammenhang auch mit Vorsicht zu erwähnen. Es
wird immer Zeit brauchen, bis deine eingetrudelten Daten analysiert
werden. Dann funkti auch das Betriebssystem immer wieder dazwischen.
mfg mf
Die Idee, einen neuen Treiber für ein existierendes Audiointerface zu
entwickeln, ist mir noch gar nicht gekommen. Das ist softwareseitig
bestimmt eine ganz schöne Herausforderung, allerdings fiele so ein
Großer Teil des Problems Hardware (zumindest für einen "proof of
concept") erstmal weg. Die nötigen Steuerdaten müssten dann zwar auf
separatem Wege zum Gerät gelangen, aber zu Testzwecken finde ich den
Ansatz sehr interessant.
Beim Überfliegen einiger Kurzeinführungen in das Thema USB ist mir
aufgefallen, dass ich durch die "Zerstückelung" des Busses in 1000
Frames pro Sekunde auf jeden Fall mit mindestens einer Millisekunde
Latenz rechnen muss. Wird dann wohl nichts mit absoluter Latenzfreiheit,
aber eine ms (wenn sie denn praktisch auch erreichbar ist) wäre für mein
Vorhaben noch verschmerzbar.
Wie schon gesagt, du musst keinen Treiber schreiben, dafür gibts die
generischen Treiber samt API. Latenzfrei bekommt man mit USB gar nichts
hin. Und bei BULK transfer kannst du dich schon mal auf einige hunter ms
Pause zwischen Transfers einstellen, wenn du mit Windows arbeitest. Du
müsstest dann wirklich ISO Transfer nehmen, da ist wenigstens die
Bandbreite garantiert. USb 2.0 HighSpeed hat übrigens 125µs Raster für
die MicroFrames. Trotzdem ist USB im OS so niedrig priorisiert, dass man
da nicht viel machen kann. Schon gar nicht, wenn Daten rein, bearbeiten
und Daten wieder raus. Das bekommst du auf gar keinen Fall mit 1ms
Latenz hin.
125µS hören sich ja schon mal ganz anders an. Dass ich um isochronen
Datentransfer nicht herumkommen werde, habe ich mir schon gedacht.
Naja, ich denke, um mehr herauszufinden, heißt es ab hier wohl erstmal:
"Probieren geht über Studieren". Danke an Euch für die aufschlussreichen
Tipps & Anregungen!
Sobald ich auf experimentellem Wege erste (Miss-)Erfolge verbuchen kann,
werde ich der Vollständigkeit halber auf jeden fall hier darüber
berichten.
Grüße,
Thorsten
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten