Hallo! Ich habe für meine Masterarbeit ein Atmel EVK1104 Board mit dem AVR32UC3A3256 zur verfügung. Ziel ist es (neben anderen Dingen) einen USB Audio Device zu programmieren. Ich hatte bisher nicht viel mit Microcontrollern zu tun. Im Studium habe ich mal mit einen Motorolla 68000 experimentiert, aber mehr als mittels Taster einen Interrupt auszulösen wurde da nicht gefordert. Bei dem AVR32 konnte ich als ersten Einstieg immerhin schon mal mittels Counter-Overflow einen Interrupt auslösen und so eine LED zum blinken bringen (soviel Wissen ist im Studium hängen geblieben). So weit so gut, allerdings habe ich hier schon ein bisschen im Forum gelesen und den Eindruck bekommen, dass erstens die AVR32 nicht so ganz einfach sind und zweitens die Sache mit der USB programmierung erst recht nicht so einfach ist. Ich hab versucht über die Beispiele im Atmel Studio einen Einstieg zu bekommen, komme aber nicht so recht weiter. Auch im Internet habe ich bisher keine Tutorials oder ähnliches zu USB zusammen mit AVR32 gefunden. Ich wäre also um Tipps dankbar, wie ich einen Einstieg in dieses Thema finden könnte, ohne gleich nur noch Bahnhof zu verstehen. Vielen Dank schon mal und Liebe Grüße, Julia
USB Audio ist wirklich kein einfaches Thema, und wenn "LED blinken lassen" deine einzigen Vorkenntnisse sind, dann wird's hart. Eine Masterarbeit in welchem Studienfach wird das denn, wenn ich fragen darf?
Julia Keiper schrieb: > Ich hatte bisher nicht viel mit Microcontrollern zu tun. µC sind kleine Computer. Insofern ist da eigentlich nix besonderes dran. Allenfalls die Tatsache, daß man das Futter für µC meistens per Cross-Compiler erzeugt. > Im Studium habe > ich mal mit einen Motorolla 68000 experimentiert Wie lange ist das denn her? Nicht das der 68k schlecht wäre (ich mag ihn sehr), aber er ist einfach mal ALT und keinesfalls mehr Stand der Technik. Und außerdem ist er natürlich vor allem auch eins nicht: ein µC. > Bei dem > AVR32 konnte ich als ersten Einstieg immerhin schon mal mittels > Counter-Overflow einen Interrupt auslösen und so eine LED zum blinken > bringen Damit hast du offensichtlich eine funktionierende Tool-Chain zur Verfügung. Damit sind zwei Drittel der Einsteiger-Probleme bereits überstanden. Der Rest ist sträfliches Datenblatt-Lesen und genauso sträfliches Programmieren. Da spielt jedenfalls die Tatsache, daß das Zielsystem ein µC ist, eigentlich schon keine Rolle mehr. Man muß einfach nur Denken und Programmieren können. Und fleißig sein. > So weit so gut, allerdings habe ich hier schon ein bisschen im Forum > gelesen und den Eindruck bekommen, dass erstens die AVR32 nicht so ganz > einfach sind und zweitens die Sache mit der USB programmierung erst > recht nicht so einfach ist. Ja Scheiße: Programmieren ist Arbeit, wer hätte das gedacht... Mir kämen glatt die Tränen, wenn ich mal Zeit hätte für Mitleid mit den Dummen und den Faulen...
c-hater schrieb: > Wie lange ist das denn her? Nicht das der 68k schlecht wäre (ich mag ihn > sehr), aber er ist einfach mal ALT und keinesfalls mehr Stand der > Technik. Und außerdem ist er natürlich vor allem auch eins nicht: ein > µC. Das kommt mir bekannt vor... ich hatte damals im Studium die ersten Embedded-Berührungen auch mit einem 68k (war eine größere Hochschule in Mittelfranken hüst). Und ja, ein 68k ist eigentlich ein Mikroprozessor. Daher wurde bei mir in der Vorlesung auch der ganze Kram mit externer Speicheranbindung etc. auch mit angeschnitten. c-hater schrieb: > Ja Scheiße: Programmieren ist Arbeit, wer hätte das gedacht... > > Mir kämen glatt die Tränen, wenn ich mal Zeit hätte für Mitleid mit den > Dummen und den Faulen... Naja, das finde ich ein wenig überheblich. Zwischen mal eben unter Anleitung einen Watchdog ausschalten, Interrupts auslösen und ein USB Device nachbauen, liegen doch ein paar Stufen. Klar, es ist machbar aber für einen absoluten Neuling schon ein ordentlicher Brocken. Und bedenke, dass ein Student/in (shit Gender Diversity) noch nicht zwangsweise so viel Erfahrung hat bzw. sich bereits durch Freizeitbeschäftigung und persönlichem Interesse so tief in Embedded eingearbeitet hat.
Für eine Masterarbeit ist auch 1 Semester Zeit und man bekommt 30 ECTS dafür. Also ist genuug Zeit sich da so einiges anzueignen.
Es ist eine Masterarbeit für E-technik. Ich werde ein Platinenlayout für ein Winkelmessgerät entwickeln und dann auch den µC zur Messwertverarbeitung programmieren. Die USB Verbindung soll dazu dienen die Messwerte dann am PC anzeigen zu können. In einem halben Jahr kann man sich schon einiges aneignen, und genau das ist ja auch das Tolle daran, man lernt viel Neues. Max, danke für den Link! Den werde ich mir morgen früh in der Arbeit gleich mal ansehen.
Nanu - wieso USB Audio Device, normalerweise nimmt man da USB CDC Serial Emulation?
Das war der Vorschlag meines Betreuers. Es sollen 4x16 Bit (4Leitungen) mit 10 kHz übertragen werden. Da es bei Audio ja unter anderem 44,1kHz gibt dachte er man könnte diesen Wert ja einfach vierteln und hätte dann rund 11 kHz was auch ok wäre. Ist also CDC die bessere Variante? Da mein Betreuer selber noch nie eine USB-Verbindung programmiert hat wird er mit Sicherheit offene Ohren für Tipps haben ;-)
:
Bearbeitet durch User
Schau dich mal unter http://www.usb.org/developers/docs/devclass_docs/ um. Vllt. passt "Test & Measurement Class" nicht nur vom Namen gut, sondern auch für deinen Fall.
Einarbeitung in Mikrocontroller-programmierung und USB so nebenbei für eine Arbeit in E-Technik? Wenn dein Betreuer den Aufwand da mal nicht gewaltig unterschätzt hat. Würde auf jeden Fall ein Protokoll nehmen, für das der PC passende Treiber mitbringt. Brauchst ja sonst noch mal einen Monat Einarbeitung in Windows/Linux Treiber. CDC ist halt am einfachsten. Man braucht keine Features konfigurieren, kann man benutzen ohne die Spezifikation durch zuarbeiten. Und wenn du Textzeilen überträgst, kannst du einen Terminalemulator zum debuggen nehmen. Bei einem realen Produkt schlägt Murphys Gesetz zu. Der Kunde will eine Erweiterung, die nicht in das Audio Protokoll passt. Eine graphische Oberfläche zur Kalibrierung oder irgend was anderes.
Ich frag mich auch gerade wie viel Zeit ich dafür wohl einplanen müsste. Es stimmt mich etwas misstrauisch, dass ich eine Diplomarbeit gefunden habe, in der nur die USB-Programmierung Thema war. Hat ja also anscheinend Stoff für ein ganzes Semester gegeben. Immerhin hab ich da mal einen theoretischen Einstieg in das Thema (die Programmdateien sind nicht dabei). Ich stimme dir da zu, es sollte definitiv ein Protokoll sein, für das Windows schon Treiber mitbringt. Die Test & Measurement Class ist somit meines Wissens schon mal raus. Da muss ich wohl nächste Woche mal mit meinem Betreuer sprechen, wie es so weiter gehen soll...
Muss es unbedingt USB sein? USB-Kerneltreiberprogrammierung kannst Du aufgrund der zeitlichen Gegebenheiten vergessen. Du hast realistisch 3 Monate für das Gerät und 3 Monate für die schriftliche Ausarbeitung. HID wäre am einfachsten, ist aber nicht besonders schnell. CDC ist am zweit-einfachsten Alles andere ist kompliziert und in drei Monaten nicht zu schaffen. Alternative: Ethernet. Da brauchst Du keine Kernelprogrammierung, und UDP/IP-Pakete zu senden, ist einfach. Sie auf dem PC zu empfangen auch. Du brauchst dann eben einen Prozessor mit eingebautem Ethernet. fchk
Julia Keiper schrieb: > Das war der Vorschlag meines Betreuers. Es sollen 4x16 Bit > (4Leitungen) > mit 10 kHz übertragen werden. Da es bei Audio ja unter anderem 44,1kHz > gibt dachte er man könnte diesen Wert ja einfach vierteln und hätte dann > rund 11 kHz was auch ok wäre. Ist also CDC die bessere Variante? Da mein > Betreuer selber noch nie eine USB-Verbindung programmiert hat wird er > mit Sicherheit offene Ohren für Tipps haben ;-) Hi, ich beschäftige mich seit Jahren mit USB audio, und ich rate dir dringend davon ab, Audio für Messwerte zu nehmen. Die Samplerate bestimmt dein Gerät, insofern könntest du zwar sogar ein 4 Kanal, 16bit, 10 KHz Audiodevice definieren. Das Problem liegt an anderer Stelle. Audio wird nicht als "Messwert" behandelt. Die Treiber konvertieren die Audiodaten gerne erst mal nach "float". Ausserdem hängen Mixer-Stages im Treiber, die die Werte verfälschen können. Und nicht zuletzt ist es ein Clocking Problem. D.h. da deine Messwerterfassung nicht synchron zur internen Audioclock läuft, macht der Treiber eine Samplerateconversion. Da werden Samples eingefügt, weggelassen und interpoliert -> macht deine Messwerte unbrauchbar. Und ein USB Audio Gerät benötigt einen Haufen komplizierter "Descriptors", und Handler, die sich um Audioclocks, Stream start/stop etc. kümmern... Besser: Schau dir mal die "libusb" an, das ist eine Bibliothek, um mit USB Devices zu kommunizieren. Wie dein Gerät vom Betriebssystem behandelt wird, hängt von den sog. "Descriptors" ab, die dein Device ans Betriebssystem meldet. Hier kannst du bestimmen, dass dein Gerät "vendor specific" ist, so dass sich kein Windows-Treiber daran bindet. Was du dann noch brauchst ist ein sog. "bulk in" Endpoint, über den dein Gerät die Daten an den Rechner übertragen kann. Über einen solchen bulk endpoint kannst du bis zu 8000 mal pro Sekunde 1024 Bytes übertragen. In deinem Fall reicht dir ein Endpoint mit 80 Byte Größe, der 1000x pro Sekunde "gepollt" wird. Das geht also locker. Libusb bindest du in dein Programm ein, und über diese library kannst du dann auf dein Gerät zugreifen und die Daten über diesen "bulk endpoint" abholen. Ich habe es ehrlich gesagt unter Windows noch nie gemacht, aber unter OSX ist das sehr einfach.
Ja sollte schon, USB soll ja genau eine der Neuerungen sein im Vergleich zum alten Stand des Geräts. Aber wie gesagt/geschrieben, ich muss das am Montag nochmal besprechen.
Frank K. schrieb: > HID wäre am einfachsten, ist aber nicht besonders schnell. > CDC ist am zweit-einfachsten Hi Frank, könntest du das etwas ausführen? Ich verwende zur Zeit bspw. ein CDC Gerät um Messdaten zu übertragen, will aber die gut implementierte Suspend Möglichkeiten der Betriebssysteme nutzen, die es bei HID oft gibt. Wie würde man auf ein HID Gerät zugreifen? Bei einem CDC Gerät geht das ja relativ einfach mit der virtuellen seriellen Schnittstelle. Das Einzige was ich mir vorstellen kann ist entweder eine USB Tastatur, worüber die Messdaten als Tastenanschläge übertragen würden oder via WinUSB/libusb. Allerdings wird es bspw. bei MATLAB schwierig, dort mit WinUSB/libusb zu spielen.
Simon K. schrieb: > Frank K. schrieb: >> HID wäre am einfachsten, ist aber nicht besonders schnell. >> CDC ist am zweit-einfachsten > > Hi Frank, könntest du das etwas ausführen? Ich verwende zur Zeit bspw. > ein CDC Gerät um Messdaten zu übertragen, will aber die gut > implementierte Suspend Möglichkeiten der Betriebssysteme nutzen, die es > bei HID oft gibt. HID hat mit suspend nichts zu tun. Suspend macht jedes USB Gerät. > > Wie würde man auf ein HID Gerät zugreifen? Bei einem CDC Gerät geht das > ja relativ einfach mit der virtuellen seriellen Schnittstelle. > Das Einzige was ich mir vorstellen kann ist entweder eine USB Tastatur, > worüber die Messdaten als Tastenanschläge übertragen würden oder via > WinUSB/libusb. HID hat leider ein bischen zu wenig Bandbreite. Selbst wenn du einen eigenen Endpoint nimmst - es muss bei HID ein interrupt endpoint sein - sind das (64-1) bytes * 1000 = 63000 bytes pro Sekunde. Benötigt werden aber min. 80000 bytes/s. > > Allerdings wird es bspw. bei MATLAB schwierig, dort mit WinUSB/libusb zu > spielen. Wäre dann die Frage, was mit den Messwerten tatsächlich weiter passieren soll...
Easylife schrieb: > Simon K. schrieb: >> Frank K. schrieb: >>> HID wäre am einfachsten, ist aber nicht besonders schnell. >>> CDC ist am zweit-einfachsten >> >> Hi Frank, könntest du das etwas ausführen? Ich verwende zur Zeit bspw. >> ein CDC Gerät um Messdaten zu übertragen, will aber die gut >> implementierte Suspend Möglichkeiten der Betriebssysteme nutzen, die es >> bei HID oft gibt. > > HID hat mit suspend nichts zu tun. Suspend macht jedes USB Gerät. Ich weiß. Wie man aber durch eingehende Recherche feststellen kann, ist Selective Suspend/Auto Idle für CDC Devices unter Windows eher lumpig bis gar nicht implementiert. Bei HID Geräten siehts hingegen besser aus. >> Wie würde man auf ein HID Gerät zugreifen? Bei einem CDC Gerät geht das >> ja relativ einfach mit der virtuellen seriellen Schnittstelle. >> Das Einzige was ich mir vorstellen kann ist entweder eine USB Tastatur, >> worüber die Messdaten als Tastenanschläge übertragen würden oder via >> WinUSB/libusb. > > HID hat leider ein bischen zu wenig Bandbreite. Selbst wenn du einen > eigenen Endpoint nimmst - es muss bei HID ein interrupt endpoint sein - > sind das (64-1) bytes * 1000 = 63000 bytes pro Sekunde. Würden mir reichen.. > Benötigt werden aber min. 80000 bytes/s. > >> >> Allerdings wird es bspw. bei MATLAB schwierig, dort mit WinUSB/libusb zu >> spielen. > > Wäre dann die Frage, was mit den Messwerten tatsächlich weiter passieren > soll... Ich meinte jetzt in meinem konkreten Anwendungsfall. Was die TO damit vor hat, weiß ich nicht.
:
Bearbeitet durch User
Simon K. schrieb: (...) > Ich meinte jetzt in meinem konkreten Anwendungsfall. Was die TO damit > vor hat, weiß ich nicht. Würdest du dann bitte zu deinem Projekt einen eigenen Thread aufmachen?
Easylife schrieb: > Simon K. schrieb: > (...) >> Ich meinte jetzt in meinem konkreten Anwendungsfall. Was die TO damit >> vor hat, weiß ich nicht. > > Würdest du dann bitte zu deinem Projekt einen eigenen Thread aufmachen? Würdest du dann bitte anderen Leuten nicht vorschreiben, wie sie das Forum zu benutzen haben?
Nichts liegt mir ferner als jemandem etwas vorzuschreiben. Ich finde es nur sehr verwirrend, wenn in einem Thread von 2 Projekten die Rede ist, die sich technisch stark unterscheiden (Thema 63000 byte/s reichen aus oder nicht...). Da weiss doch am Ende keiner mehr, welche Antwort für welches Projekt gültig ist.
Simon K. schrieb: > Wie würde man auf ein HID Gerät zugreifen? Schau hier: http://www.lvr.com/hidpage.htm#MyExampleCode
Auch auf die Gefahr hin, dass ich mich wieder mal dumm anstelle und mir auch eine dementsprechend "dumme" Antwort geschrieben wird habe ich doch noch mal eine Frage: Was ich vor habe steht ja oben schon. Nach langem einlesen in das Thema USB (ich hab mir ein Buch bestellt) habe ich nun zumindest eine Vorstellung von Deskriptoren und Endpoints und auch davon was man alles Programmieren muss, um einen USB Audio Device auf dem AVR32 zu realisieren. Daher die Frage eines Arbeitskollegen: "Gibt´s denn da keine ICs, mit denen dass einfacher wäre?" Ich hab google angeschmissen und bin schon mal auf das hier gestoßen: http://www.ti.com/product/tas1020b Nun möchte ich die Frage meines Kollegen also noch an euch weiter geben. Habt ihr noch Ideen zu ICs, die passen könnten?? Ein liebes Dankeschön schon mal! Julia
>Nun möchte ich die Frage meines Kollegen also noch an euch weiter geben. >Habt ihr noch Ideen zu ICs, die passen könnten?? TUSB3200 allerdings ist USB Audio für deine Anwendung völlig ungeeignet. Wie Easylife schon geschrieben hat werden die Messwerte durch den KMIXER verändert zusätzlich hast auch noch die Systemklänge drin. Rechne für ein funktionierendes USB Audio Device mit ca 6 Monaten. Wenn du keine Erfahrung hast auch mehr. Thomas
Serial-Emulation über USB ist immer noch eine bessere Wahl als ein USB-Audio-Device und vor allem sparst Du eine Menge an Zeit! Hast Du nicht einen Kollegen, der sich mit USB gut bis sehr gut auskennt?
Den hatte ich auch gerade gefunden, danke! :-) Die Infos von Easylife hatte ich schon weitergegeben, aber es soll trotzdem der USB Audio Device realisiert werden. Was soll ich dazu mehr sagen....
Serial hilft bei der geforderten Bandbreite wohl eher nicht. 4*10 KHz brauchen einen Bulk Transfer. Damit bleibt ohne Treiber nur libusb oder unter W7 WinUsb. Alternativ gibt es von Thesycon einen universellen USB Treiber. Dieser ist allerdings kostenpflichtig. Die haben allerdings auch ein Demo. http://www.thesycon.de/eng/usbio.shtml Thomas
Nur so ne Idee: Wenn das Haupt-Feature das Winkelmessgeraet und nicht die USB-Anbindung ist, koenntest Du auch zuerst mal provisorisch die Daten ueber den UART rausschieben, getreu nach dem Motto: wichtige Features zuerst. Nicht dass Du am Ende mit einem 80% funktionierenden USB-Audio-Device dastehst, mit Winkelmessen noch TODO.
Danke Konrad! Natürlich hast du Recht: man muss den Aufgaben Prioritäten zuordnen. Allerdings ist das Winkelmessgerät in diesem Fall nicht das Haupt-Feature. Das Gerät an sich existiert schon funktionierend. Es geht eher um einige Verbesserungen an diesem Gerät. Eine davon ist eben, dass man die Messdaten bequem (aus Anwendersicht) per USB auf den PC bekommt.
> aber es soll trotzdem der USB Audio Device realisiert werden
dann kannst du dein Projekt gleich begraben.
Kauf einfach ein billiges USB Audiodevice und mach mal ein paar
Messungen.
Wenn du Glück hast bekommst du vielleicht 12 sichere Bits aus dem
KMixer.
Audio ist für diese Zwecke ungeeignet.
Thomas
Julia Keiper schrieb: > Ja sollte schon, USB soll ja genau eine der Neuerungen sein im Vergleich > zum alten Stand des Geräts. Wie werden denn die Daten derzeit zum PC übertragen?
Wie schon mehrfach gesagt, ist ein USB Audio Device absolut ungeeignet für diese Aufgabe, da es von sich aus schon auf Audio spezialisiert ist. Sicher würde es irgendwie gehen, wenn die Treiber dafür umgeschrieben würden. Nachfolgend würdest du dich mit USB Audio auch perfekt auskennen, nur ist es eben völlig ungeeignet und in der kurzen Zeit für einen Neuling nicht zu bewerkstelligen. Von Cypress gibt es da gute Lösungen, http://www.cypress.com/?id=193. Oder muss der AVR32 unbedingt die USB Schnittstelle darstellen?
Nein, der AVR32 muss nicht unbedingt die USB Schnittstelle darstellen. Um es mal ganz banal zu formulieren: das Ziel ist es, dass der Anwender des Winkelmessgeräts ein USB-Kabel in sein PC steckt und dann am PC in einer kleinen Software die Messdaten sehen kann. Was/wie das da am anderen Ende des Kabels passiert ist vollkommen egal. Hauptsache es können 4 x 16 bit x 10kHz übertragen werden und sie kommen am Ende aus einem USB stecker (weil sich dieser nun mal an jedem PC bequem verwenden lässt).
:
Bearbeitet durch User
Audio wird bei USB über den Isochronous mode gemacht: The USB protocol provides no error detection or recovery for Isochronous transfers. If no data is transferred or the data is corrupted, no error information is passed to the application. No retries are performed and subsequent packets of a partially failed transaction are nevertheless transferred. Würde ich bei Winkelsensoren schlecht finden. Wenn nen Sound mal abgehackt ist OK aber wenn mir nen Winkelsensor an ner Steuerung oder nem Roboter falsche Werte liefert könnte sich das Ding zerlegen oder jemanden verletzen.
Aus welchem Dokument hast du das? Wenn ich´s schriftlich liefere glaub´s mir mein Betreuer vielleicht.
Der Text ist von hier: http://www.on-time.com/rtos-32-docs/rtusb-32/programming-manual/advanced-topics/isochronous.htm aber es ist noch viel mehr zu finden: http://www.lowlevel.eu/wiki/Universal_Serial_Bus#Isochronous http://www.silabs.com/Support%20Documents/TechnicalDocs/AN295.pdf usw.
http://www.ftdichip.com/Products/ICs/FT232R.htm Der IC arbeitet am PC als virtueller COM-Port und wurde oben sicher schon mit Stichwort "Seriell" angesprochen. Du überträgst die Daten über UART, das beherrschen die meisten µC von Haus aus. Um USB musst du dich dann erstmal nicht kümmern.
Bitte 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.