Speicherbedarf Mp3-Player

Johannes Hofmann schrieb:
> Und: welche Taktfrequenz ist mindestens für ein entspanntes Abspielen,
> im Worst Case von MP3s mit 320kbit/s, nötig?

also 320kbit/s wirst du wohl kaum schaffen, dafür wird deine 
FAT-Implantierung auf nem Atmega zu langsam sein.

Johannes Hofmann schrieb:

>also 320kbit/s wirst du wohl kaum schaffen, dafür wird deine
>FAT-Implantierung auf nem Atmega zu langsam sein.

Schmarn, VS1002 und Atmega32 auf 16Mhz funzt bei mir Einwandfrei mit MP3 
auf 320kBit/s, höher habe ich noch nie getestet allerdings.

echt, schafft der das so schnell, der kleine Atmega. ich hab mich immer 
daran orientiert:

Beitrag "Re: MMC/SD-Karte mit FAT16 an AVR"

Puffer (B)  |  Zeit (s)  |  Geschw. (kb/s)
------------------------------------------
     8      |    13      |      78
    16      |     9      |     114
    32      |     6      |     171
    64      |     5      |     205

Wer von euch hat denn nun recht?

Holger meint, es reicht bereits ein mega8, Julian dagegen, die gesamte 
Mega-Reihe reiche nicht aus.

Wenn es mit nem Mega8 klappen würde, wär ich sehr beglückt 
(Platinengröße).

Update: Haha, da wurde in der Zeit, in der ich die Antwort schrieb ja 
schon was neues gepostet.

Also das hier ist der letzte Benchmark, den ich jetzt von dieser 
FAT-Implantierung gefunden habe:

http://www.roland-riegel.de/sd-reader/benchmarks/


Ausschnitt:

1

2

Read FAT-16

3

Chunk size (Bytes): 2048  

4

Time (s)          : 10.0

5

Data rate (kB/s)  : 204.8

6

7

Test conditions: ATmega128 at 14.745 MHz, 128 MB SD card, FAT16-only configuration, 2 MB file, FAT16-only configuration, buffered access, without timestamps.

8

9

10

Read FAT-32

11

Chunk size (Bytes): 2048  

12

Time (s)          : 8.5

13

Data rate (kB/s)  : 240.9

14

15

Test conditions: ATmega128 at 14.745 MHz, 4 GB SDHC card, FAT32, 2 MB file, buffered access, without timestamps.

Ups, du hasst ja 320 kbits geschrieben und hier sind die Werte in 
kbs.

Also dürfte es klappen, da 200 kbs in etwa 1600 kbits sind.

Edit: Ist hier wohl etwas problematisch, kbit/s fett zu schreiben ;)

Ich möchte ja die Dateien direkt von meiner Muckesammlung auf die 
SD-Karte ziehen.
Aber da benötige ich ja FAT32. Da wird's ja noch enger...

Naja, mal ausprobieren.

Johannes Hofmann schrieb:
> Ich möchte ja die Dateien direkt von meiner Muckesammlung auf die
> SD-Karte ziehen.
> Aber da benötige ich ja FAT32. Da wird's ja noch enger...
>
> Naja, mal ausprobieren.

Nö, passt doch. FAT32 ist sogar noch schneller!
320 kbits (Kilobits) entsprechen 40 kbs (Kilobytes).

Nach dem Benchmark von Holger schafft seine FAT32-Implantierung bei 
14,745 MHZ 240 kbs

Das ist etwa 6mal so schnell, wie du für die Wiedergabe von 320 kbits 
brauchst!

Müsste also dicke reichen.

holger schrieb:
> ATMega8: Text LCD für aktuelle Songanzeige plus ein paar Taster
> zur Bedienung. Keine Menüführung, nix sortieren, keine Playlists.
> Also ein simples Ding. Vorspulen ist schon fast Luxus ;)

