Forum: Mikrocontroller und Digitale Elektronik USB Audio Device AVR32


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Julia K. (julia_k)


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

von Easylife (Gast)


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

von Max D. (max_d)


Bewertung
0 lesenswert
nicht lesenswert
LUFA hat beispielcode dafür http://www.fourwalledcubicle.com/LUFA.php

von c-hater (Gast)


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

von Fliegenklatsche (Gast)


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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


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

von Julia K. (julia_k)


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

von Kein Name (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nanu - wieso USB Audio Device, normalerweise nimmt man da USB CDC Serial 
Emulation?

von Julia K. (julia_k)


Bewertung
0 lesenswert
nicht lesenswert
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
von mar IO (Gast)


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

von Kein Name (Gast)


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

von Julia K. (julia_k)


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

von Frank K. (fchk)


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

von Easylife (Gast)


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

von Julia K. (julia_k)


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

von Julia K. (julia_k)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Easylife, ich werd mir die libusb mal zu Gemüte führen!

von Simon K. (simon) Benutzerseite


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

von Easylife (Gast)


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

von Simon K. (simon) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Easylife (Gast)


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

von Simon K. (simon) Benutzerseite


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

von Easylife (Gast)


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

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:

> Wie würde man auf ein HID Gerät zugreifen?

Schau hier:
http://www.lvr.com/hidpage.htm#MyExampleCode

von Julia K. (julia_k)


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

von Thomas (Gast)


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

von mar IO (Gast)


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

von Julia K. (julia_k)


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

von Thomas (Gast)


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

von Konrad (Gast)


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

von Julia K. (julia_k)


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

von Thomas (Gast)


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

von S. R. (svenska)


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

von FX2 (Gast)


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

von Julia K. (julia_k)


Bewertung
0 lesenswert
nicht lesenswert
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
von Uwe (Gast)


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

von Julia K. (julia_k)


Bewertung
0 lesenswert
nicht lesenswert
Aus welchem Dokument hast du das? Wenn ich´s schriftlich liefere glaub´s 
mir mein Betreuer vielleicht.

von Uwe (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Rudi (Gast)


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

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.