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.
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.
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?
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.
(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.
>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?
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 ??
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).
>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.
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.
>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.
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
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.
> 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.
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.
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
> 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.
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?
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
> aber hast du auch selbst je einen MP3 Player gebaut? Ja, habe ich. http://martinsuniverse.de/projekte/audiohplayer/audiohplayer.html 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.
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...
> 32KB reinschieben kann
Kannst du mir mal schnell die Seite im Datenblatt nennen wo das steht.
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.
Du kannst allso immer 32 Byte Blocke senden ohne zwischendurch zu schauen ob sich DREQ geändert hat.
Das ist schon klar, habe mich mit Kilo verschrieben, aber du hättest bit gemeint.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.