|
Datum:
|
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
|
Datum:
|
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....
|
Autor:
Peter D.
(pdiener)
Datum:
|
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
|
Datum:
|
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.
|
Datum:
|
>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.
|
Datum:
|
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 ...
|
Autor:
Peter D.
(pdiener)
Datum:
|
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.
|
Datum:
|
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.
|
Datum:
|
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?
|
Datum:
|
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.
|
Datum:
|
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 ).
|
Datum:
|
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
|
Datum:
|
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.
|
Datum:
|
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.
|
Datum:
|
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
Thread beobachten
Seitenaufteilung abschalten