Kann ich so absolut bestätigen:
In meinem mp3 Player werkelt ein mega8 @ 8MHz, angeschlossen ist eine SD 
Karte, ein VS1011, ein Inkrementalgeber mit Taster und ein 2x20 VFD.
Nachdem ich die Unterstützung von langen Dateinamen und dem ID3 Tag 
eingebaut habe, war der Speicher nahezu komplett voll (man kann die 
Anzahl an freien Bytes an Händen und Füßen abzählen).
Song vor, zurück, lauter, leiser und Pause. Mehr brauche ich nicht und 
mehr gibt es auch nicht.

Normale 192kbit/s mp3s spielt er übrigends bei einer nicht 
fragmentierten Speicherkarte selbst @ 4MHz noch problemlos ab.
Da der VS10xx einen 2kByte großen Puffer hat, ist die Datenrate sowie 
das Dateisystem alles andere als kritisch. Solange man die Taster nicht 
per Warteschleife entprellt, sollte es da also keine Probleme geben, 
selbst wenn alles nicht perfekt optimiert ist.

Als Software für das Dateisystem kann ich die hier übrigens sehr 
empfehlen:
http://elm-chan.org/fsw/ff/00index_e.html
Das ist mit Abstand das am meisten ausgereifte was es so an freier 
Software gibt.

Hallo,

ich habe vor Zeiten mal einen Player mit dem 8515 mit 32k externem Ram 
gebaut, 8MHz getaktet, Decoder war ein MAS3507D. Quelle eine 2,5"HD 6GB, 
Filesytem das Amiga FastFileSystem. Einfach, weil es dafür ideal war und 
ich noch einen Amiga in Betrieb hatte. Ende 2000 habe ich mich wohl 
nicht mit FAT rumärgern wollen.

Display 2x16 Zeichen, unten dynamische Menüanzeige, oben Titeldaten.
Angezeigt wurde nur MP3-Tag (der alte), der scrollte auch zur Laufzeit, 
Steuerung des MAS3507 für Lautstärke, Höhen und Tiefen über I2C auch zur 
Laufzeit ohne Aussetzer. Geteste allerdings damals nur bis 192kBit.

Wirklich kritisch war nur die Buffersteuerung zwischen HD und Ram und 
MAS.
Der Ram diente vor allem zum Preload der Startsektoren der Titel und war 
Batterie gepuffert. Sonst raspelte nach dem Start des Players die Platte 
erstmal 1-2 Minuten rum und suchte die Titel zusammen.

Die Problemstelle ist wirklich der SD-Karten-Zugriff. es ist auch 
relativ nutzlos, sich über die maximale Transferrate zu freuen.
Kritisch ist die minimale z.B. beim Sektorwechsel, die muß der Buffer 
und der Decoder 100% sicher überbrücken können, sonst gibt es Aussetzer.

Ich würde auch heute erstmal einen AVR auf ein Steckbrett nageln, 
SD-Karte und MP3-Decoder ran und die Sachen zum Spielen unter allen 
Umständen bringen.
Dabei muß dann genug Rechenzeit für den Rest übrigbleiben.
Wenn man z.B. in der Titelliste blättern will, während gespeilt wird, 
dann muß die im Ram parat liegen. Sonst würde ich da keine reale Chance 
sehen.

Würde mich vermutlich auch heute zum Mega8515 + 32k/64k S-Ram bringen, 
mir gefällt die Kombination. ;-)

Gruß aus Berlin
Michael

Noch mal ne rein informative Frage: Wie lange habt ihr denn für den 
MP3-Player gebraucht. Also Aufbau der Schaltung, Verstehen des 
FAT-Zugriffs, der Ansteuerung des VS-Chips usw.?

Danke

Wenn man alles auf einmal macht und vorher noch nichts auf einem der 
Teilgebiete davon gemacht hat, und auch wirklich alles verstehen möchte, 
also nicht nur aus fertigen Libs etwas zusammenbauen möchte, dann Wochen 
bis Monate.

