www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MP3 SPI Problem


Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mahlzeit zusammen!

Ich baue mir gerade einen MP3 Player mit ATMega 32 16 Mhz (später soll 
es der 8515 mit 64kB XRAM) sein. Decoder ist der VS1011e, Speichermedium 
ein 1 GB Kingston.

Ich habe die SPI Kommunikation mit der SD Karte erfolgreich herstellen 
können, und die Datenrate getestet: ca 350 Kbyte/s. Wunderbar. FAT 16 
ist auch schon drauf, nur habe ich jetzt ein kleines Problem: Ich 
brauche noch eine SPI Schnittstelle für den VS1011e. Soll ich eine in 
Software implementieren? Ist diese schnell genug. Oder soll ich beide an 
eine Schnittstelle anschließen? Ich möchte eure Erfahrungen hören. Wie 
oft kommt denn das DREQ Signal, wieviele Bytes kann ich von der Karte 
kopieren, bis es kommt?

Ich habe es Softwaremäßig so aufgeteilt: Es werden immer Signale von der 
SD Karte gelesen, in den (X)RAM verfrachtet, DREQ löst einen Interrupt 
aus und dann kriegt der VS seine 32Kb Daten. reti

Den XRAM brauche ich außerdem für die (halbe) FAT Tabelle.

Wäre sehr froh wenn ihr mir ein wenig von euren Projekten erzählen 
würdet
PS: Ich mache alles in Assembler.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein MP3 Player basiert zwar nicht auch einen AVR aber auf einen Renesas 
M16C.
Zwei enzelne Schnittstellen sind einfacher zu handeln. Es geht aber auch 
mit einer.

> Wie oft kommt denn das DREQ Signal, wieviele Bytes kann ich von der Karte
> kopieren, bis es kommt?

Das hängt von der Bitrate ab. Kannst du dir aber selber anhand der 
Bitrate und der Buffer-Größe ausrechen.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werde Lieder zwischen 128 und unter 300 bits/s verwenden. Um jetzt 
eine grobe Information über die Datenrate zum VS1011 zu haben heißt das, 
dass ich mehr als 300 b/s schicken muss, da der Decoder auch zeit zum 
dekodieren bracht. Aber wieviel genau? Hat jemand irgendwelche Messwerte 
bzw. wie kann ich die Datenrate berechnen?

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Während du Daten schickst kann der Dekoder ja auch schon dekodieren. Bei 
beispielsweise 128kBit/s dekodiert der Dekoder eben 128000 Bit in einer 
Sekunde, also musst du im Durchschnitt dem Dekoder jede Sekunde 128000 
Bit rein schieben.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(Ausgehend von der oben gennaten Datenrate)
Wenn du die Daten mit Durchschnittlich mit 1Mbit/s zum Vs1011 schickst, 
musst du im Durchschnitt ca. 1/8 einer Sekunde Daten schicken und 7/8 
ist die Schnittstelle frei.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Während du Daten schickst kann der Dekoder ja auch schon dekodieren. Bei
>beispielsweise 128kBit/s dekodiert der Dekoder eben 128000 Bit in einer
>Sekunde, also musst du im Durchschnitt dem Dekoder jede Sekunde 128000
>Bit rein schieben.

Kann er nun oder tut er das wirklich?

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kann er und tut es auch

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß noch immer nicht genau ob ich SD und VS beide an Hardware SPI 
anschließen soll. Der VS macht mir keine Sorgen, aber die SD Karte kann 
laut Spezifikation immmer noch Signale senden, selbst wenn ihr CS auf 
High ist. Es kann die ganze Bus Kommunikation durcheinanderbringen. Ich 
weiß außerdem nicht, wie hoch die Datenrate bei Soft SPI sein kann. Laut 
ATMEL App Note um die 444 Bits/s. Das ist mir ein wenig zu langsam. Ich 
habe mir überlegt den Timer für die Soft SPI implementierung zu 
verwenden. Im Forum ist von so vielen MP3 Player Projekten die Rede, wie 
haben es die gelöst ??

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg wrote:
> Ich weiß noch immer nicht genau ob ich SD und VS beide an Hardware SPI
> anschließen soll. Der VS macht mir keine Sorgen, aber die SD Karte kann
> laut Spezifikation immmer noch Signale senden, selbst wenn ihr CS auf
> High ist. Es kann die ganze Bus Kommunikation durcheinanderbringen.

