Hallo Ich habe nun endlich meinen DJ-MP3-Player fast fertig und stehe nun vor einem Problem. Der Player schiebt die Daten eines Songs bis zum letzten sector des letzten clusters der Datei in den Decoder-Chip (sta015). Das Problem: Windows ist so freundlich dass es, wenn ich eine Datei auf die SD/MMC schreibt und diese sagen wir 200 und ein halbes cluster groß ist, im übrigen halben cluster die Daten stehenlässt, welche vorher an dieser Stelle standen. Also z.B. Daten einer gelöschten mp3-Datei. Diese Daten spielt natürlich mein Player jetzt mit ab. Ich kann das ende auch nicht mit Hilfe von Filesize des Directory-entrys bestimmen, da ich in bestimmten Funktionen den Titel nicht am Anfang starte, sondern ihn ab einer zuvor abgespeicherten Position lese. Der Directory-entry wird in diesem fall nur sehr schwierig zu lesen sein. Ich hoffe dass jemand auf diese zugegeben schwierige Problematik einen Rat weiß.. MfG Matze
Gast
#632772
Ich denke, Du musst in jedem Fall zusätzlich zur Dateiposition die Dateigröße mitspeichern, wie soll es sonst gehen? Was würde bei Deinem Player wohl passieren, wenn Du das Gerät ausschaltest, die Datei extern löschst und dann die Wiedergabe fortsetzen willst? Insofern ist eh der komplette Pfad\Dateiname, Tracklänge und Position notwendig.
beim Neustart liest er sich den Pfad den Dateiname und ein offset aus einer auf der Karte befindlichen ini-datei, errechnet sich dementsprechend die position. Sinn der Sache ist, dass wenn ich auf einen der 8 mit diesen positionen bechriebenen knöpfe drück, der gewünschte titel sofort ohne verzögerung abgespielt wird. Funktioniert bis auf diese eine sache hervorragend. Dateiende wird bis jetzt erkannt, wenn in der clusterkette kein weiteres cluster gefunden wird...
Gast
#632808
Aha, interessante Anwendung. Aber was spricht denn dagegen, beim Zerpflücken der Ini-Datei auch mal kurz nach der mp3-Datei zu sehen? Zur Not kommt die Dateilänge in die Ini-Datei :-)
Das ganze läuft auf 'nem mega32, und da ist jedes byte RAM sehr wertvoll ;-). Wenn ich für jeden der 8 titel die länge sagen wir mal in sektoren mit abspeicher sind da auch mal wieder 16 byte weg. da komm ich schon langsam in den bereich des stack rein. und das ganze nur wegen nem sekundenbruchteil falschen titel am ende der datei. das muss sich doch anders lösen lassen...
Gast
#632816
>Ich kann das ende auch nicht mit Hilfe von Filesize des Directory-entrys >bestimmen, da ich in bestimmten Funktionen den Titel nicht am Anfang >starte, sondern ihn ab einer zuvor abgespeicherten Position lese. Der >Directory-entry wird in diesem fall nur sehr schwierig zu lesen sein. Wieso ? Benutzt du kein FAT ? Filesize steht im direntry. >Dateiende wird bis jetzt erkannt, wenn in der clusterkette kein weiteres >cluster gefunden wird... Naja, wenn Filesize nicht ausgewertet wird kommt beim letzten Cluster halt bis zu 64kb Schrunz aus dem Lautsprecher ;)
Ich benutze fat, um im startup die datei und die startposition zu finden. Nur beim jeweiligen abspielen eben nicht um zeit zu sparen.
Gast
#632830
>Das ganze läuft auf 'nem mega32, und da ist jedes byte RAM sehr wertvoll
Dann nimmst halt nen mega644 und gut is.
@Matthias Du kannst nicht nur das Dateiende Sektor basierend auswerden (über letzten Cluster). Das Dateiende kann sich irgendwo innerhal eines Sektors befinden. Du brauchst einen Filepointer und die Filesize um Bytegenau zu sagen wo das Ende ist, auch innerhalb eines Sektors.
Ok, bytegenau werde ich mir sparen, 32 byte speicher hab ich echt nicht übrig. aber ich werd wohl nicht drumrum kommen, das ende sektorgenau mit zu speichern. mit max.511 byte falschen daten bringt der mp3-decoder noch kein schiefes tönchen raus
Gast
#632864
Immerhin ist nun klar, dass es ein Problem ist, aber lediglich ein Mangel an Speicher. He! 32 Byte weniger Stack hat noch niemandem geschadet :-) Vielleicht ein wenig Fehlersuche, naja. Wird das EEPROM schon sinnvoll genutzt? Ich finde die Sektormethode jedenfalls unausgegoren. Aber mich fragt ja keiner.
Die sektor methode ist nicht so gut wie möglich, aber so gut wie nötig denk ich. das problem ist mir schließlich erst aufgefallen, als ich eine 512 mb karte im player abgespielt habe (16sec/cluster) bei der testkarte mit 256 mb (8sec/cluster) hat man nichts gehört, obwohl es da dann ja auch max. 8 "schlechte" sectoren mit abgespielt hat. da dürfte man einen sector eigentlich nicht hören. eeprom wird momentan noch nicht genutzt, wird aber später noch eingebunden. Ich denke, ich werde anstelle des startclusters der datei die position des directory-entrys der datei abspeichern. dann muß ich nicht erst beim zugriff umstandlich das entry suchen und hab alle gesuchten daten schnell zur hand (startcluster und filelenght). die 16byte mehr muß ich dem stack halt noch abringen. ich freu mich schon auf komische programmsprünge ;-)) Vielen Dank für die vielen Ratschläge. MfG Matze
@Matthias Schau dir mal meinen Code des MP3stick auf www.mictronics.de an. Ich belege damit derzeit 1,8K RAM und 19K Flash eines ATmega128. Und da sind viel mehr Sachen zusätzlich drin als nur MP3 von SD zum Dekoder schieben. Womit verbrauchst du den deinen ganzen RAM? Vielleicht kannst du deinen Code ja mal vorstellen, ich wäre interessiert.
der MEGA32 hat nur 2K RAM. Damit verwaltet er das dateisystem mit ordnern, sortiert sich die dateien im ordner alphabetisch, liest natürlich den id3tag, erstellt und verändert seine ini-Datei auf der karte und realisiert eine bedienung nach dem vorbild eines CDJ-100 dj-cd-players noch fragen?
Ja, wenn du soviel Funktionalität unterbringst, warum dann ATmega32?
Das frag ich mich langsam auch... ;-) Ich hab damals mit dem mega32 angefangen, weil er der größte war, der noch Beinchen hat. Ich war damals noch kein Freund von smd-löten. Aber ich muß sagen, es reicht. Ich hab die 16 Byte noch untergebracht, und damit ist er jetzt eigentlich fertig. Und ich muß sagen, ich hab dadurch sehr gut gelernt, resourchenschonend zu programmieren. In einer Hochsprache wäre das sicherlich nicht möglich gewesen. Ist halt der Vorteil von ASM.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.