Ich hatte z.B. SD Karten und FAT vorher schon mehrmals verwendet, daher 
dafür auch fertigen Code.
Für meinen mp3 Player habe ich vom Entwurf bis zur ersten abgespielten 
mp3 rund 1-2 Tage gebraucht. Bis die Software und das Gehäuse usw. 
fertig war, hat es aber Wochen gedauert, da man immer wieder kleine 
Fehler beheben muss, die man nur im Betrieb bemerkt. Außerdem kommen 
immer wieder neue Features hinzu (auslesen der LFN, des ID3 Tag usw.).

Der VS ist im Vergleich zur SD Karte und dem Dateisystem aber extrem 
einfach.
Daher würde ich ein fertiges Dateisystem verwenden, das garantiert 
funktioniert (wie z.B. das von elm-chan). Alternativ kann man eine kurze 
mp3 auch mal in den Flash packen oder über UART streamen. Zum Testen des 
VS reicht das.

Ich hab mir schon zig Projekte runtergeladen nur fehlt halt der große 
Überblick. Bspweise weiß ich nicht, wie ich den fertigen Code, etwa von 
elmchan in mein Projekt integrierern kann. Explizit, welche 
Softwareschnittstellen ich ansprechen muss.
Z.B. wenn der FAT-Code einen neuen Sektor benötigt, wie ich diesen 
Befehl der SD-Karten-Routine übergebe.
Hab vorher noch gar nichts Derartiges gemacht.

Schau dir mal die Sampleprojects von elm chan an. Da ist fertiger Code 
für AVRs dabei, also eigentlich alles komplett fertig. Du musst nur die 
Pinnummern für SPI an deinen µC anpassen.
Die Routinen für die MMC Karte stecken in der mmc.c.

Da sind ja auch Schaltpläne dabei.
Warum hat er denn die Leitungen zur SD-Karte mit Pullups versehen? Und 
was bringt der Pulldown-Widerstand für SCK?

An DO der SD Karte muss ein Pullup sein, denn nur dann kann man zwischen 
Tristate und Low unterscheiden. Ansonsten ist die Init der SD Karte ein 
Glücksspiel.
Ein Pullup am CS Anschluss der SD Karte ist sinnvoll, damit diese z.B. 
beim Programmieren des AVRs nicht auch Daten auf die SPI Leitungen 
treibt. Der Pulldown an SCK ist nicht ganz so wichtig.

ok, werd ich alles mit in meine Schaltung mit aufnehmen.
Aber wie sieht es denn mit dem anderen Teil meiner Frage aus.
Angenommen es befindet sich eine einzige MP3-Datei auf der Karte. Welche 
Schritte muss ich abarbeiten, um die auslesen zu können?

Hallo Sumynona

Der Ablauf ist klar, nur häng ich halt gerade an der Stelle das 
FAT-System der Karte zu lesen.
angenommen auf der Karte liegt ne Datei "Test.mp3", geh ich dann ganz 
normal über fopen("Test.mp3"); ?

Welche FAT Routinen verwendest du jetzt? (Davon hängt das ganze ab, wie 
die Funktion genau aufgerufen wird,) aber im groben ja, so in etwa geht 
das.
Dann kann man (je nach FAT Routine) Block oder Byteweise die Daten 
lesen.

Naja, wie gesagt, ich hab jetzt hier den FAT-Unterbau von elmchan 
"eingebaut".

http://elm-chan.org/fsw/ff/00index_e.html Hier gibt's ja die 
Erläuterungen zu den Funktionen. Und da hat er ein f_open verwendet.

Also Datei öffnen und dann Byte-weise den Data-Stream an den VS1001 
übergeben, wenn ich das richtig verstanden habe.

Ja, genau. Allerdings ist das Byteweise übertragen sehr ineffizient wie 
man hier sieht:
http://elm-chan.org/fsw/ff/img/rwtest.png

Da der VS10xx mindestens 32 Bytes frei hat, solange DREQ aktiv ist, 
würde ich immer 32Byte Blöcke senden. Das dürfte deutlich effizienter 
sein.