Ist das echt so ?
Ich habe VS1011 und SD Karte am Hardware SPI eines mega8 hängen. Läuft 
problemlos.
Die Datenrate (Daten mit Dateisystem von der SD Karte lesen und an den 
VS1011 senden) liegt bei max etwa 100kByte/s, könnte aber noch etwas 
optimiert werden (was für mp3 aber nicht notwendig ist).

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Der VS macht mir keine Sorgen, aber die SD Karte kann
>laut Spezifikation immmer noch Signale senden, selbst wenn ihr CS auf
>High ist.

Wie bitte ? Das ist absoluter Unsinn. Wo steht das ?
Kann ich auch nicht nachvollziehen da ich einen
Vs1001 und SD schon am selben SPI hatte.

Die SD sendet GAR NICHTS wenn CS high ist.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß jetzt nicht an welcher Stelle genau aber es steht weiters auch, 
dass CS während eines Datentransfers nicht auf high gesetzt werden 
sollte. Was soll ich jetzt tun, wenn ich Daten von der Karte lese und 
plötzlich wird DREQ low und ich muss CS vom SD auf high setzen. Soll ich 
da Multiple Block Read verwenden, Dann wenn DREQ kommt, CMD 12 (Stop) 
senden und dann einfach CS auf High stellen. Habe ich überhaupt soviel 
Zeit? Wäre um jeden erdenklichen Tip dankbar.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich weiß jetzt nicht an welcher Stelle genau aber es steht weiters auch,
>dass CS während eines Datentransfers nicht auf high gesetzt werden
>sollte.

Das stimmt. Du musst einen ganzen Block abholen. 512Bytes plus CRC.

>Was soll ich jetzt tun, wenn ich Daten von der Karte lese und
>plötzlich wird DREQ low

Gar nichts. Lese einen Block von der SD und füttere den VS
damit solange er Daten annimmt. Der VS hat einen internen Puffer
den er erst mal abarbeiten muss. Solange er das tut hast du genug
Zeit den nächsten Block von der SD zu lesen.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin seit vier Wochen an der ganzen Sache dran und stehe hier kurz 
vor dem Ende (psychisch und vom Projekt). Das einzige woran es halt 
scheitert ist, dass ich so viel schon im Internet recherchiert und das 
Datenblatt des VS1011 schon x mal ausgelesen habe, aber trotzdem einfach 
nirgendwo einen Hinweis darauf finde, wie lange dieses IC braucht um 
z.B. diese 32kb in seinem FIFO zu decodieren und auszugeben, sodass es 
wieder die nächsten bytes braucht. Ich bin normalerweise eher der 
Theoretiker, der zuerst alle Datenblätter liest, alles schön ausrechnet, 
proggt und dann zu löten beginnt. OK, ohne praktische Tests (z.B. Max 
SPI Datenrate von der SD Karte ermitteln) geht gar nichts aber die 
Theorie finde ich sehr wichtig. Kann mir denn niemand sagen wie schnell 
der VS mit dem Decodieren ist, sodass ich mich endlich zwischen Soft und 
Hard SPI entscheiden kann.

PS: Wenn ich dieses Projekt einmal fertig stelle, dokumentiere ich es 
ausführlich, stelle es ins Netz, sodass keiner mehr im Forum mit solchen 
Fragen nerven muss

Autor: fubu1000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,
mach beide an den Hardware SPI des Megas.
Reicht mehr als aus ich spiele mit nem Vs1002 Lieder von 320kbit/s ab, 
mehr habe ich noch nicht getestet. Ist aber laut Datenblatt auch das 
Maximum.
Du holst einfach immer 512byte von der SD und sendest die danach immer 
wen DREQauf LOW an den VS1011. Nach dem senden deiner 512 byte an den 
VS, holste wieder 512byte von der SD und so weiter. Bei mir sind keine 
Glitches zu hören in den Liedern und nebenbei steuert der Atmega noch 
die Zeitanzeige aufm Display und und und.
Viel Spass noch bei deinem Projekt und GRUSS.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wie lange dieses IC braucht um z.B. diese 32kb in seinem FIFO zu
> decodieren und auszugeben, sodass es wieder die nächsten bytes braucht.

