Es gibt ja sehr viele Projekte die sich um das Thema "Bau eines MP3-Players" drehen. Gibt es eigentlich Chips, mit denen man das umdrehen kann? Also Mikrofon zu Rohdaten und Rohdaten zu mp3? Gibt es solche encoderchips?
Salve, es gibt zumindest portable MP3-Player (Sticks), die direkt in MP3 aufnehmen können (für die Diktiergerätfunktion). Bei diesen kleinen Dingern halte ich es aber für recht unwahrscheinlich, daß da ein dedizierter IC verwendet wird. Google verrät dazu nix? Mark
Ach du meinst, dass dieser Chip, der da benutzt wird beide Richtungen integriert hat?
Schau mal bei VLSI nach, die haben in der VS10xx - Reihe glaub' ich auch Varianten die Audio im mp3 codieren können, direkt mit analogem Eingang. Auslsesen und Ansteuerung der Schaltkreise geht bequem über SPI. Gruß Konrad
Salve, äh, nein, ja... also auch... ich meinte einfach, daß da sicherlich ein ASIC oder zumindest DSP eingesetzt wird, der sich um mehr kümmert als nur dieses eine Feature. In beiden Fällen jedenfalls kein Standard-IC (für sowas wird in einem portablen Gerät kein Platz sein), an den man als Außenstehender rankommt. Ist aber auch nur meine Vermutung. Mark
So portabel möchte ich das, falls ich es umsetzen werde und falls das dann auch noch funktioniert, gar nicht machen. Es ist nur so, dass ich mit unserem Fehrnseher einen super Radioempfang über den Digitalen Reciver hinbekomme, der nur alle paar Stunden mal aussetzt, wenn der Reciver mal wieder abstürzt.Da dachte ich dass man ja gleich ein IC an den Ausgang heften könnte. Sterio wird es dann zwar sicher nicht, aber das ist immerhin besser als nichts. Und für unterwegs könne ich mir ja irgendwoher so ein Racingpack von Akkus holen, die mir dann 5V geben. Genug von denen und man kriegt sicher eine Laufzeit von einigen Stunden... Das Ding kann man dann bequem im Rucksack mitnehmen ;-)
http://www.micronas.com/products/documentation/consumer/mas3587f/index.php Sieht gut aus. Ist S/PDIF ein digitaler Ein/Ausgang? Wenn ja, dann hoffe ich, dass mein Reciver auch einen hat. Dann wäre alles Perfekt, sofern ich fähig bin den zu verwenden. Noch eine geeignete Bitrage und ich kann die Aufnahmen vielleicht sogar archivieren.... "Digitale Koaxialkabel - auch Koaxkabel, "S/PDIF"-Kabel, Koaxdigitalkabel genannt - übertragen digitale Datenströme als elektrische Impulse, während Optische Digitalkabel (Lichtleiterkabel) die Übertragung als Lichtimpulse über eine Glasfaserstrecke leiten. In der Fachpresse wird häufig die Meinung vertreten, die Klangreinheit und Qualität der Übertragung per Koaxkabel sei besser. Dies ist jedoch genauso falsch, wie die Meinung, eine digitale Verbindung sei störtechnisch gesehen unkritisch, da hier ja angeblich "nur ein Bitstrom aus Nullen und Einsen" transportiert wird, der entweder funktioniert oder nicht funktioniert. Weniger bekannt ist, dass auch dieser digitale Datenstrom im Digitalkabel bzw. Koaxkabel gestört werden kann - und zwar mitunter erheblich. Zwar greift dann die Fehlerkorrektur der angeschlossenen Komponenten, doch nicht selten treten dennoch sogenannte Bild- und Ton-Artefakte auf. Letztlich wird man nie genau feststellen können, welche Artefakte ihre Ursache im Digitalkabel haben und welche in der Software oder Hardware begründet sind. Doch mit einem hochwertigen Digitalkabel sind Sie zumindest an dieser Stelle auf der sicheren Seite. Übliche "Beipackstrippen" weisen oft nicht einmal den nach dem S/PDIF-Standard geforderten exakten Wellenwiderstand von 75 Ω auf und sind für anspruchsvolle Anlagen gänzlich ungeeignet. Hier finden Sie eine repräsentative Auswahl im Bereich elektrische Digitalkabel (S/PDIF-Koaxkabel) ..." Ich sollte mich vorher aber vielleicht noch etwas Informieren...
http://cgi.segor.de/user-cgi-doc/Katalog/p15.shtml http://www.segor.de/bilder/0000cd72.jpg Mh meine ToDo-Liste beinhaltet dann erstmal das Sammeln von Erfahrungen mit dem I²C Bus und dasAnsprechen von irgendwelchen Speicherkarten....
Freak5: Der von Dir zitierte Text scheint aus einem "audiophilen"
Magazin oder ähnlichem zu stammen. Das ist -wie bei solchen Magazinen
üblich- ziemlicher Humbug. Der S/PDIF-Datenstrom wird ohne
Fehlerkorrektur* übertragen; die Fehlerkorrektur findet im jeweiligen
Abspielgerät, also CD-Player oder DAT-Recorder bereits vor dem
S/PDIF-Ausgang statt.
Da es eben keine Fehlerkorrektur gibt, sind Übertragungsfehler auf
S/PDIF-Übertragungsstrecken in der Regel sehr schnell zu hören; ein
nicht korrekt gesteckter optisches Kabel macht sich mit leichten
Knistergeräuschen bemerkbar.
Der von diesen Magazinen betriebene Mystizismus ("von katholischen
Jungfrauen bei Mondschein in Handarbeit gewickelte Kabel klingen
besser") ist -wenn überhaupt- erst bei Übertragungslängen jenseits der
5m in irgendeiner Weise zu rechtfertigen. Darunter tut's die einfache
"Beipackstrippe"; beim üblichen Abstand von Audiokomponenten genügt
auch ein rostiger Schweißdraht.
Deine eingangs gestellte Frage ist mit einem eindeutigen Ja zu
beantworten; S/PDIF ist eine digitale Audioschnittstelle, die seit
-geschätzt- gut zwanzig Jahren Anwendung findet. Es gibt davon zwei
Ausführungen, die optische Übertragung mit Kunstoff-Lichtwellenleiter
und die koaxiale mit Cinch-Steckern.
Welche davon verwendet wird, ist im Grunde genommen irrelevant; die
verwendeten Geräte geben das mit ihren Anschlüssen halt vor.
Die leider in die ewigen Papierberge eingegangene Zeitschrift elrad
(Mutter der c't) hat in den späten 80ern und frühen 90ern sich recht
ausführlich mit dieser Schnittstelle und ihren Anwendungen beschäftigt;
so gab es damals als Selbstbauprojekt unter dem Namen "Take5" eine
ISA-Karte mit S/PDIF-Interface ...
*) Mittlerweile wird über S/PDIF auch anderes als Stereo-Audio-Daten
übertragen; dieser ganze Surround-Unfug verwendet ebenfalls diese
Schnittstelle. Mag sein, daß es da irgendwelche
Fehlerkorrekturverfahren geben mag; ich beziehe mich hier auf die
Schnittstelle von üblichen CD-Playern und DAT-Recordern.
Dumm ist nur, dass mein Reciver sowas nicht hat. Die Möglichkeit ist aber trotzdem cool... Ich meine mein PC hats und auch mein CD-Spieler ;-) Diese Projekte funktionieren doch immer mit MMC-Karten. Kann man sowas nicht prinzipiell auch mit CF machen, oder gibt es da keine Slots und Datasheeds für? Danke für die ganzen Tipps. Ich freue mich schon aufs Basteln ;-)
MMC Karte kannste halt mit SPI ansteuern.. CF brauchste nen paar mehr, 8 gemultiplexte? Also 16Address und 8Data, etwas aufwendiger. dave p.s. gefährliches Halbwissen
@dave: Meinst du mein oder dein Wissen??? Och das mit den 16 Leitungen geht schon in Ordnung... SPI würde ich ja ohnehin für den Audiochip benutzen und die ATmega128 haben genug Pins. Ich habe ebend schon 2x CF, außerdem sind die billiger. So klein bekomme ich die Elektronik ja eh nicht, dass der Kartentyp eine Rolle spielt.
Großer Vorteil von MMC/SD gegenüber CF ist der deutlich lötfreundlichere Sockel. Ein CF-Sockel ist ein 50poliges kleines Ekel. Allerdings ist CF ziemlich einfach anzusteuern, wenn man den TrueIDE-Modus nutzt. Implementiert man 16 Bit-Zugriffe, dann kann man auch echte Festplatten verwenden, was aufgrund der Kapazizät bei mp3-Playern sinnvoll sein kann. 16-Bit-Zugriffe bringen beim AVR aber nichts, da der sowas nicht wirklich kann*. Allerdings spielt bei einem mp3-Player die I/O-Performance auch keine allzu große Rolle. Der Preisvorteil von CF gegenüber SD ist nicht sonderlich groß, das sah früher mal anders aus (1 GByte SD kostet etwa 80 EUR, 1 GByte CF etwa 60 EUR). Datenblätter von beidem (CF/SD-Karten) kann man sich beispielsweise bei SanDisk herunterladen. Davon abgesehen: www.compactflash.org Sockel für beides müsste man eigentlich bei Segor bekommen. *) natürlich kann man mit 'nem AVR 16-Bit-I/O-Zugriffe emulieren, es gibt aber keine Möglichkeit, in einem Taktzyklus 16 I/O-Pins simultan einzulesen und den gelesenen Wert in einem 16-Bit-Register abzulegen - der AVR hat halt keine 16-Bit-Register.
noch mal zum thema störanfällige digital kabel: Also ich habe bei Kunden schon beobachtet, daß die verwendung eines einfachen Stereo Audiokabels (eben nur ein Kanal)als Digitalcoaxialkabel bei geringer übertragungsweite (1,5m) vollkommen ausreichend ist. Wir verkaufen da dann aber lieber Videocoaxialkabel, welche eine bessere Schirmung aufweisen und mit einem Wellenwiderstand von 60Ohm schon ganz gut hin hauen. Natürlich haben wir auch Kunden die eben ein spezielles und teures Digitalkoaxialkabel haben wollen, meinetwegen dann sollen sie eben die 20 EUR für 2 Meter ausgeben. Bei mir zu Hause läuft seit Jahren ein Videokoaxialkabel mit 60 OHM auf 10m einwandfrei und das ganze hat mich nichtmal 5 EUR gekostet.
@Rufus T. Firefly: Da habe ich richtig was verpasst. Aber wenn man nach dem billigsten Preis pro GB sucht, dann sind die CF-Karten immer noch halb so teuer. Außerdem habe ich hier noch eine 500MB und eine 128MB herumliegen, welche aus der Zeit stammen, wo 1GB noch 500E gekostet hat :-) http://www.geizhals.at/deutschland/a144233.html http://www.geizhals.at/deutschland/a129647.html http://www.geizhals.at/deutschland/a46752.html Mh mit den Festplatten meinst du doch normale ATA, oder? Da könnte man ja so ein etwas größeres Microdrive nehmen ;-) http://www.geizhals.at/deutschland/a149026.html Das mit den 16Bit könnte man zu einem Geschwindigkeitsvorteil ausnutzen. Mann müsste nur die Freqenz den Atmels mehr als doppelt so hoch haben als die der ATA-Übertragung. ;-) Mh ich dachte eigentlich, dass 200kbit/s eine nicht zu vernachlässigende Übertragungsrate (für den Atmel)ist... Naja das kommt wohl auch darauf an, wie man den programmiert.
Zur Entscheidung zwischen CF und SD empfehle ich Dir, mal 'nen Kartenleser aufzumachen und Dir die verwendeten Stecker näher anzusehen. Willst Du wirklich CF-Stecker verlöten? Bitte; nur zu. Das von Dir zitierte "größere Microdrive" ist keines. Das ist eine 1.8"-IDE-Festplatte. Hitachi stellt -im Gegensatz zu Toshiba- diese Platten in einer mechanisch anderen Konfiguration her, wo der Anschluss an der Seite untergebracht ist, die, wie es der Zufall so will, exakt so breit wie die kurze Seite einer 2.5"-Platte ist. Daher ist der Hitachi-Anschluss auch steckerkompatibel zu dem einer 2.5"-Platte. Microdrives sind 1"-Festplatten im CF-Typ-III-Gehäuse, und werden derzeit von Hitachi/IBM und Magicstore hergestellt; die maximale Größe scheint bei etwa 5 GByte zu liegen. 4 GByte-Laufwerke von Magicstore bekommt man mit etwas Geschick für unter 150 EUR. Was magst Du mit folgendem Satz meinen? Das mit den 16Bit könnte man zu einem Geschwindigkeitsvorteil ausnutzen. Mann müsste nur die Freqenz den Atmels mehr als doppelt so hoch haben als die der ATA-Übertragung. ;-) Im sogenannten PIO-Modus können auf dem IDE-Interface maximal 16 MByte/sec übertragen werden. Das geschieht mit 16-Bit-Zugriffen von je 125 nsec Dauer. Um mit 'nem AVR in diese Regionen zu geraten, ist ein Memory-Mapped-Interface erforderlich (also nicht über irgendwelche Ports, sondern über das externe Speicherinterface). Mit einem PLD muss dann noch dafür gesorgt werden, daß zwei aufeinanderfolgende Speicherzugriffe (auf zwei aufeinanderfolgende Speicheradressen) zu einem 16-Bit-IDE-Zugriff umgesetzt werden. Nur: Wozu der Aufriss? Die für die Wiedergabe oder Aufnahme von mp3-Dateien erforderliche Datenrate liegt so derartig deutlich unter dieser hier (mp3 mit 128 kBit/sec sind gerade mal 16 kByte/sec), daß mir das ein veritabler Overkill zu sein scheint. Mh ich dachte eigentlich, dass 200kbit/s eine nicht zu vernachlässigende Übertragungsrate (für den Atmel)ist... Ich habe mal mit einem IDE-Treiber für Bascom herumgespielt. Der erzielte beim Beschreiben einer IDE-Festplatte eine Datenrate in der Größenordnung von 40..80 kByte/sec und war alles andere als optimiert. Wichtig beim Beschreiben und auch Lesen von FAT-Dateisystemen ist ausreichend Speicher; es ist sehr hilfreich, wenn die FAT im Speicher gehalten werden kann. Allerdings kann die bereits bei FAT16 für einen µC recht unhandlich werden (max 128 kByte), bei FAT32 werden alle Grenzen gesprengt (wird mehrere Megabyte groß, je nach Plattengröße). Du solltest zumindest Teile der FAT zwischenspeichern, damit Du nicht für jeden Clusterwechsel erneut die FAT komplett einlesen und durchsuchen musst ...
Ich weiß auch, dasss das eine 1.8" HD ist. Das steht ja auch fett dran. Microdrive habe ich in Anführungsstrichen gehabt und da war ein Smily hinter! Mh Kann man zum Speichern der Daten keine SRamzellen nehmen, in die man die Fatdaten steckt? Dann kann man dort parallel zum Lesen der HD die Tabellen durchsuchen? Außerdem kann man beim Schreiben darauf achten, dass man die Festplatte nicht fragmentiert und beim Lesen kann man ja eine art Triplebuffering machen, wodurch man immer genug Zeit hat.. Naja darüber kann ich mir ja sonstwann gedanken machen. Danke für die INfos usw. :-) Über die Übertragungsrate würde ich aber schon nachdenken. Ich möchte die Festplatte, falls ich so eine nehmen sollte ja nicht immer an den PC anshcließen. Also muss der AVR auch für die Übertragung sorgen. Das sollte dann auch nicht zu lange dauern.
. Microdrive habe ich in Anführungsstrichen gehabt und da war ein Smily hinter! Da sind keine Anführungszeichen. Ein "Smiley" ist auch kein ernstzunehmendes Satzzeichen. Mh Kann man zum Speichern der Daten keine SRamzellen nehmen, in die man die Fatdaten steckt? Dann kann man dort parallel zum Lesen der HD die Tabellen durchsuchen? Ich zitier' mich mal selbst: Wichtig beim Beschreiben und auch Lesen von FAT-Dateisystemen ist ausreichend Speicher; es ist sehr hilfreich, wenn die FAT im Speicher gehalten werden kann. Allerdings kann die bereits bei FAT16 für einen µC recht unhandlich werden (max 128 kByte), bei FAT32 werden alle Grenzen gesprengt (wird mehrere Megabyte groß, je nach Plattengröße). Wird's beim zweiten Mal lesen klarer? FAT16 benötigt für jeden Cluster zwei Bytes. Da es maximal ca 65000 Cluster geben kann, resultiert daraus eine Größe von 128 kByte. Bei FAT32 wird's noch schlimmer; je Cluster werden 4 Bytes benötigt. Eine 4 GByte-Platte mit 4 kByte-Clustern hat knapp eine Million Cluster - damit ist die FAT bereits bei einer so winzigen Festplatte 4 MByte groß. Außerdem kann man beim Schreiben darauf achten, dass man die Festplatte nicht fragmentiert Das klingt zwar schön, ist aber unrealistisch, vor allem, wenn die Festplatte auch noch von einem PC mit Daten befüllt werden soll. Über die Übertragungsrate würde ich aber schon nachdenken. Ich möchte die Festplatte, falls ich so eine nehmen sollte ja nicht immer an den PC anshcließen. Also muss der AVR auch für die Übertragung sorgen. Das sollte dann auch nicht zu lange dauern. Ich vermute mal, daß Du mit "der Übertragung" das Befüllen der Platte durch einen PC meinst. Das den AVR machen zu lassen ist ein Holzweg; hier empfiehlt sich der Einsatz einer USB-IDE-Bridge. Die gibt es als fertiges Bauteil zu kaufen und erreichen Datendurchsatzraten am USB-Port, die ein AVR noch nicht mal beim Beschreiben von SRAM hinbekäme. Über eine Signalleitung kann die USB-IDE-Bridge dem AVR mitteilen, daß er jetzt "die Pfoten" von der Platte zu lassen hat, um das Dateisystem nicht durcheinanderzubringen. (Beispiel: CY7C68300A von Cypress, gibt's bei Segor) Ein Zugriff des AVRs auf die Festplatte ist nur erforderlich, wenn mp3-Material abgespielt oder aufgenommen werden soll. Und da spielt die Datenrate eine eher zweit- bis drittrangige Rolle. Du solltest Dir vielleicht mal die Erfordernisse von Dateisystemtreibern ansehen, bevor Du in detailliertere Planungswut verfällst. Natürlich kann man auch FAT32 mit einem µC mit sehr wenig Speicher beschreiben, nur wird dann ein ziemlich ausgeklügeltes Speichermanagement nötig, um wenigstens Spuren von I/O-Performance zu erzielen. Sowohl beim Abspielen als auch Aufnehmen von mp3-Material ist die Verwendung mehrerer Puffer mehr als angesagt; als Puffergröße empfiehlt sich IMHO die Clustergröße des verwendeten Dateisystems. Auch hier wird viel Speicher erforderlich; bei FAT16 und einer 2 GByte-Platte/CF-Karte liegt die Clustergröße beim Maximalwert von 32 kByte. (Es gibt noch eine seltene FAT16-Implementierung mit 64 kByte-Clustern, die aber wird nur von wenigen Betriebssystemen unterstützt und kann daher wohl ignoriert werden, auch wenn so 4 GByte Plattengröße genutzt werden können).
Mist ich dachte wirklich ich hätte Microdribe in Anführungszeichen gesetzt. Son Mist. Aber du denkst doch nicht wirklich, dass es Leute gibt, die sowas in ihren CFII Slot stecken wollen, oder? "Wird's beim zweiten Mal lesen klarer? " Ich hätte externer Ram schreiben sollen. Wenn man sparsam mit den Pins eines großen ATmegas umgeht, dann könnte man doch bis zu ~17 Pins zum Ansprechen von Externen Ram benutzen, so dass man da die Tabelle speichern könnte. Das Beschreiben über den AVR dachte ich an, da man so das Fragmentieren verhindern könnte. Das nimmt dann zwar auch mehr Platz in Anschruch, aber man hat später gar kein Problem das auszulesen. Man könnte sich doch ein Programm zum Beschreiben schreiben, so dass man die Platte unfragmentiert abspeichert (Oder einfach eine eigene Ableitung von Fat bastelt. Ich hätte da schon eine Idee, die natürlich hochgradig statisch ist, aber zum reinen Abspielen geeignet;-) ) Planungswut habe ich schon nicht. Diesen Thread habe ich nur aufgemacht, weil ich noch nicht mal einen Kommerziellen MP3 Player gesehen habe, der einen Aufnahmemodus hat. Da wollte ich wissen, ob es sowas gibt :-)
Angehängte Dateien:
-
MP3-Rec.gif
29 KB
Sowas gibt es. Es ist sogar bezahlbar. Wenn du es selbst machst, wird es vermutlich teurer. Im Anhang das Angebot nur eines Anbieters (Pearl). Bitte nicht als Werbung verstehen. ...
Mh aber falls ich sowas brauche, dann kann ich es mir ja basteln. An einer 60GB-Platte könnte ich damit am Fehrnsehen oder Radio sehr einfach Interviews mitschneiden, wobei da der Bau eines Radios für den PC vielleicht besser wäre... Oder man könnte sonstwas basteln... Eine richtig sinnvolle Aufgabe fällt mir gerade nicht ein, aber da gibt es garantiert genug g Mann könnte diese tragbaren Systeme z.B. endlich mit einer richtigen Akkulaufzeit basteln, zum Beispiel mit einer integrierten Autobaterie und einer 80GB-Platte und einem integrierten Lautsprecher :-) Naja gut, dass ich jetzt weis, wo es sowas gibt. Im Moment muss ich so wie so mein theoretisches Wissen über den I²C Bus an einem Temperatursensor testen :-)
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.