Aber einen Schritt nach dem anderen. Bring das ganze erstmal soweit zum 
Laufen, dass du dir über f_opendir und f_readdir den Verzeichnisinhalt 
ausgeben lassen kannst.

Bei den ElmChan-Samples http://elm-chan.org/fsw/ff/ffsample.zip
gibt es für den AVR unter Main.c eine IOinit.
Doch ich konnte nicht finden, wo der Herr Chan den uC deklariert, bzw. 
dass in der io.h der richtige uC ausgewählt wird.
Auch versteh ich nicht, warum, er in der IOinit gleich mehrere Ports auf 
"HIGH" setzt.

Könnt ihr mir da mal wieder aushelfen?

Johannes Hofmann schrieb:
> Doch ich konnte nicht finden, wo der Herr Chan den uC deklariert, bzw.
> dass in der io.h der richtige uC ausgewählt wird.

Das macht der Compiler automatisch wenn man dem den richtigen µC 
mitteilt. Darum musst du dich also nicht kümmern.

> Auch versteh ich nicht, warum, er in der IOinit gleich mehrere Ports auf
> "HIGH" setzt.

Das Beispielprogramm verwendet nicht nur die MMC/SD Karte sondern auch 
noch CF oder IDE. Die haben einen 16bit Datenbus.

Hallo
Was mach ich denn mit der Fehlermeldung?
Es wurde auch keine .hex-Datei zum Programmieren erstellt.


gcc plug-in: Error: Object file not found on expected location 
C:\User\....\default\MP3.elf

Der Code compilierte ohne Probleme.

1

int main (void){

2

3

  FATFS *fs;         // Work area (file system object) for logical drives

4

    FIL fsrc, fdst;      // file objects

5

    BYTE buffer[4096];   // file copy buffer

6

    FRESULT res;         // FatFs function common result code

7

    UINT br, bw;         // File R/W count

8

9

10

    // Register work area for logical drives

11

    f_mount(0, &fs[0]);

12

13

14

    // Open source file on the drive 1

15

    res = f_open(&fsrc, "srcfile.dat", FA_OPEN_EXISTING | FA_READ);

16

17

18

19

20

    // Close all files

21

    f_close(&fsrc);

22

23

    // Unregister work area before discard it

24

    f_mount(0, NULL);

25

26

27

28

}

Hab mal nen DJ MP3-Player nach dem Vorbild des berühmten CDJ100 von 
Pioneer in nen Mega32 reingepresst. Mit Cue-Punkt im Titel setzen usw.
Hatte außerdem noch so ne lustige 8ter Tastenreihe wo man Jingles 
drauflegen konnte die bei Knopfdruck abgespielt wurden.
Das ganze komplett in ASM geschriebene.
FAT16 von SD/MMC Karte und über den gleichen Hardware-SPI wieder raus an 
den MP3-Decoder.
Mit alphabetischem Ordnen in den Verzeichnissen, ID3-Tags, Playtime (+ 
und -), Display und FAT Schreibroutinen zum speichern der 
Jingle-Tasten-Belegung waren die 2k RAM fast bis aufs letzte Bit 
ausgereizt. War schon ne ganzschöne Trickserei.
320kbit hat er aber Problemlos abgespielt. (Ob er das in C programmiert 
auch geschafft hätte, weiß ich allerdings nicht)

Hallo

Kann mir evtl. jemand sagen, welche Funktionen von chan ich weglassen 
kann?
Denn im Moment passt der Code leider nicht mal in nen Atmega32. Mist.

Ich will erstmal testen, ob eine Testdatei auf die SD-Karte geschrieben 
werden kann.

Keine, das geht da anders: Schau mal in der ff.h, da gibt es 
verschiedenste Einstellungen. Da kannst du z.B. auf nur Lesen 
einstellen.

Aah, hab ich überhaupt nicht gesehen. Na das nächste Mal geh ich alle 
Dateien aber Zeile für Zeile durch ;-)

Aber wie wird der Compiler denn mit diesen Defines angewiesen, bestimmte 
Teile des Codes nicht in das Programmierfile mit reinzunehmen?