Das habe ich doch oben schon genau beschrieben. Schraub jetzt mal das 
Brett vor Kopf ab. (ist nicht bös gemeint)

FIFO = 32KBit (habe ich nicht überprüft, ist das wirklich so viel?)
MP3 = 128KBit/s

Also muss der VS genau 128kBit in einer Sekunde dekodieren, sonst würde 
die Abspielgeschwindigkeit nicht passen. Daraus folgt, das der VS den 
genau 1/4 Sekunde benötigt um diesen FIFO zu dekodieren. Da 128k 
diviediert durch 32k = 0,25s also 1/4s. Wenn die MP3-Datei mit einer 
höheren Bitrate kodiert ist, muss der VS die Daten entsprechend 
schneller dekodieren und der FIFO muss entsprechend schneller/öfter 
befüllt werden. Ist doch eine ganz einfache Rechnung.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder auch so gerechnet, (immer ausgehend von ein 128kBit/s MP3 Datei)
du ließt ein Block von der SD-Karte (512 Bytes = 4096 Bit). Bei 
128kBit/s reicht diese Datenmenge also für 4096/128000 Sekunden also 
0,032 Sekunden. Du must also ca. 32 mal (1/0,032) in der Sekunde einen 
Secktor der SD- Karte in den VS schieben.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe nicht alles gelesen und habe auch den VS1011 noch nicht 
benutzt.
Ich habe früher mal mit MAS3507 und einer 2,5" HD auf einem 8515 mit 32k 
Ram rumgespielt.

Ein Ringpuffer im Ram und 2 Flags dazu. Der Buffer wird von der HD 
gefüllt, dann wurde der Transfer zum MAS freigegeben. Der hat relativ 
wenig internen Puffer, der wurde also erstmal gefüllt.

Der MAS meldet sich ja bereits, bevor sein Puffer leer ist, das sollte 
der VS ja auch machen. Das Auffüllen des Puffers geht auch schneller, 
als das Abspielen. Das Problem ist also nur, wie groß dieser Ringpuffer 
sein muß, damit er in solchen "Häppchen" von HD/SD-Karte gefüllt werden 
kann, die den Transfer zum MAS/VS nicht stören. Ich habe damsls 
Blockgrößen geholt, also 512 Byte von der HD. Dann nachschauen, ob der 
MP3-Chip was will, wenn ja, dessen Buffer nachfüllen. Nachschauen, ob 
der Zeiger in die unteren 512Byte zeigt, wenn ja, die oberen von HD/SD 
nachfüllen und merken. Wenn der MP3-Chip seinen Buffer dann wieder von 
oben holt, die untere Hälfte von HD/SD füllen.

Das war zumindest bis 192kBit auf einem 8MHz getakteten 8515 keine 
Problem, incl. XMEM-umschalterei wegen HD-Zugriff am selben Bus, I2C zum 
MAS, um ohne Aussetzer Höhen/Tiefen/Lautstärke zu verstellen und 
LCD-Anzeige (2x20) incl. Software-Scrollen der Titelanzeige.

Die Abstimmung der Puffergröße und er "Häppchen" zu MP3-IC und 
HD/SD-Card ist eben etwas kritisch, viel hilft da nicht unbedingt viel, 
es muß zu Zugriffszeiten und internen Puffergrößen passen.

Auch eine SD-Card sollte bei ReadSector Pause machen dürfen, also Sector 
anfordern, 128Byte lesen, CS inaktiv, CS wieder aktib und die nächsten 
128Byte vom Sector lesen, müßte eigentlich auch da gehen.

Gruß aus Berlin
Michael

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Auch eine SD-Card sollte bei ReadSector Pause machen dürfen, also Sector
> anfordern, 128Byte lesen, CS inaktiv, CS wieder aktib und die nächsten
> 128Byte vom Sector lesen, müßte eigentlich auch da gehen.

