Hallo Gemeinde, ich will mir für in meinem Auto eine Soundanlage bauen. Da meine Musiksammlung fast nur aus MP3's besteht, dachte ich mir folgendes: Ich könnte ne Notebook-HD nehmen und dort all diese Dateien draufspielen. Die HD kommt dann ins Auto. Im Autoradio-Schacht soll dann die komplette Anlage Platz haben. Also ein kleines Bedienpanel mit LCD und paar Tastern, die ganze Elektronik für den Player selbst plus noch ein Verstärker. Wobei der Verstärker für mich kein Problem darstellt, der ist relativ einfach. Hingegen mit dem Player selbst haperts mir noch etwas. Grundsätzlich mal: - Brauche ich zum Steuern der Festplatte und des Bedienpanels und zum Übertragen der MP3-Daten von der HD zum Decoderchip viel Rechenleistung, oder reicht da ein 'normaler' Feld- Wald- und Wiesen-Controller mit ca. 16 MHz? Reichen vielleicht sogar 8 Bit? - Zum MP3-Decoder: Welcher ist am einfachsten und bietet trotzdem gute Qualität? Ich hätte persönlich jetzt den VS1001k genommen, gibts bessere? - Zur HD: Darf ich ne HD überhaupt ins Auto verbauen? Ich meine bezüglich der Temperaturschwankungen und der Erschütterungen (Obwohl eine Notebook HD da sicher widerstandsfähiger ist als eine 'normale'). Wäre vielleicht eine Speicherkarte (CF oder so) besser? Wenn ihr mir da weiterhelfen könntet wäre das ganz toll. Gruss
Eine MP3 ist im allgemeinen mit 128-192 kBit/s kodiert. Im Extremfall können es aber auch 320 kBit/s sein. Das sind also 40 kB. Diese werden zu jeweils 16 Bit von der HD gelesen. Also müssen max. 20480 Lesevorgänge pro Sekunde von der Festplatte gemacht werden. Hinzu kommt noch ein gewisser Overhead an Kommandos und für das Dateisystem. Das ganze muß dann seriell an den MP3-Dekoder geschaufelt werden. Das kann eigentlich so ziemlich jeder Controller. Von Vorteil ist aber ein externes Speicherinterface und ein Hardware-SPI. Die Dekoder von VLSI sind schon sehr gut und recht einfach zu verwenden, allerding solltest du nicht den alten VS1001k nehmen, sondern mindestens den VS1002 oder besser den VS1033 oder VS1053. Ab dem VS1002 besitzen die Dekoder ein etwas anderes, aber einfacheres Interface und sie haben auch so einige Verbesserungen abbekommen. Eine Notebookfestplatte kann man schon ins Auto einbauen. Es gibt sogar einige kommerzielle Geräte, die Notebookfestplatten im Auto verwenden. Wenn ich mich recht entsinne haben sowohl Fujitsu als auch Toshiba vor ein paar Monaten sogar eine Serie auf den Markt gebracht, die einen erweiterten Temperaturbereich aufweisen und somit explizit für den Automobilsektor geeignet sind.
Ich kenne mich jetzt nicht mit den Mp3-decodern aus, aber ich denke anstatt der Festplatte ist es sinniger z.B. eine SD-Karte zu nehmen. Die 8GB dinger bekommt man schon ab 20€ und die sind vom Interface her wesentlich einfacher mit µCs anzusprechen und erfordern nicht so viele Leitungen. Gabs hier nicht schonmal ein fertiges Mp3-Decoder-Board auf ARM-Basis? Das wäre eine gute Grundlage denke ich. Ich wollte sowas auch mal machen, allerdings war bei mir das Problem eher der Verstärker, weshalb ich es dann wieder verworfen habe. Nun habe ich jedoch schon ein Mp3-Radion mit SD-Karte und USB-Anschluss. Für den Preis kann man sich das schon fast nicht mehr selber bauen.
@Timmo H.: Ich baue es nicht selber wegen des Preises. Das lohnt sich nämlich tatsächlich nicht. Nein, ich baue es nur so aus Spass selber ;) Kaufen kann jeder. @Kai: Wie denkst du, macht man das genau? Jeweils die ganze MP3-Datei von der HD lesen (oder z.B. immer in 40 kB-Blöcken), das im RAM zwischenspeichern und von dort zum Decoder schaufeln, oder immer Wort für Wort von der HD direkt zum Decoder? Was ist besser?
Bei den VS10xx ist es so, dass sie dem Controller über einen separaten Pin (DREQ) mitteilen, wenn der interene Puffer leer wird. Sobald dieses Signal gesetzt ist kann man dem Dekoder ohne weitere Überprüfung dieses Signals 32Byte übergeben, da dieser einen FIFO-Puffer besitzt. Eine größere Datenmenge (mehrere kByte) zwischenzuspeichern ist mit den meisten Controller nicht möglich und auch nicht nötig. Ich habe es immer wie folgt gelöst: In meinem Controller reserviere ich 1kByte für die MP3-Daten. In diesen 1024 Byte kann ich genau zwei Sektoren der Festplatte speichern. Beginne ich mit dem Abspielen einer Datei, so lade ich von der Festplatte einen Sektor in den Zwischenspeicher und starte den Dekodiervorgang, indem ich dem VS10xx Daten schicke. Dieser fordert dann zyklisch neue Daten an, indem er sein DREQ Signal aktiviert. Während Daten aus dem ersten gepufferten Sektor an den VS10xx übertragen werden lese ich den zweiten Sektor von der Festplatte in den Zwischenspeicher. Ist der erste gepufferte Sektor dann komplett an den VS10xx übertragen, so wird der zweite übertragen und der dritte Sektor von der Festplatte in den Zwischenspeicher geladen, d.h. der erste Sektor gepufferte Sektor wird überschrieben. Dieses Spiel wiederholt sich dann so lange bis die Datei vollständig angespielt wurde. Aller x-Sektoren (je nach Formatierung des Speichermediums) muß die Position des nächsten Clusters auf der Festplatte gelesen werden. Hierbei muß zwar auch ein kompletter Sektor der FAT gelesen werden, aber man muß ja nicht alle 512 Byte irgendwo speichern, sondern es reicht wenn man sich den betreffenden Wert rauspickt (2 Byte bei FAT16 bzw. 4 Byte bei FAT32). Aus der gelesenen Clusternummer kann man dann die Position des Clusters auf der Festplatte errechnen und dort mir lesen beginnen.
@Kai: Na, das Verfahren, das du beschreibst, klingt ziemlich simpel! Dann könnte man ja das DREQ-Signal mit einem Interrupt-Eingang verbinden, wo die Intterupt-Routine dann schön die Daten von der HD zum Decoder schaufelt. Oder so ähnlich. Das scheint mir tatsächlich nicht allzu viel Rechenleistung zu brauchen! Danke noch für die Tipps mit den VS1002..1053. Ich muss mir da auf alle Fälle mal noch Muster besorgen ;) Ansonsten, sind die Dinger softwareseitig komplex oder relativ simpel anzusteuern? Ich meine, ob es viele Register zu initialisieren gibt usw., oder ob der Decoder alles selber macht. Ich nehme an, dass ich mit dem Ausgangssignal des Decoderchips direkt auf den Eingang meines Verstärkers gehen kann, oder? Ich werde einen MOSFET-Verstärker bauen. Das sollte ja ansich passen. Noch ne andere Frage: Ich plane noch, eine Line-In Buchse einzubauen (falls ein Freund mitfährt, kann er dann da seinen MP3-Player oder Discman oder was weiss ich anschliessen). Irgendwie muss ich ja dann das Signal entweder vom Line In oder vom Decoderchip auf den Verstärkereingang schalten können. Wie löst man das? Ich denke mal, mit einem gewöhnlichen Analogmultiplexer so im Stil von CD4050 oder wie der auch wieder geheissen hat, wird das nichts. Kannst du mir da auch noch was empfehlen? Grüsse
Hi, ich habe mir vor kurzem ein 2008er Sonyradio mit mp3 CD und USB Anschluss gekauft. Bin damit bestens zufrieden, einziger Nachteil ist, dass der meine 60G externe HD nicht mag. Ansonsten für 100€ eine kostengünstige, saubere Lösung, zumal USB Sticks - fast nix mehr kosten - man kann sie "so in die Mittelkonsole ballern" - zerkratzen nicht - sehr schnell Beschreib- und Löschbar - passt mehr drauf als auf ne CD Dafür lohnt der komplizierte Selbstbau mit Rechner & HD fast nicht, finde ich. VG, /th.
@Random ... Tobias sagte doch bereits >Ich baue es nicht selber wegen des Preises. >Das lohnt sich nämlich tatsächlich nicht. Nein, ich baue es nur so aus >Spass selber ;) Kaufen kann jeder. Basteln macht nunmal Spaß.
Hallo Tobias, ich habe mir vor zwei Jahren auch einmal einen MP3 Player gebaut, der auch in einem KFZ-Radioeinschubschacht passt. Ich verwende hierzu einen VS1003. Die MP3 Decoder von VLSI sind eigentlich relativ einfach zu initialisieren und zu konfigurieren. Im Prinzip gibt es sogar einen Testbefehl um einen Sinus auszugeben. Damit kann man vorab schon überprüfen ob der Decoder richtig konfiguriert wurde. Anschließend braucht man eigentlich nur noch das DREQ Signal überprüfen (Interrupt) und Daten schaufeln. Der Decoder, die HDD und die Schnittstellen steuere ich über einen PIC18F8722 an (8Bit, 40MHz). Zwischenspeicherung von 512Bytes (MP3) mach ich mit dem internen RAM des Controllers. Viel mehr zwischenspeichern macht eigentlich nicht viel Sinn, es sei denn du machst nebenbei irgendwelche zeitintensiven Berechnungen (z.B. Spektrum). Ich habe zusätzlich noch 1MByte externes SRAM und 512kByte Flash drauf. Damit sollte eigentlich der Speicher nie knapp werden... Den Schaltplan zu meinem Design findest du unter http://www.poms-engineering.at/html/index.php?inc=projects_mp3_player&lang=de Vielleicht hilft dir das in irgendwelcher Weise.
@Rooney: Dein Projekt klingt interessant. Ich schaue mir mal deine Schemas an. Danke jedenfalls für den Link! Könnte ich ggf. mal auch deinen Code anschauen (initialisierung des VS1003)? oder hast du in PIC-Assembler codiert? Wenn ja - dort blick' ich eh net durch :p Was meinst du, reicht es von der Rechenleistung her, wenn ich einen Microcontroller mit ca. 16 MHz Takt verwende? z.B. einen 8051? Grundsätzlich muss der ja nur folgendes machen: - Daten von der HD holen - diese per SPI zum Decoder schaufeln - prüfen, ob der Benutzer auf dem Panel eine Taste drückt wobei mir letzteres Kopfzerbrechen bereitet. Denn der Controller muss ja dann, wenn der Bentzer z.B. die Lautstärke einstellen will, noch irgend einen Text auf das LCD ausgeben (ich dachte an ein Punktmatrixdisplay, oder ist das zu popelig? ansonsten hätte ich noch ein 2.4" Farb-TFT rumliegen (mit integrierem Controller)). Wird der Micro vom Daten holen und rüberschaufeln nicht so arg ausgelastet, dass man da noch irgendwas anderes machen kann? Wie gross ist der interne Buffer des VS1xxx denn? Und wie lange hält der ungefähr hin, wenn die Bitrate worst case 192 kBits beträgt? Noch was: Im Datenblatt habe ich grade was von "supported MP3 modes" gesehen. Wie kann ich auf dem PC eine Datei überprüfen, ob sie in einem dieser Modes ist? Denn offenbar kann der VS1xxx nicht jede x-beliebige MP3-Datei abspielen, liege ich da richtig?
@Tobias: Ein 8051 kann reichen, allerdings würde ich keinen nehmen, der 12Clocks/Cycle oder 6Clocks/Cycle braucht, bzw. müsste ein solcher entsprechend schneller getaktet werden. Der zuletzt von mir eingesetzte 8051er konnte bei 12Clocks/Cycle mit 40MHz getaktet werden bzw. bei 6Clocks/Cycle mit 20MHz. Ich denke, der hätte dafür gereicht. Das Problem bei einem 8-bitter ist, dass du den evtl. vorhanden Daten- und Adressbus nicht benutzen kannst, da die Festplatten ein 16Bit breiten Datenbus besitzen. *) Der VS1003 unterstützt alle MP3 Formate. In den drei Tabellen zu MPEG 1.0, MPEG 2.0 und MPEG 2.5 sind alle Kominationen aus Samplerate und Bitrate als unterstützt gekennzeichnet. Ebenso für WMA. *) Es gab mal einen 8Bit-Modus, der aber wohl von keiner einigermaßen aktuellen Festplatte mehr unterstützt wird.
Wenn du überlegst einen 8051er zu nehmen, dann kannst du auch den AT89C51SND1C nehmen. Der hat schon vieles drauf, was man für einen MP3-Player braucht. - MP3 Dekoder - IDE/ATAPI Interface - MMC/SD Interface - USB Interface - Keyboard Interface (quasi zusätzliche Interrupteingänge) Das Datenblatt dazu findest du bei www.atmel.com. (Darf man hier eigentlich Datenblätter mit anhängen oder gibt das rechtliche Probleme?) Momentan versuche ich auch einen MP3-Player auf Basis des genannten Controllers zu entwickeln, allerdings habe ich leider nicht viel Zeit dafür wegen Studium. Spätestens in einigen Wochen werde ich mich aber noch intensiver damit beschäftigen. Ich habe aber bereits schon mal eine funktionsfähige Testplatine für den Controller gebaut, wo ich alles Notwendige später noch anschließen kann wie z.B. den DAC, SD-SKarte, Display usw... Die Platine kann auch direkt am PC über USB programmiert werden (auch Stromversorgung über USB). Hier mal der Link zu meiner Testplatine: Beitrag "Adapterplatine AT89C51SND1C" Im Prinzip möchte ich alles erstmal so weit wie möglich auf einzelne kleine Platinen bringen, die ich dann miteinander z.B. über eine Art "Hauptplatine" verbinden kann. So kann ich einzelne Komponenten auch mal austauschen, wenn irgendwas nicht richtig läuft oder wenn ich z.B. einen anderen DAC einsetzen will. Wenn dann alles läuft wie es soll, würde ich natürlich gerne alles auf eine Platine packen, so dass es möglichst kompakt wird.
@Kai F: Naja, das mit dem 8051 war nur so 'ne Idee, weil ich davon noch massig rumliegen habe. Ich werde aber wohl trotzdem mit ziemlicher sicherheit einen 32 Bit MC nehmen. Das hässliche ist nur: Der VS1xxx läuft, wenn ich mich recht erinnere, mit 2.5V. Mein MC mit 3.3 oder 5V. Das Festplatteninterface mit 5V. Das ist etwas unschön.... Kann man die Festplatte (zumindes das Interface) irgendwie mit 3.3V betreiben?
@Tobias: Ich schreibe eigentlich nichts in Assembler sofern es nicht wirklich nötig ist. Source Code kann ich dir raussuchen. Ich würd dir von einem 8051 abraten. Immerhin willst ja auch ein Display haben. Wenn du eine HDD verwendest und du durch die Ordner "surfen" willst, kann ich dir nur zu einem Grafikdisplay raten, also wie du schon erwähnt hast. Die Ansteuerung des Displays braucht auch Rechenleistung die man nicht vernachlässigen sollte. Vor allem wenn du nicht nur Text darstellen willst... Du wirst dich später nur ärgern, wenn du nicht mit der Leistung auskommst. Der VSxxx braucht zwar mehrere Spannungen, aber das IO-Interface läuft auf 3.3V. Verwendest du also beispielsweise einen AT91SAM7 Controller kannst den MP3 Dekoder direkt dranhängen. Die Festplatte schließt über einen bidirektionalen Level-Converter dran. Du wirst in diesem Forum sicher fündig. Wenn du einen 5V Controller hast, dann machst die Ansteuerung wie in meinem Schaltplan gezeigt. Für 5V auf 3.3V nimmst du 74LVC Gatter, für 3.3V auf 5V nimmst du 74HCT Gatter (wichtig ist das T).
So, ich hab mir nochmal alles gründlich durchdacht. Ich denke wohl, dass ich das mit einem 32 bit uC lösen werde. Die Frage ist nur: mit welchem? ARMs gibts so unendlich viele, ich hab da überhaupt keinen durchblick, zumal ich die ARM-Familie nur oberflächlich kenne. An einen Coldfire dachte ich auch noch, da ich davon noch 2 Stück hier rumliegen habe. Der sollte auch vom Takt her ausreichend schnell sein, bis 66 MHz sind damit durchaus möglich. Tja, ich denke ARM wäre schon die richtige Wahl, nur was für einer? Kann mir jemand einen Tipp geben?
Beachte bei deinem Projekt, dass die Lebenserwartung einer HD im Auto nicht sonderlich hoch ist zwecks Erschütterungen und Temperatur.
ich weiss, aber eine Notebook-HD ist da sicher schon um einiges resistenter als eine Desktop-HD. Da mache ich mir keine Sorgen ;)
Ich würde dennoch SD-Karte oder SSD nehmen. Da kannst du drauf rumtrampeln und da passiert nichts. Wer hat schon mehr als 16GB Mp3s im Auto? Zudem kannst du die SD-Karten auch noch für deine Digicam oder so benutzen. Ich habe inzwischen so viele SD-Karten hier rumliegen, da wäre es blöde sie nicht zu nutzen.
Meine HD macht das seit gut 3 Jahren mit. Allerdings hat mein Player auch die Raffinesse, dass die Titel im DRAM gepuffert werden und die Platte nur zum nachladen anspringt. Könnte sein, dass dadurch die Lebensdauer etwas höher ausfällt. Gruß Matthias
Also wegen der HDD würd ich mir gar nicht allzu viele Gedanken machen. Klar, man darf nicht den größten Mist am Markt kaufen. Navigationsgeräte/Board Computer von BMW und Mercedes haben auch Laptop HDDs integriert. Ich weiß das, ich habe eines vor mir liegen... Wenn ich mich nicht täusche hat man darauf 5 Jahre Garantie, also würd ich mal behaupten wollen, dass dieser Punkt unbedenklich ist. Durch die "Aktivität" der HDD selbst, ist sie bereits enormen G-Kräften und Erschütterungen ausgeliefert. Wenns dann bei einem VU mit Totalschaden kaputt ist, wird Tobias sich sicherlich nicht um die HDD Sorgen machen. SD Karten sind zwar alle schön und nett, ich würde es auch zusätzlich vorsehen, aber ich nehme an Tobias will eine HDD weil dort einfach viel mehr Platz drauf ist. Das SD Karten günstig sind, braucht man nicht abstreiten. Hofer/Aldi hat gerade eine 4GB Karte für 14€. Wie auch immer... Ich würd dir einen AT91SAM7Sxxx vorschlagen, wobei ich nicht glaube, dass es bei diesem Projekt ein KO-Kriterium für für irgendeinen Hersteller gibt. Ich hatte bis jetzt nur gute Erfahrungen mit AT91, vor allem weil es für diesen Controller auch sehr viele Beispiele gibt, die sehr hilfreich sein können, wenn man noch nie etwas mit ARM gemacht hat. ATMEL hat vor kurzem auch eine sehr stromsparende Variante rausgebracht (AT91SAM7L), ist also auch überlegenswert. Ich persönlich würde einen Controller nehmen, der entweder genug "Haxn" hat um eine Festplatte ohne viel herumpuffern anzusteuern oder sogar ein externes Speicherinterface (z.B. AT91SAM7SE). Externes SDRAM dran und die HDD und fertig. Schlussendlich kommt es jedoch darauf an was du in Händen halten willst, wenn alles fertig ist. Hier stellt sich die Frage, ob du Ethernet, CAN, USB, RS232, WLAN etc. benötigst. Erst wenn du dir darüber im Klaren bist, solltest du dich fragen mit welchem Controller ist das am einfachsten und kostengünstigsten zu realisieren. Was du auf jeden Fall benötigen wirst, ist eine DMA/PDC um Daten in den Decoder zu schaufeln. Zumindest eine Schnittstelle mit der Außenwelt, um Daten auf die HDD zu laden ohne den Player aus dem Auto auszubauen. USB oder Ethernet sind da sicherlich ein feine Sache. Über FTP könntest deine Datein verwalten, bzw. als USB Device (Wechseldatenträger im Explorer) per Drag und Drop. Dir muss aber klar sein, dass ist sehr viel Arbeit. Ein IPOD ist auch nicht in 2 Tagen entwickelt worden. Ordentliche Hardware zu bauen ist nicht trivial. Ich weiß zwar nicht wie gut die neuen Decoder von VLSI sind, aber ältere Komponenten haben da recht grindige Geräusche von sich gegeben, wenn nicht ordentlich geroutet oder gefiltert wurde. Die Software ist wohl auch ein recht komplexer Teil. FAT32, Display, USB, FTP Server... nimmt sehr viel Zeit in Anspruch. Machst du das für dich privat oder denkst du den Player auch zu verkaufen? Auch wenn es da 1000 am Markt gibt, wenn du dir was besonderes einfallen lässt, kannst du ihn zumindest als Eval-Board verkaufen.
@Rooney: Hmm, an Verkauf habe ich bis jetzt gar nicht gedacht. Aber du hast natürlich Recht, es wäre eine feine Sache, wenn sich damit sogar noch was verdienen lassen würde. Noch was zum ARM: Ich dachte an einen ARM ohne externes Speicherinterface. Dafür mit vielen GPIOs. Die HD würde ich dan mit bit-banging ansteuern (ich weiss, undschön, aber wenn der ARM ausreichend schnell getaktet ist sollte das schon hinhauen), ebenso wie das Display. Bei der Schnittstelle dachte ich an Ethernet. Wenn ich den Laptop mit habe, oder wenn ein Freund einen dabei hat, dann kann man den dann an die Anlage anschliessen und paar Files rüberziehen. So könnte das Teil gleich noch als 'portabler' Speicher dienen ;) Gibts für ARM eine eine einigermassen günstige oder gar kostenlose Software (C-Compiler + Loader) ? ich kenn mich da, wie gesagt, noch nicht so aus.
Also wegen der Geschwindigkeit brauchst dir keine Sorgen machen, ich habe meinen MP3 Player mit einem PIC realisiert und der hat das auch geschafft... Ein externes Speicherinterface würde dir nur sehr viel Arbeit abnehmen. Aber wie gehabt, ich weiß nicht inwiefern eine HDD von dem EBC (external bus controller) unterstützt wird. Wenn der Großteil der Ansteuerung dann erst wieder per Software erledigt werden muss, macht es keinen Sinn. Wenn du Ethernet willst musst du jedoch bedenken, dass du einen FTP/Webserver am Controller laufen lassen must. Am besten wäre also einen Controller zu nehmen der Ethernet bereits unterstützt oder du verwendest einen Ethernet-to-Serial-Converter. Wobei das Zweitere zwar FTP unterstützt, aber nur für den internen Speicher des Converters selbst. Damit du aber via FTP auf deine HDD zugreifen kannst benötigt das einiges an Programmierkunst. Deswegen würd ich nur Controller nehmen, die Ethernet onboard haben. Hierfür gibt es sicherlich einige Beispiele im Netz. Wenn der Source Code zur Verfügung steht braucht man eigentlich nur den Treiber (HDD + FAT32) schreiben. Klar, es gibt kostenlose Compiler, aber ob die was taugen weiß ich nicht. Ich verwend in der Firma IAR Embedded Workbench und JLINK. Schon mal daran gedacht, mit mehreren Leuten an diesem Projekt zu arbeiten? Da ich bereits einiges an Erfahrung habe, weiß ich, dass du dein Projekt nur verkaufen kannst, wenn du nicht nur Hardware hast, sondern auch eine funktionierende Software (Programmbeispiele) und Dokumentation etc.
Hallo Rooney, ja du hast das allerdings mit einem PIC gemacht, der immherin mit 40 MHz läuft. Die HDD lässt sich eigentlich wie ein RAM ansprechen, es gibt RD und WR-Leitungen und das CS kann man ja aus Adressleitungen ableiten. Sollte also gehen. Hmm, Ethernetcontroller habe ich auch noch ein paar hier. Zur Not könnte man einen solchen verwenden ;) Aber du hast natürlich Recht, ein externes Speicherinterface nimmt einem einiges an Arbeit ab. Ich bin mir nur nicht ganz sicher, ob die HDD (bzw. der HDD-Controller) schnell genug ist, wenn er mit dem EBC verbunden ist. Auf der HDD würde ich ein eigenes kleines Dateisystem einsetzen. Dies aus 2 Gründen: 1. Ich hab mich mal in FAT einarbeiten wollen, aber war mir etwas zu aufwendig und ich hatte nicht so viel Zeit, deshalb habe ich das bleiben lassen. Der 2. Grund ist, dass die HDD ja nur in diesem Player lesbar sein muss und auch von diesem beschrieben wird. Also wäre FAT32 nicht unbedingt nötig. Oder? Die IAR Workbench werde ich mir anschauen. Ist die sehr teuer? Wie siehts mit JLINK aus? Ich gebe gerne Geld für so ein Entwicklungstool aus, aber nur wenn es wirklich gut ist und nicht allzu viel kostet. Deshalb meine Fragerei ;) Mit mehreren Leuten an dem Projekt zu arbeiten habe ich mir noch nicht überlegt. Wird aber sowieso schwieriger, da ich nicht allzu viele andere Hobbybastler kenne. Grüsse
einen 40MHz PIC mit einem 48MHz AT91SAM7S kann man nicht vergleichen... Der PIC ist was er ist, ein kleiner Controller, mehr nicht und nicht weniger. Schon allein die Tatsache, dass der AT91SAM7S eine DMA/PDC besitzt macht ihn um vieles schneller. Ob ein Interface des EBC mit einer HDD möglich ist muss man einfach mal versuchen. Du kannst sehr viel beim EBC konfigurieren, auch Zugriffszeiten. Da wäre es wahrscheinlich ratsam wenn man direkt bei ATMEL anfragt. Die haben dort fähige Mitarbeiter sitzen und ich nehme mal an, dass vor dir sicher schon mal wer so etwas machen wollte. Auch wenn FAT32 nicht unbedingt einfach ist, aber niemand erwartet, dass man alles neu programmiert. Ich persönlich würde trotzdem zu einem Standartformat greifen, das funktioniert dann zumindest auf jeden Fall. Für IAR Embedded Wochbench gibt es eine Kickstart Version, die ist so viel ich weiß kostenlos hat aber eine 32k Beschränkung. Wird sich also nicht ganz ausgehen. Die Vollversion wird wohl irgendetwas zwischen 1000 und 2000 Dollar kosten. Ich kann dir Bescheid geben wie viel es ausmacht, wenn ich eine Antwort von IAR bekomme. Habe mich wegen dem Betriebssystem erkundigt. Angebot ist jedoch noch ausständig. Der Segger JLINK kostet für nicht kommerziellen Gebrauch 100€ und funktioniert nicht nur mit IAR sondern auch Yagarto (kostenlos). Kann ich nur empfehlen!!! Hobbybastler findest du hier im Forum genug. Man könnte ja ein Gemeinschaftsprojekt organisieren. Einer macht die Hardware und die Software wird in kleinere Aufgabenpakete geteilt. Dazu muss man sich nicht mal sehen, der Großteil würde per Email bzw. Postweg gehen. Lass es mich wissen, wenn du Interesse daran hast.
So Rooney, ich hab mich mal auf der NXP-Website informiert über die verschiedenen ARMs. Denkst du, der LPC2212 oder LPC2214 könnte geeignet sein? Der hat externes Interface, 128k Flash, SPI, und 2 UARTs. Also alles was ich brauche. Einen ARM mit intergriertem Ethernet würde ich lieber nicht verwenden, da dieser ja dann sowieso extern noch einen PHY brauch. Da kann ich gleich den kompletten Ethernet-Controller extern machen. Das wäre dann in meinem Fall ein CP2200, da der ein schönes, paralleles 8 bit Interface hat. Festplatte kann man ans EBC anschliessen meine ich. Die Pins sind auch 5V-Tolerant. Auf USB verzichte ich gerne. Also sollte der LPC2212 geeignet sein oder? mehr als 128k FLASH brauch man wohl kaum meine ich mal. Der IAR ist mir mit 1000 zu teuer. Das hole ich mit basteln nie raus, und genau dafür will ich den ja. Da werde ich mir lieber Yagarto mal ansehen ;) Der Segger JLINK erscheint mir allerdings wirklich günstig, ich denke so ein Teil werde ich mir kaufen. Hmm, ob ich das als Gemeinschaftsprojekt realisieren will? Ich weiss nicht, für die meisten im Forum ist das wohl ein alter Hut, so ein MP3-Player. Ausserdem mache ich die Hardware gerne selber, aber softwareseitig bin ich nicht so der Held, da würde ich gerne auf etwas Hilfe zurückgreifen ;)
Mit NXP kenn ich mich nicht so aus, ich verwende eigentlich nur ATMEL Controller mit ARM7 und ARM9. Ein AT91SAM7SE256 hätte auch ein externes Speicherinterface. Der interne Ethernet Controller hat den Vorteil, dass du dich nicht um das Datenschaufeln kümmern musst, dafür hast du ja eine DMA/PDC. Aber ich sage mal, dass ist Geschmackssache. 5V Tolerant ist wohl ein Pluspunkt der für LPC spricht. Wenn die Festplatte dann auch noch TTL kompatible Eingänge hat, dann kannst du dir alle Levelconverter ersparen. Das IAR nicht billig ist liegt einfach daran, dass es einen sehr guten Debugger integriert hat. Irgendwann mal wenn ich Zeit habe, möchte ich mir jedoch auch Yagarto/Eclipse reinziehen. Mein JLINK würde ich jedoch nie wieder tauschen :-) Wennst genug Geld hast, kannst dir die RDI kaufen, damit du auch im Flash mehr als einen Breakpoint setzen kannst oder um Flash schneller beschreiben zu können. Diese Lizenzen sind jedoch auch nicht geschenkt. Mit den 100€ ist eben nur "normale" Debuggen drin, wobei auch die möglichkeit besteht über TCP zu debuggen. Ich habs zwar noch nicht ausprobiert, aber soll für manch einen auch relevant sein.
Also ich persönlich würde dir von den LPC22xx abraten. Diese Serie ist schon relativ alt, besitzen recht wenig und langsame Peripherie und sie besitzen auch nur 16kByte RAM. Schau dir doch mal die LPC2378/LPC2388 an. Diese bieten wesentlich mehr und schnellere Peripherie und 58 bzw. 98kByte RAM sowie 512kByte Flash. Preislich sind sie auch wesentlich interessanter. (Conrad: LPC2214 für 17,59 und LPC2378 für 13,77 -> zugegeben sehr teuer, aber das Verhältnis stimmt). Nachteil der beiden LPC23x8 ist das externe Businterface, welches hier nur 8Bit Daten- und 16Bit Adressbreite bietet. Ein integriertet Ethernet-MAC hat übrigens gewaltige Vorteile! Zum einen sind wesentlich weniger Leitungen zu routen und zum anderen sind die PHY-Bausteine recht günstig. Bei den LPCs verfügt der integrierte MAC über DMA und 16kByte RAM. Die Belastung, die ein externer Ethernetcontroller auf den Daten-/Adressbus bringt ist nicht zu unterschätzen. Solltest du einen vollen (32Bit) Datenbus brauchen/wollen, so wäre der LPC2468 was für dich. Ist nahezu identisch mit dem LPC2388, nur das dieser einen richtigen Daten-/Adressbus und außerdem noch einen SDRAM-Controller besitzt.
Hallo, mal so ein Vorschlag nebenbei. Wie wäre es wenn du deinen MP3-Player als USB-Host entwickelst. Dann kannst du USB-Sticks verwenden. Bist flexibel, was die Lieder angeht und mit 4-8 GB sollten genug MP3 Lieder drauf passen. Gruß Udo
Oder man nimmt einfach nen AVR32 (z.B. das ATNGW100). Da ist SD-Interface Hardwaremäßig implementiert. Und genug Leistung zur mp3-Decodierung hat er auch. Und mit dem AC97 Controller sollte die Soundausgabe auch kein Problem darstellen, oder sehe ich das falsch?
@Rooney Bob: Ich glaube, die Festplatte hat sogar TTL-Pegel. Das wäre natürlich genial, wenn ich um den Pegelkonverter herum käme. Der gefällt mir einfach nicht, wie ich zugeben muss. Du sagtest ja früher, ich soll es dich wissen lassen, wenn ich an einem Gemeinschaftsprojekt Interesse habe. Nun, kann ich auch sonst später mal auf dich zurück kommen? Du scheinst ja ziemlich versiert in der Sache zu sein. Ich denke, das Projekt hält wohl doch noch den einen oder anderen Stolperstein für mich bereit ;) @Kai: Okay, überzeugt! Der integrierte Ethernetcontroller hat doch mehr Vorteile als ein separater. Unschön finde ich es aber wirklich, dass er noch einen externen PHY braucht. Welche Chips verwendest du zu diesem Zweck? Ich kenn' da keinen einzigen, wie ich gestehen muss. Datenbus muss wohl oder übel 16 Bit breit sein, da die HDD auch ein 16 Bit breites Interface hat. Und ich möchte sie ja am externen Bus anschliessen. @Udo: Naja, wenn der Player über USB funktioniert, muss ich ja ständig einen Stick mit haben und den dort anschliessen. Wäre zwar nicht schlecht, aber eine HDD bietet doch einige Vorteile, wie ich meine. @Timmo: Du siehst es nicht falsch; im Gegenteil, der AVR32 hätte sicher ausreichend Rechenpower. Allerdings bin ich mit den AVR-Prozessoren noch weniger vertraut als mit ARMs, und es gibt auch noch einige andere Gründe, warum ich lieber keinen AVR einsetzen würde.
PHYs gibt's genug, die man da einsetzten kann. häufig genutze Beispiele: -Micrel: KS8721/KSZ8721 -Micrel: KS8001L/KSZ8001L -National: DP83846 Ich persönlich route gerade ein Layout mit LPC2468, KSZ8001L (PHY) und vielen anderen Spielereien. Wird allerdings eine 4-lagige, knapp Eurokarten große Platine.
Zum Thema Workbench, wer mit 32KByte auskommt, dem würde ich immer zur IAR Kickstart Version raten, das ist kein Vergleich mit Yagarto/Eclipse. Wer aber mehr Code hat, für den ist Yagarto eine gute Alternative, obwohl es auf Eclipse beruht (und ich kein so riesen Fan davon bin) muss ich im Endeffekt zugeben, wenn man sich dran gewöhnt hat, kann man damit arbeiten und es ist halt komplett kostenlos. Wer also mit Yagarto und J-Link anfangen will, dem kann ich nur empfehlen sich einfach ne embOS Trial Version von www.segger.com runterzuladen. Nein, ich will keinem nen RTOS andrehen, aber dann hat man einfach was, mit dem man einen fertigen Workspace hat, mit dem man erstmal rumspielen kann, um zu sehen, ob alle Tools so funktionieren, wie man sich das vorstellt. Gruß, Til
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.