Dafür gibt es ja #ifdef... und #endif  wenn etwas definiert(bei ifdef) 
ist, wird der code bis #endif Nicht übersprungen ...

Das reicht aber irgendwie noch nicht.

DAs hex-File ist mit den für mich wichtigen Optionen 84kB groß.

Was kann man denn da noch machen?

Was hast du alles eingestellt? Falls du LFN aktiviert hast, deaktiviere 
das erst mal. Das braucht aufgrund der großen Tabellen sehr viel 
Speicher.

Ok, LFN war schon mal gut.
Aber nun ist das Problem aufgetaucht, dass Chan ja den PORT E nutzt, der 
ATmega aber gar keinen hat.

in der Funktion mmc.c gibt es ein paar Funktionen bezgl. Power 
on/off/check, die ich aber gar nicht benötige.

Auch die rtc.c brauche ich ja nicht.

Wie ist da am besten zu verfahren?

Hast du in dem Projekt auch den Code für CF, IDE usw. drin?
Alles rund um PortE usw. kannst du entfernen, da dies ja nur für CF/IDE 
benötigt wird.

Die Power Sachen kannst du auch weg lassen, da deine SD Karte vermutlich 
dauerhaft mit 3,3V versorgt wird.

Ok, jo nur SD und immer mit 3,3V
Was ist mit diesem RTC?

In ff.c unter _USE_IOCTL stecken ja noch mehrere Aufrufe der 
Power-Funktionen drin.
Kann ich da einfach die betreffenden Zeilen löschen, oder geht das noch 
komfortabler?

Aber die Powerfunktionen hab ich doch schon entfernt.

Bitte vergesst mich nicht ;-)

Hallo

Ich bin jetzt bei Disk_initialize().
Doch irgendwie wird das CS der karte nicht auf LOW gezogen.

1

#define SELECT()  PORTD &= ~(1<<PD4)  /* MMC CS = L */ 

2

#define  DESELECT()  PORTD |= (1<<PD4)  /* MMC CS = H */

Aufruf in der Send_CMD-Funktion ist ja

1

  DESELECT();  

2

  SELECT();

Da müsste ja auch mal was passieren. Hab ne LED an CS angeschlossen und 
die müsste ja dann mal ausgehen, wenn SELECT aktiviert ist.

Ist bestimmt ein simpler Fehler, den ich nicht seh...

Ok auf dem SPI tut sich überhaupt nix!

Hier ist die Initialisierung, die direkt zu Beginn ausgeführt wird(Das 
ist aus dem fertig übernommenen Code):

1

  PORTB = 0b10110101;      /* Enable drivers */

2

  DDRB  = 0b11000111;

3

  SPCR = 0b01010000;      /* Initialize SPI port (Mode 0) */

4

  SPSR = 0b00000001;

Ich habe auch mal den Programmer abgeklemmt, der auch am SPI hängt, aber 
keine Besserung.
Muss was Internes sein.
Das Fusehäkchen im AVR-Studio-Programmer-Menü ist gesetzt und grau 
unterlegt mit nem roten Fragezeichen. Es lässt sich auch nicht 
entfernen.

ChipSelect funktioniert.

Du musst DDRB und PORTB entsprechend anpassen, so dass MOSI, SCK und SS 
Ausgang sind und der Pullup an MISO an ist.

Ich dachte die SPI-Zuweisung macht die iom32.h automatisch.

Na jedenfalls siehts jetzt mit DDRB = 0b10110000;
 und PORTB |= (1<<PB6) | (1<<PB4);
nicht anders aus...
Immer noch kein Wackeln auf dem SPI.

Aber der SPI ist doch nun über diese Zeile SPCR = 0b01010000;
so initialisiert, dass es funktionieren müsste.

weil ich mein Multimeter drangehängt habe und sich auf keiner Leitung 
das geringste regt.
Ich weiß auch, dass meine SD-Karte funktioniert, da ich sie mit einer 
Software-SPI-Routine schon mal initialisiert hatte.

