mikrocontroller.net

Forum: Projekte & Code USB Soundkarte für den XMega mit DMA Datenübertragung und Interrupt getriebenen FIFO USB stack


Autor: Felix H. (masterq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ihr lieben.
Ich wollte mir gerne eine kleine Soundkarte auf den XMega programmieren. 
Da ich nichts gefunden habe das ich ausreichend gut finde habe ich mir 
selber einen USB-Stack geschrieben und eine Soundkarte mit ISONCHRONOUS 
Endpoint aufgesetzt.
Da das dann doch eine ganze Menge arbeit war habe ich sie 
veröffentlicht.
Sagt mir gerne was ihr davon haltet.

Da ich immer noch an Einzelheiten bastel gibt es keine ZIP File, sondern 
der ganze kram ist auf GitHub zu finden:
https://github.com/masterxq/xmega-usb-soundcard
https://github.com/masterxq/xmega-usb-soundcard/releases

Ich habe bei der Entwicklung sehr auf die Effizienz geachtet, und 
benutze überall wo es möglich ist den DMA um die Daten zu übertragen.

Wenn jemand hier Windows hat würde mich interessieren ob die Karte dort 
auch funktioniert. Bisher habe ich sie nur unter Linux testen können.

Ich freue mich auf eure Kritik.
Liebe Grüße und einen schönen Sonntag
Felix

Autor: Niklas Gürtler (erlkoenig) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Warum hast du denn die Microsoft String Deskriptoren mit drin? Die 
braucht's doch für Geräte mit Standard-Klassen nicht, bzw. verhindern 
ggf. das Laden des Standard-Treibers unter Windows...

Namen wie "__DESCRIPTOR_H__" sind übrigens für User-Code verboten und 
nur der Standard-Library vorenthalten:
https://wiki.sei.cmu.edu/confluence/display/c/DCL3...

Autor: Felix H. (masterq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist ein Relikt, ich nehme das gleich mal raus. Danke.

Autor: Felix H. (masterq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ist getan, ich hätte es eh irgendwann weg geräumt. Aber ich wusste 
nicht welchen Effekt das hat. Deshalb habe ich das mit dem Code cleanup 
nach hinten verschoben. Ich werde gleich mal einen neuen Version tag 
machen und neue hex Files bereitstellen.
Das mit den Defines habe ich auch nicht gewusst werde ich aber erst 
später ändern. Da liegt einiges vor mir. Das ist längst nicht das 
einzige Projekt wo ich das so gemacht habe.
Schöne Sache du kennst dich ja ganz gut aus.
Nochmal vielen dank für deinen Blick.

Autor: Felix H. (masterq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
https://github.com/masterxq/xmega-usb-soundcard/re...
Würde mich freuen wenn du dir es nocheinmal ansiehst.

: Bearbeitet durch User
Autor: Niklas Gürtler (erlkoenig) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
In der usb_standard.h ist das Microsoft-Zeug ja immer noch drin :)

Die USB-Deskriptoren mit "packed" anzulegen find ich etwas unelegant 
weil das eine Sprach-Erweiterung ist und man sich nicht so ganz sicher 
sein kann dass das Layout korrekt ist... Würdest du das z.B. auf eine 
Big-Endian Plattform kopieren wären die Integer falsch herum.

Ich hab das so gemacht:
https://github.com/Erlkoenig90/f1usb/blob/master/s...
https://github.com/Erlkoenig90/f1usb/blob/master/s...
Erfordert aber C++ und ist auch nicht so ganz einfach.

Autor: Felix H. (masterq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
entschuldige die späte Antwort.
Es ist leider das zweite mal das ich sie verfasse. Habe sie wohl beim 
letzten mal nicht abgeschickt:(
Naja, in der usb_standard.h ist das Zeug ja eigentlich auch nicht so 
schlimm, ich werde hoffentlich irgendwann einen Fork erstellen und eine 
Standard library für USB auf den XMega implementieren. Dann werde ich 
das ganze auch nochmal aufräumen und richtig einsortieren. Mit meiner 
Datei-Struktur, Benennung und der Aufteilung der Daten sowie mit einigen 
Abstraktionsebenen bin ich eh noch überhaupt nicht zufrieden. Ich habe 
es trotzdem rausgenommen. Auf C++ werde ich für die nächste Zeit für 
meine µC Projekte nicht umsteigen. Sonst nutze ich es gerne. Aber ich 
finde es ungeeignet da man auf dem µC so wenig RAM zu Verfügung hat und 
man mit C mit weniger Aufwand mehr Kontrolle hat. Da die meisten Felder 
eh nur ein Byte breit sind, ist wohl bis auf weiteres die hübscheste 
Lösung alle weiteren mit macros zu füllen. Man dann bei der Macro 
Definition ja auch abfragen welche ob es little- oder big-endian ist und 
entsprechend ein anderes macro zur Verfügung stellen oder einen Fehler 
werfen. Aber ehrlich gesagt ist mir das auch relativ unwichtig, da diese 
Implementierung sehr stark mit der Hardware verknüpft ist und sich 
deshalb sowieso nicht ohne weiteres portieren lässt. Was die headers und 
die Descriptoren angeht haben das andere umfangreicher und besser 
strukturiert gelöst. Von daher gehe ich davon aus das es nicht so 
wichtig ist das dieser Teil der Implementierung zu diesem Zeitpunkt sehr 
portabel ist. Besser Strukturiert wäre würde ich höher priorisieren.

Liebe Grüße und vielen Dank
Felix

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.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.