guten morgen alle zusammen :) mir ist da gerade eine idee(und sie wächst noch weiter) gekommen, nur leider bräuchte ich bei interesse noch unterstützung!!! also es geht um einen mp3-player mit diktirgerät. dieser SOLL auf dem msp430 149 aufbauen und den mspgcc verwenden. 1. er sollte mmc/sd und eventuell cf lesen & schreiben können. 2. eventuell usb unterstützung haben ( zum up/downloaden von daten ). 3. eventuell ein tastenfeld besitzen, das eventuell über eine matrix angesteuert werden soll 4. logischerweise ein display ( eventuell ein I²C ) 5. (...) hätte jemand interesse an der mitwirkung??? und allen fragen vorab, ich habe noch keine codes hierfür geschrieben!!!
Es gibt für die Speicherkarten schon Code: http://www.random.linux-site.net/files/unsorted/kartenleser_ti/ Der funktioniert halbwegs, aber es fehlen da Funktionen um ohne die Block-Limits Lesen/Schreiben zu können. Notfalls könnte ich die einbauen. Für MP3 braucht man wohl einen Decoder-Chip, so wie man auch für USB einen braucht; der MSP soll dafür zu langsam sein. Mit Übertakten auf 16 MHz (geht mit 4 V) würde wohl die Rechenleistung reichen, aber das RAM ist sicherlich zu klein, denn schon wegen den 512 Byte-Blöcken der Karte braucht man 2 512 Byte Buffer.
hmm... ich hatte nicht vor, den msp zur dekodierung zu nutzen, sondern, wie du ja erwähnt hast einen extra chip. zur mmc zurück: wie sieht es den mit fat unterstützung aus?? könntest du soetwas auch einbauen???
würde ich auch eh nicht versuchen!!! aber meine bemühung liegt jetzt erstmal bei der mmc via spi ;) ich will erstmal das hinbiegen, denn dieser teil (so scheint mir) ist der anspruchvollste. ps. ich übertackte nie eine uC / cpu!!! erst rechnicht um 200% !!! übertackten = abbbeeeeäääks :P
Also für FAT braucht man mind. 1,2 kB RAM (http://home.t-online.de/home/holger.klabunde/avr/avrboard.htm#cf) und für die Karte gut 1 kB, also insges. 2,2 (+ einiges für den Rest) und sowiel hat selber der große (f149) nicht. Es gibt zwar neuere Typen mit 10 kB RAM, aber die haben dafür weniger Flash, so dass das knapp werden würde.
hmmm dann eventuell noch nen rom an den spi ran ;) nen externes fatstack sozusagen???
Sicherlich zu lahm. Für sowas braucht man einen größeren Prozessor. Der hier müßte ausreichen: http://shop.mikrocontroller.net/csc_article_details.php?saArticle[ID]=51
http://www.circuitcellar.com/msp430/hj.htm der hat es auch geschaft, aber der gibt auch nach bitten keine weiteren sourcen frei schnöff
sooo, hab mal ein wenig bei ti geschnüffelt ;) msp`s mit mehr ram sind z.b. der F1610 (5kb) und der F1611 (10kb) schein mir, als seien das tolle dinger ;) nur leider sind die z.z. in der preview :(
Ja, MP3-Player mit so kleinen Prozessoren gibt's, aber a) wird kein Dateisystem verwendet (sogen. SDS, simple data storage), und b) haben die nur einen kleinen Funktionsumfang.
Hallo, also das 2kb RAM zu wenig sind, kann ich mir wirklich nicht vorstellen! @nobody0: Wie kommst du auf "für die Karte gut 1 kB" ? Hat der Holger auf der oben erwähnten Seite für seine FAT Tests nicht einen Atmega32 im Einsatz der auch nur 2kb RAM hat? Schliesslich wäre da noch dieses MSP430 Projekt von 2002: http://www.del-ojo.com/cherry/mp3.html Da wird zwar mit Smartmedia cards und FAT12 gearbeitet, aber soviel macht das doch im Endeffekt auch nicht aus. OK, der aktuelle yampp 7 MP3 Palyer verwendet z.B. auch kein FAT - nicht_mehr, der yampp 3 nämlich sehr wohl! Gruss, oli
Für die Karte braucht man gut 1 kB: 512 B für den Datentransfer weil nur in 512 B Blöcken gelesen/geschrieben werden kann + 512 B Buffer um 1..512 Byte an jeder beliebigen Adresse lesen/schreiben zu können. Ohne Dateisystem kann man natürlich sich auf das erste Byte eines Blockes beschränken; dann reichen 2 Byte aus, aber 511/512tel der Karte sind dann unbenutzt. Bei einer 512 MB-Karte könnte man so noch 1 MB Lesen/Speichern.
hmm, also wenn ich den Holger auf seiner Seite richtig vertsehe, meint er genau das mit den 1,2kb. Ich werde den Code demnächst als Ausgangsbasis für eine MSP430 SD Card Ansteuerung verwenden. Wenn das mit einem ATmega32 klappt, gehts mit nem MSP430F149 sicher auch. Gruss, oli
klar, ich werd den Code veröffentlichen, wenns fertig ist. Hier noch ein Beweis das FAT32, MMC Card und VS1001K ansteuern sogar mit 1KB RAM auf nem ATmega8 läuft: http://www.phrozen.org/ gruss, oli
Hallo, von Atmel gibt es einen Controller der MP3 integriert hat und ist ab ca. 10,-EUR zu haben. Leider hab ich von deren Programmierung keine Ahnung. Gruß, Benny.
Hi für FAT lesend brauchts eigentlich nicht alzu viel RAM. Sollte sogar gehen ohne einen Sektor als Puffer. Allerdings wirds dann eklig. Allerdings will man zumindest einen Sektor puffern können. Also 512 Byte Sektor + ein wenig Kleinkram reichen. Hab ich mal auf einem 8051 für einen Datenlogger implementiert. Komfortabel und schnell wirds wenn man die komplette FAT im Speicher halten kann. Matthias
Naja, Lesen reicht nicht; Schreiben ist mind. genau so wichtig und mit 2 kB scheint mir da kein Platz für FAT zu sein.
Gut, beim MP3-Player könnte man notfalls aufs Schreiben verzichten, aber normalerweise soll ein MC ja Daten darauf speichern.
Hi natürlich kann man mit 2k RAM FAT schreiben. Sobald man einen Sektor puffern kann geht das ohne großen Aufwand. Komfortabel und schnell wirds, wie ich oben geschrieben habe, wenn man die komplette FAT puffern kann. Dafür reichen aber 2k auch nicht. Matthias
Ja, also ich vermute, dass dutzende Dateien auf der Karte die gelesen und geschrieben werden müssen, mehr als 2 kB RAM benötigen, insbesondere wenn mehrere Dateien gleichzeitig geöffnet werden müssen.
Hi nicht vermuten, machen. Ich (tm) hab das schon auf einem P89C51RD2 gemacht. Der hat 1k SRAM. Gelesen wurde aus einer Datei (Konfiguration) und geschrieben in zwei Dateien (allerdings abwechselnd und nicht wahlfrei) Dazu reichte ein (Lese/Schreib)-Puffer für einen Sektor der CF-Karte und ein paar Variablen für Sektornummern, FAT-Cluster, Dateinamen usw. Insgesamt wurden etwa 650 Byte Datenspeicher und etwa 100Byte Stack benötigt. War etwas umständlich aber ging. Heute würde ich dazu einen Controller mit 2k-RAM nehmen um zwei Sektoren puffern zu können. Pro Datei in die wahlfrei geschrieben werden soll würde ich mind. 512 Byte SRAM ansetzen. Wenn die Anforderungen bei Projektplanung nicht so genau feststehen greift man natürlich lieber zu einem Controller mit mehr SRAM oder einem externen Speicher-Interface. Mehr ist natürlich aus Programmierersicht meist besser. Wenns dann aber um solche Sachen wie (Stör)Ab- und Einstrahlung geht versucht man so viel externe Hardware wie möglich zu vermeiden. Matthias
Tja, das nicht-wahlfrei ist das Problem. Jeweils nur eine Datei öffnen u. lesen oder Schreiben ist wohl noch machbar, aber das reicht ja nicht. Ich müsste aus mind. 3 Dateien lesen u. in 2 Dateien schreiben. Wenn das alles sequentiell gemacht werden müsste, dann wäre da einiges an zusätzlichem Overhead, und dabei ist der Overhead schon beim Lesen der Karte bei 97 %, wenn man die Datentransferrate durch die Taktfrequenz teilt.
Muss da Matthias zustimmen. Hab damals (vorm Krieg) auch mit einem Mega163 (1k SRAM) FAT32 von einer 137GB HDD gelesen. Ohne Buffer, ohne alles. Konnte trotzdem bis 320kbit/s MP3 abspielen und gleichzeitig durch die Verzeichnisse wechseln und scrollen (die wurden aber extern gespeichert). Okay, man muss da schon ein wenig tunen, aber geht. Jetzt mache ich das ganze nochmal richtig, für ATA/ATAPI Devices mit Master und Slave. Dafür gönne ich mir aber einen Mega128, da kann man sich schön austoben.
Das man etwas nachbauen möchte, dass es (teuer) bei ELV oder Conrad gibt verstehe ich ja noch, aber warum etwas, dass es billiger und kleiner bei ALdi fertig gibt??? cu joern
Hm, falsches Board erwischt? ;-) Es geht doch hier doch nicht nur um den praktischen Nutzen oder geldwerten Vorteil (unter dem Gesichtspunkt müsste man fast alle Hobbies bleibenlassen). Es geht darum, selbst ein tolles Projekt zu realisieren (nicht nur "nachzubauen") und dabei etwas zu lernen und Spaß zu haben. Und darum, dass es auch in Zukunft Leute gibt, die für Aldi günstige Geräte bauen können.
moin erstmal, also zum lesen von ner mmc braucht man nur ein byte. man muss nur ein 74*00 zwischen schalten. dann kann man gleichzeitig 1 byte von der mmc lesen und 1 an den mp3 decoder senden. auf phrozen.org ist ein schaltungs bild. zum lesen muss die cpu 512kb ram für fat + app ram haben. 512kb deshalb, weil man immer nur in gesamten sectoren schreiben kann. das ist eigentlich kein problem wenn man von zb einem ftdi die daten holt, die geschrieben werden. da man da 1 byte holen und schreiben könnte aber, man muss ja den fat ändern. das heisst relevanten sektor finden, komplett auslesen, fat-chain ändern, und ganzen sector wieder schreiben. deshalb braucht man einen 512kb puffer. mmc/sd kann ja nur maximal 512kb. john
achso, mit geschwindigkeit ist kein problem. ich kann bis 320kbit/s abspielen mit 4mhz cpu
Du meinst wohl 512 Byte und nicht 512kb, oder? Und zum Lesen/Schreiben auf dem MMC verwende ich immer 512 B Blöcke, auch weil ich zwischengeschaltete Funktionen verwende, durch die 1..512 Byte von/an jeder Adresse gelesen/geschrieben werden können. Deshalb brauche ich 2x512 B Buffer: Einen in dem die Daten von/an den Karten-Treiber übergeben werden und einen zum Swapen. Ansonsten müsste man ja ständig überprüfen ob man über eine Block-Grenze hinüberlesen/hinüberschreiben würde (was die Karte nicht macht u. deshalb abgefangen werden muß). Im Prinzip ginge das zwar und man käme mit 512 B Buffer aus, aber das würde den Code zu einem gewaltigen Spaghetti-Code aufblähen. Alternativ kann man natürlich nur ein Byte an den Adressen 0, 512, 1024 usw. verwenden; dann braucht man mit call by reference überhaupt keinen Buffer. Ich kenne aber kein Dateisystem, dass damit verwendet werden kann.
Hallo Also ich habe ein kleines Minidateisystem für MMC welches mit 2 Buffern a 512Bytes ca. 1,6KByte benötigt und halt mit einen Buffer 1,1KByte. Ausreichend für einen MP3Player mit MEGA32. Die 1,1 bzw 1,6Kbyte ergeben sich daraus das die FAT Tabelle für 1 File in den Speicher gelesen wird, und halt der Buffer. Der Vorteil es muß nicht jedesmal in der FAT gesucht werden welcher Cluster der nächste ist somit ist das Filesystem auch recht schnell. zur zeit kann nur Fat16 gelesen werden. Schreibroutinen kommen aber bald hinzu. Download auf meiner HP. Mfg uli
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.