Aber ich probier die SPI-Frequenz noch mal runter zu setzen.

So im Gegensatz zu voher ist jetzt der SPi Teiler 128 anstatt nur 2. Der 
uC läuft jetzt auch mit 1 MHz
Da seh ich nur an der SCK-Leitung bischen was wackeln. Das krebst so bei 
3mV rum.

Genau die beiden Zeilen hab ich mir grade von nem Ulrich Radig-Projekt 
rüberkopiert.

Hier ist er endlich ;-)

So die Orange Leitung hängt ist MOSI/DI, Grün ist SCK und Blau MISO/D0
Und dann noch paar Dioden, die mir zur Fehlersuche dienen.
Abblockkondensatoren an den VCC-Pins des uC hab ich auch dran.

Ich hatte wie gesagt die Karte schon mal initialisiert, aber da hatte 
ich eben Software SPI und da war die Schaltung auch auf ner 
Lochrasterplatine verlötet. Die Leitungslängen zur SD-Karte waren aber 
ähnlich lang.

Jo 3,3V.
Ich habe aber auf irgendeiner Homepage schon mal nen ähnlich wüsten 
Aufbau gesehen und dort funktionierte es auch.

Ich werde mir heute Abend mal ne Schleife bauen, die dann ständig den 
SPI beansprucht.
Und wenn ich da das Multimeter dranstecke, stellt sich entweder ein 
Mittelwert irgendwo zw. 3,3 und 0V ein oder nicht.
Bin sehr gespannt...

So, SPI funktioniert.
SCK und MOSI haben nen Spannungsmittelwert von 1,.. Volt, wenn ich 
ständig sende.
Nur die Initialisierung klappt immer noch nicht.
habe auch die Kabel vom uC zur Karte noch so kurz wie möglich gemacht.
Habe gerade den Pullup an D0 bzw. MISO der Karte nicht dran. Ist das 
kritisch?

Fällt euch noch was ein, wo der Fehler stecken könnte?
Die Software ist ja bereits erfolgreich vom Ersteller gestestet worden, 
zwar an einem anderen Atmega als meinem, aber das wird's wohl nicht 
sein.

Ich halte mal fest:
SPI funktioniert und ist korrekt angeschlossen
Ports auch korrekt
Spannungsversorgung ist auch i.O.
SD-Karte ist auch i.O.
der uC funktioniert auch

An der Schaltung ist bis auf die etwas längeren Kabelverbindungen auch 
nix verkehrt.

Wenn über SPI ein Byte geschickt wird, dann wird doch bitweise auch das 
MISO-Register des Slave durchgeschoben oder?
Also müsste man auf der Leitung ja auch ein Wackeln sehen, wenn ständig 
Daten über den SPI geschickt werden, gell?

Ich hab mal ne andere Frage:
Wo hast du die Verbinderkabel zum senkrechten rein stecken ins 
Steckbrett her die "isolierten Drahtbrücken" habe ich auch aber das ist 
immer etwas friemelig mit dem raus suchen der passenden Länge.

Hierher: http://www.sureelectronics.net/

Die haben auch nen Shop bei Ebay. Alles supergünstig. Trotz Versand aus 
Fernost.

So, ich hab den Fehler gefunden.
Hatte mir ne Schleife gebastelt, die die ganze Zeit CMD0 an die Karte 
gesendet hat. Bei Erfolg-->LED an.

Gestartet. Nix passiert. Aber als ich die SD-Karte rauszog!!, da ging 
die LED auf einmal an. Es war also ein Kontaktproblem, aaaargh.

Hallo

Ich hab hier mal mein Projekt angefügt. Es wäre toll, wenn jemand von 
euch das mal bei sich reinladen könnte und mir sagen könnte, ob der Code 
so funktioniert.
Ich zweifle nämlich langsam an meinen Fähigkeiten, weil ich diese simple 
Grütze nicht zum Laufen kriege.

Ihr müsst praktisch nur den Ausgangspin für das Chipselect in der mmc.c 
ändern.

Vielen Dank