Davon dass das funktioniert kann man NICHT ausgehen.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DER VS1011 hat einen FIFO von 32 k BYTE, ist recht und gut deine 
Rechnung Martin, aber hast du auch selbst je einen MP3 Player gebaut? 
Weil du nämlich nicht weißt wie groß der FIFO ist. Ist ja egal. Zu 
deiner Rechnung: das alles ist OK, wenn man davon ausgeht, dass die 
Leistung des Decoders ordentlich ist. Was ist aber, wenn der IC für 32KB 
z.b. 1/2 sekunde braucht (ist extrem). dann muss ich ihm schon vorher 
die Daten gesendet haben. wenn er so in realtime arbeitet ist das sehr 
gut. Tut er das wirklich?

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Martin: da hast Du völlig recht, ich habe mal in meine ziemlich alten 
MMC-Unterlagen geschaut...

Was ich jetzt nicht gefunden habe: geht bei allen? MMC/SD-Cards 
READ_BLK_PARTIAL? Dann wäre es ja wieder kein Problm, einen Block in 2 
oder 4 Teilen zu lesen.
Meine Beschreibung sagt nur, daß Start und Ende im selben physikalischen 
Block liegen müssen.

Gruß aus Berlin
Michael

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> aber hast du auch selbst je einen MP3 Player gebaut?

Ja, habe ich.

http://martinsuniverse.de/projekte/audiohplayer/au...

In meinem ersten Design waren SD-Karte und VS1011 an der selben 
SPI-Schnittstelle. Das funktionierte auch gut. In meinem zweiten Design 
habe ich es der Einfachheithalber getrennt. Habe ja genug HW-SPIs :-) .

> DER VS1011 hat einen FIFO von 32 k BYTE

Ich habe jetzt nochmal das Datenblatt überflogen, aber dies nicht auf 
den ersten Blick gefunden. Wo steht das denn? Für die Rechnung ist es 
aber egal, dann musst du nur andere Zahlen einsetzen.

> wenn man davon ausgeht, dass die Leistung des Decoders ordentlich ist.

Sie ist ordentlich.

> Was ist aber, wenn der IC für 32KB z.b. 1/2 sekunde braucht (ist
> extrem). dann muss ich ihm schon vorher die Daten gesendet haben.

Genau. Dazu fragst du die DREQ Leitung ab, um zu ermitteln, ob noch 
Platz im FIFO ist. Bzw. sagt dir die DREQ Leitung "Hey Junge mach mal 
hinne, ich habe gleich keine Daten mehr im FIFO"

> wenn er so in realtime arbeitet ist das sehr gut. Tut er das wirklich?

Ja tut er.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja wenn man min. 32KB reinschieben kann, dann wird auch der FIFO so 
groß sein. Ich probiere es jetzt einfach mal mit 512KB von der Karte 
lesen und den VS füttern und nochmal lesen...

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 32KB reinschieben kann

Kannst du mir mal schnell die Seite im Datenblatt nennen wo das steht.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seite 19 bzw. Abschnitt 7.4 auf der version 1.04

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann müsste er ja mt 32KB länger als eine sekunde auskommen

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ACHTUNG!!!

Da steht 32 Byte. NICHT Kilo. Damit ist aber nicht der gesamte FIFO 
gemeint. Sondern nur der Punkt wo sich DREQ ändert. Undzwar 32 Byte vor 
Voll und 32 Byte vor Leer.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst allso immer 32 Byte Blocke senden ohne zwischendurch zu 
schauen ob sich DREQ geändert hat.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist schon klar, habe mich mit Kilo verschrieben, aber du hättest bit 
gemeint.

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Vorgehensweise
512byte lesen, in Sückchen an den Dekoder füttern, wieder 512 Byte 
lesen, funktioniert. Ich hab das selbst mal mit einem ATmega103 und dem 
VS1011 gemacht, und hatte nur einen 512 byte Puffer im RAM dafür. Du 
kannst aber auch 2 Puffer nehmen, im Interrupt den Dekoder füttern, und 
im Hauptprogramm immer wenn ein Puffer leer ist den neu einlesen, 
während der Interrupt solange den anderen benutzt.
Einen weiteren 512 Byte puffer hatte ich immer für den aktiven Teil der 
FAT, das ganze Programm ist also mit dem internen Ram ausgekommen.

Autor: Konz (former IOP) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut ich versuchs

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.