Ich hab auch mal ein wenig zum Thema SH7264 recherchiert. * er hat eine SH-2A_Architektur, die nicht unmittelbar durch das GCC-Team supportet wird. Der GCC auf der Renasis-Seite scheint ein eigener Fork von Rernasis zu sein. GCC unterstützt SH-3 und SH-4. *GDB-Unterstützung dann wohl eher auch nicht. D.h.: man ist bei der Entwicklungsumgebung (heute) auf Gedei und Verderb an Renasis gebunden.....ob das so schlau ist? * für mich ist bisher auch völlig ungeklärt, wie ich meine Software in das Board bekomm, solange ich nicht das (teure) Development-Kit von Renasis, oder den beschriebenen USB-Adapter aus dem japanischen Elektronik-Magazin (Beschaffung völig ungeklärt) besitze. Selbstbau-Projekte mit diesem Chip finden sich im Netz scheinbar (noch) nicht. Von nachbaubaren "ISP-Adaptern" ganz zu schweigen. Zudem scheint Renasis da auch eine recht restriktive Lizensierungsstrategie zu fahren, wenn ich z.B. lese, daß ich für die Nutzung der Hardwaredebug-Funktion eine extra (kostenpflichtige) Lizens benötige... Also irgendwie hab ich bei dem Ding im Moment kein so gutes Gefühl, auch, wenn die Features wirklich verlockend sind. Harry
Auch wenn er auf den 1. Blick vielversprechend aussieht, warum solch einen exotischen Prozessor verwenden? Nach den Problemen mit verschiedensten Renesasprozessoren, die ich in der Firma immer wieder sehen muß, käme für mich solch ein Prozessor nie in Frage, auch wenn man die Entwicklungskits zur Zeit regelrecht hinterhergeworfen bekommt. Zeitgemäß und relativ zukunftssicher sehe ich Prozessoren mit Arm-Kern. Hier sind die Toolchains komplett frei und gut erprobt. Es gibt genügend Hilfestellung im Netz und viele Leute, die sich damit auskennen.
Ich halte das auch für mutig auf so einen Exoten zu setzen. Der mag für kommerzielle Autoradios ganz nett sein, aber für Open Source Projekte gelten andere Anforderungen. Gibt es z.B. überhaupt einen Open-Source-MP3- und AAC-Decoder für den Prozessor?
Jan X. schrieb: > Auch wenn er auf den 1. Blick vielversprechend aussieht, warum solch > einen exotischen Prozessor verwenden? Nach den Problemen mit > verschiedensten Renesasprozessoren, die ich in der Firma immer wieder > sehen muß, käme für mich solch ein Prozessor nie in Frage, auch wenn man > die Entwicklungskits zur Zeit regelrecht hinterhergeworfen bekommt. > Zeitgemäß und relativ zukunftssicher sehe ich Prozessoren mit Arm-Kern. > Hier sind die Toolchains komplett frei und gut erprobt. Es gibt genügend > Hilfestellung im Netz und viele Leute, die sich damit auskennen. 100% ACK 32bit Atmel erscheint mir auch ganz OK Harry
es gibt einen E10A-USB Lite On-Chip Debug Emulator, ua von MSC, der sollte günstiger sein. SH2-A ist min. genau so sicher wie ARM, wenn nicht sicherer. Es gibt von dieser Schiene (von Renes) extrem viele Controller, weit mehr als ARM von einer einzelnen Firma (von verscheidenen Firmen, sind ja ARM.Controller auch nicht kompatiberl, nur die CPU) >Soweit ich das aber nach nur lesen sagen kann ist es weniger komplex als >eine R32 oder M16. Stimmt so nicht. SH2(-A) ist RISC mir nur 16bit OPcode-satz (desw auch rel wenig Adr-möglichkeiten, (bzw Table im code nötig)), braucht also oft viele Befehle wo nen CISC nur 1 braucht. Die MIPS-Angaben sind da nicht sehr wirklichkeitsnah! SH2-A ist eine Erweiterung von SH2, um einige Befehle, insbes Erweit. mit 15 Registerbänken. Aber SH2(-A) hat DelayedBranches, also etwas knifflig zu progr.! SH..CPUs gibts seit ca 1993. Der Kern ist also auch nicht der Neuste und ist immer 'aufgestockt' worden. Renesas favorisiert die im Hochleistungsbereich, bzw auch im Bereich mit sehr viel Periferie. RX's (gibts mit sehr viel Flash, auch sehr schnell, zukünft. bis max 200MHz ) sind dagegen ganz neu und sind von der Leistung her auch i.e. mit SH2's vergleichbar, und sind besser zu programmieren. Viele Periferie-teile von neueren Renes-Derivate der verschiedenen CPU-Familien überschneiden sich bzw werden sich in Zukunft immer mehr überschneiden (da Ren. das Rad auch nicht immer neu erfinden will) DTC (von Ren.) ist auch eine nette Perif-einheit (die in den meisten neueren Deriv eingebaut ist), fast so schnell wie DMA, aber mit wesentlich mehr Kanälen. Die meisten anderen Chip-Hersteller haben nichts vergleichbares zum DTC. --- Vielleicht so'n RX nehmen --ist General Purpose, sehr schnell, hat integr. schnelles Flash -- und ggfs I2S-Teile usw einfach über PLD/FPGA anbinden (dann wär man da noch flexibler als mit nem o.g. SH2-A)
Ehrlich gesagt, ich fühle mich mit dem Renesas auch nicht so ganz wohl, aus den Gründen die die Vorposter schon erwähnt hatten... Die Features von ihm klingen allerdings schon nicht schlecht, gerade die speziellen Audiosachen. Wobei es mir persönlich gar nicht so wichtig wäre die Audiosignale digital verarbeiten zu können, soweit ich bisher über den Tuner gelesen habe denke ich könnte ich mit dessen (analogen) Möglichkeiten auskommen. Da aber für manche die Prioritäten ja anders liegen, möchte ich die Euphorie für den Renesas hier nicht bremsen ;-) Somit ein Vorschlag: wie wäre es den Analogteil (Tuner/Verstärker, evtl auch die ADC/DACs) und den Renesas jeweils auf einer eigenen Platine unterzubringen? zumal ja anscheinend ein Evalboard für den Renesas geplant ist - möglicherweise könnte dieses dann damit auch gleich für das Radio weiterverwendet werden? Auf die Tunerplatine dann nur einen kleinen Controller setzen, der z.B. die RDS-Dekodierung, Abfragen von Tasten/Drehgebern etc. übernimmt. Das hätte auch den Vorteil, diese (zeitkritischen) Steuerungsaufgaben von dem Controller der die Signalverarbeitung macht abzukoppeln (Olaf hatte ja auch bereits angesprochen, dass das eine Herausforderung werden könnte). Somit könnten am Tuner alle gemeinsam arbeiten und trotzdem jeder den Controller seiner Wahl verwenden. Was meint ihr dazu? Einwände? Gruß Mathias
So, meine Entscheidung steht fest: Ich votiere aus o.g. Gründen eindeutig GEGEN die Renesas CPUs Harry
> Der Renesas protzt zwar mit seinem großen RAM, aber er lädt > das Programm aus einem SerialFlash... D.h. effektiv steht > einem nicht mehr RAM zur Verfügung als bei einem beliebigen > anderen CortexM3 oder AVR32 mit internem 512kB Flash und > 64..128k internem RAM. Ich weissen nicht ob 'protzen' das richtige Wort ist. Ich koennte mir vorstellen das RAM an dieser Stelle einfach eine Notwendigkeit war um die notwendige Geschwindigkeit zu erreichen. Ansonsten hast du natuerlich recht wenn du wirklich planst ein Programm zu schreiben das 512kByte gross ist. Allerdings hindert dich beim RAM keiner eine beliebige Funktionalitaet nachzuladen. Soll heissen eine der Funktionen die ich spaeter beim Bootmanager integrieren wollte, war das er einem die Moeglichkeit gibt die Firmware auch von der SD-Karte zu laden. > Jungs hat wer von euch erfahrung mit LineIn und Out. Besonders > welche beschaltung man zwischen CODEC und verstärker braucht usw ? Du brauchst einen Tiefpass gegen die Samplefrequenz. Idealerweise vielleicht nur eine RC Kombination wenn Oversampling. Ausserdem einen OP am Ausgang als Puffer und einen am Eingang um das Signal DC-maessig auf das anhebt was der Wandler unter 0 versteht. Ich denke mal der Hersteller deines Codecs koennte dazu eine Applikation haben? > BTW: Denkst Du, das es evtl. möglich ist einen anderen jTag > debugger zu benutzen? J-Link, FTDI basierte designs oder > standard RDI debugger nehmen? Bzw. kannst Du mal in den > Einstellungen der Entwicklungsumgebung schauen? Hm...ich selber habe bisher noch niemals JTAG benutzt. Ich denke aber das die verwendung eines beliebigen Debuggers kein Problem sein sollte wenn man einfach nur uebersetzten Code in das Flashrom schreiben moechte. Der Compiler kann sicherlich Motorola-S, Hex und Bin erzeugen. Ich weiss aber nicht ob und wie ein fremdes JTAG-Interface mit dem Debugger zusammenarbeiten kann so das der halt vollen Zugriff hat. Ich koennte mir vorstellen das dies nicht ohne ernste Programmierarbeit auf PC-Seite abgeht! > Ich dachte eher an jeder Seite doppelreihige Steckerleisten zu machen. Hm..gut, das koennte auch gehen. Ich denke da auch nochmal drueber nach. Aber erstmal will wenigstens mal I2C laufen habe damit ich einen ersten Erfolg sehe. :-) > Dann wird es klein und kompakt und ist trotzdem noch auf > Lochrasterplatinen benutzbar. Das wuerde ich auch fuer wichtig halten damit man es wenigstens auf so ein Standard 100x160 Board stecken kann. BTW: Die Verteilung der Signale auf dem japanischen Board ist etwas hm... chaotisch. > Übrigens find ich das decoupling schon recht ungewöhnlich, bzw. > SEHR auf Sicherheit gebaut. 10µ, 100n, 10n und 1n in Reihe? So genau habe ich mir den Schaltplan noch garnicht angeschaut. Wuerde ich fuer etwas sehr uebertrieben halten. Ein 100n in als kleiner 0603 oder 0402 sollte doch wohl reichen. > Was für Typen sind das? X7R/NP0/? Gibts zufällig ne BOM wo > das drinsteht? http://www.criseis.ruhr.de/SuperH/bom.jpg Den Text spare ich mir jetzt mal. :-) > Der GCC auf der Renasis-Seite scheint ein eigener Fork von > Rernasis zu sein. Dazu kann ich nichts sagen, ich habe mir nur mal alles runtergeladen was die Japaner selber angeboten haben: [root] /mnt/E/Daten/Etechnik/SuperH/sh7262/Dokus/gcc: l insgesamt 31M 348K 2010-05-24 14:29 asp_cq_frksh2a_gcc-20100409.tar.gz* 929K 2010-05-24 15:20 cq_gnu_resources20100424.tar.gz* 217K 2010-05-24 15:19 cq_sh7262_gcc.zip* 28M 2010-05-24 14:28 gnu_sh-hitachi-elf_cygwin-2.95.3-1.tar.gz* 1,5M 2010-05-24 14:30 jsp-1.4.3_cq_frksh2a-20100409.tar.gz* 40K 2010-05-24 14:30 jsp-config-cq_frksh2a-20100409.tar.gz* Selber habe ich momentan noch keinen Grund mich damit zu beschaeftigen. > * für mich ist bisher auch völlig ungeklärt, wie ich meine Software in > das Board bekomm, solange ich nicht das (teure) Development-Kit von > Renasis, oder den beschriebenen USB-Adapter aus dem japanischen > Elektronik-Magazin (Beschaffung völig ungeklärt) besitze. Wie du das unter Linux schaffen willst weiss ich auch nicht. Selbst ist der Mann :-) Unter Windows sieht es so aus.... Man muss einmalig ein SPI-Flash mit einer Bootfirmware haben. Auf dem japanischen Board ist dieses Flash ein M25P05 von Numonix. Renesas selber gibt in seinen Applikationen aber ein Datenflash von Atmel an. Das muss man selber brennen koennen, SPI halt, oder jemand anders (ich z.B) brennt es einem in einem Brenner. Oder sonstwie. Ich meine das beschreiben eines SPI-Flash sollte ja keine grosse Sache sein. In dieses Flash kommt ein 8kb grosser Bootloader von Renesas. Den gibt es im uebrigen auch im Source! Ausserdem kommt da ein 24kb grosses Programm rein das mit dem Debugger von Renesas reden kann. Letzeres vermutlich auch im Source, habe ich aber noch nicht verifiziert. (8kb+24kb=32kb) Der Bootloader in der augenblicklichen Form (wie gesagt Source, kann beliebig umgeschrieben werden) laedt entweder das Debuggerprogramm oder aber aber die anderen 32kb des Flashrom und startet die. Dieses 32kb in dem 64kb Flash sind fuer den User vorgesehen. Wobei natuerlich 64kb etwas mickrig sind. Das wollte ich in naher zukunft auch durch was anderes ersetzen. Aber erstmal egal. Sobald eine funktionierende Anbindung an eine SD-Karte vorhanden ist wollte ich den Bootloader auf jedenfall dazu bringen das er auch etwas von SD-Karte startet! Wenn der Debugger das Monitorprogramm (24kb) startet dann meldet sich das Board ueber USB als virtueller COM-Port an dem PC an. Danach kann die Entwicklungsumgebung von Renesas mit dem Board reden. Es ist dann z.B moeglich Programme zu schreiben die im Ram laufen und vom HEW (Der Oberflaeche von Renesas) da reingeladen werden. Ausserdem gibt es noch einen Flashwriter (Renesas, Source verfuegbar) der ist in der Lage beliebige Sachen in das Boot-SPI-Flash zu schreiben. So kann man ein fertiges Programm dauerhaft in die Hardware bekommen, aber auch den Bootloader selber updaten. Nur wenn man sich selber den Bootloader kaputflasht und den Controller ausschaltet wird er danach nicht mehr starten und man muss erstmal das SPI-Flash extern herstellen! Wer das ganze im Detail nachlesen will die Applikation heisst: rej06b0867_sh7262_sh7264ap.pdf Und sollte hier zu bekommen sein: http://america.renesas.com/support/downloads/download_results/C2016701-C2016800/an_rej06b0867_sh_sboot.jsp > Zudem scheint Renasis da auch eine recht restriktive > Lizensierungsstrategie zu fahren, wenn ich z.B. lese, daß ich für die > Nutzung der Hardwaredebug-Funktion eine extra (kostenpflichtige) Lizens > benötige... Gib mal eine Quelle. Ich sehe im Moment nicht fuer was ich eine Lizenz benoetige und was ich nicht kann. Was ich sehe das ich vollkommen kostenlos eine sehr leistungsfaehige Oberflaeche verwenden kann die alles kann was man sich wuenschen kann. > Auch wenn er auf den 1. Blick vielversprechend aussieht, warum solch > einen exotischen Prozessor verwenden? Nach den Problemen mit > verschiedensten Renesasprozessoren, die ich in der Firma immer wieder > sehen muß, käme für mich solch ein Prozessor nie in Frage, auch wenn man > die Entwicklungskits zur Zeit regelrecht hinterhergeworfen bekommt. Ich setze Renesas auch seit Jahren ein und habe bis auf ein kleines Problem mit I2C an einem Port eines R32C116 noch kein unloesbares Problem gehabt. Anderer Probleme waren bis jetzt immer loesbar, das auch oft unter freundlicher Hilfe vom Distributor. > Ich halte das auch für mutig auf so einen Exoten zu setzen. Den Prozessor selber halte ich nicht fuer Exotisch. Ist halt ein SuperH. Dieser spezielle Typ ist sicher exotisch weil er halt fuer Audiokram optimiert ist. Aber dafuer bekommt man halt eben auch die ganzen Spezialfunktionen. > Der mag für kommerzielle Autoradios ganz nett sein, aber > für Open Source Projekte gelten andere Anforderungen. Welche? > Gibt es z.B. überhaupt einen > Open-Source-MP3- und AAC-Decoder für den Prozessor? Ich kenne mich mit MP3 nicht so aus, aber ich meine ich haette einen Link dazu gepostet. > Aber SH2(-A) hat DelayedBranches, also etwas knifflig zu progr.! Ist das nicht piepegal? Bei so einem Prozessor wird doch niemand mehr als 10-20Assemblerinstruction hintereinander schreiben. Um den Rest soll sich bitte der Compiler kuemmern. > Vielleicht so'n RX nehmen --ist General Purpose, sehr schnell, hat Waer mir noch zu neu. Olaf
> Ich votiere aus o.g. Gründen eindeutig GEGEN die Renesas CPUs
Sehe ich das richtig das du vor allem deprimiert bist weil du nicht so
einfach alles unter Linux machen kannst?
Nun setze ich ja auch zu 95% Linux ein, aber das ist fuer dieses Project
vollkommen irrelevant weil die Idee darin besteht mit anderen Leuten
ZUSAMMENZUARBEITEN und du willst doch jetzt nicht allen vorschreiben auf
Linux umzusteigen nur damit es genauso wie bei dir laeuft oder?
Olaf
Ich verfolge diesen Thread schon eine Weile und bin verblüfft wie hier im Handstreich eigene Meinungen durchgesetzt werden. Der Renesas mag technisch toll sein, aber das er hierzulande kein Exot ist halte ich für eine ziemlich isolierte Meinung. Sicher gibt es Leute die damit arbeiten, aber verglichen mit ARM ist die Verfügbarkeit von Tools jeder Art recht bescheiden. Wer das nicht hören will darf sich dieser Richtung gerne zuwenden, sollte aber akzeptieren das andere diese Meinung nicht teilen und diese Leute dann nicht als verbohrt hinstellen. Offenheit funktioniert immer in beide Richtungen.
Ok es gibt freie Compiler für die SuperH von Renesas. So lange es einen Kostenfreien Compiler gibt, gibt es von mir grünes Licht!
Jens schrieb: > Ich verfolge diesen Thread schon eine Weile und bin verblüfft > wie hier im Handstreich eigene Meinungen durchgesetzt werden. An dem System ist noch fast nichts wirklich 100% fest. Das einzige was in meinen Augen echt fest ist (oder?) ist die Art und Weise wie man mit den vielfältigen Interessen umgeht: Ich denke wir haben einen guten Kompromiss zwischen den beiden Lagern gefunden und der Vorschlag kam nicht von mir alleine. Ein reines aber gutes Autoradio (konservativerer und übersichtlicherer Ansatz) und einen multimedia CarPC (modernerer Ansatz) lässt sich sonst nicht so wirklich unter einen Hut bringen. Die einen wollen Touchscreen, Kopfstützenmonitore, etc., die anderen wollen sowas auf gar keinen Fall, andere wollen sich wieder die option offen halten. Den Multimediaansatz find ich nicht uninteressant (z.B. Wlan sync), aber ich würde primär erstmal gerne ein verdammt gutes und stabiles Autoradio bauen. Mit einer API kann man dann vom PC aus (für die Entwicklung) oder auch mit einem "Linux Modul" das Radio fernsteuern. Für die Linuxer ist das doch bestimmt auch einfacher. Sie müssen nicht viel im Kernel mode basteln sondern können das Radio komplett von user mode aus über UART (als Beispiel) fernbedienen. Und sie müssen sich nicht mehr mit den Problemen der Radiowelt auseinandersetzen sondern können es einfach als Blackbox ansteuern. Bzw. bei Nutzung einer Uart schön auf dem PC entwickeln und testen. Weiterhin haben wir schon ganz am Anfang gesagt das man abstimmt, aber niemand hat sich getraut ein paar Striche ins Wiki [1] zu tippen. Wenn man keine demokratische Rückmeldung bekommt und weiter kommen will muss man an einem gewissen Punkt einfach entscheiden. [1] http://osar.it-livetalk.de
Mathias A. schrieb: > Auf die Tunerplatine dann nur einen kleinen Controller setzen, der z.B. > die RDS-Dekodierung, Abfragen von Tasten/Drehgebern etc. übernimmt. Das > hätte auch den Vorteil, diese (zeitkritischen) Steuerungsaufgaben von > dem Controller der die Signalverarbeitung macht abzukoppeln (Olaf hatte > ja auch bereits angesprochen, dass das eine Herausforderung werden > könnte). RDS braucht -wenn man es gut machen will- relativ viel Speicher. Das Basisfeature follow me (beste Frequenz finden) an sich ist schon echt nicht ohne und nicht schnell nebenbei am Schreibtisch designed. Ein AtMega dürfte da aufgrund des geringen RAMs überfordert sein. Wenn man Frequency diversity zur Empfangsverbesserung einsetzen will braucht man sogar noch deutlich mehr Ressourcen.
@Kai Der SuperH ist eine der besten Lösungen wenn man mal von diversen ARMs im BGA absieht. Außerdem der Olaf spielt schon mit dennen. Ich würd ned immer alles über UART machen wollen es gibt ja auch noch SPDIF usw. Echtzeit schließt nicht unbedingt Linux oder so aus !
Patrick Weinberger schrieb: > @Kai > Der SuperH ist eine der besten Lösungen wenn man mal von diversen ARMs > im BGA absieht. Außerdem der Olaf spielt schon mit dennen. Ja, ich bin auch immer noch für den/die SuperHs. Ich nutz zwar Linux, aber programmieren tu ich meist unter Windows, insofern würde mich der fehlende GCC nicht stören. Zumal der Support für diese Architektur mit Sicherheit auch noch irgendwann mal kommen wird! Wenn Arm und BGA wär ich eindeutig für den LPC2888 von NXP. Aber leider nichtmal nur ein BGA, sondern sogar ein FBGA... > Ich würd ned immer alles über UART machen wollen es gibt ja auch noch > SPDIF usw. Klar, Line in-out (digital oder analog) sollte extra laufen. Wenn man auf die SD Karte vom Mainboard zugreifen wollte müsste man evtl. auch noch über eine weitere Schnittstelle nachdenken, wobei die Linux-Leute wahrscheinlich besser einen eigenen Massenspeicher nutzen. > Echtzeit schließt nicht unbedingt Linux oder so aus ! Ja, ich weiß!
Bezüglich Prozessor: Ich brauche kein Linux. Es wäre aber schön, wenn ich trotzdem die Möglichkeit habe, dieses einzusetzen. Worauf es mir aber ankommt: - Für einen Hobbyelektroniker mit beschränktem Werkzeugpool noch lötbar; kein BGA und QFN - Finepitch ist aber kein Problem (sollte halt herausragende Pins haben, die man mit dem Lötkolben erfassen kann). - Frei verfügbare Entwicklungsumgebung (gcc mit Bibliotheken; idealerweise gdb). - Kostenloses oder kostengünstiges Programmiertool. - Keine Einschränkungen in der Codegröße - ich möchte auch den kompletten Prozessor nutzen können und nicht dafür viele Euros aus der Hand geben müssen. - Kein NDA um an die Datenblätter zu kommen. - Verfügbarkeit auch für Hobbyelektroniker ohne Firma. Optional: - Gerne auch kostenlosen oder kostengünstigen Debugger. Wenn der Renesas das abdeckt, bin ich immer noch dabei.
Christian H. schrieb: > - Frei verfügbare Entwicklungsumgebung (gcc mit Bibliotheken; > idealerweise gdb). Heißt frei denn das es der GCC sein muss?
Es gibt den KPIT GNU compiler und sourcerey G++ Lite. Beide sind freie compiler aber man hat keinen Support. Zum Debugger: Der Olaf hat einen Debugger, mit dem kann man sich sicher zusammen reden. MFG
>Der Renesas mag technisch toll sein, aber das er hierzulande >kein Exot ist halte ich für eine ziemlich isolierte Meinung. Falsch. Renesas spielt weltweit in den obersten Rängen der Mikrocontroller-Firmen. Man könnte höchstens spez. Derivate von Ren. als Exot bezeichnen (vielleicht weil schlecht kaufbar o.ä.), aber nicht deren ganze CPU-Familien.
MCUA schrieb: >>Der Renesas mag technisch toll sein, aber das er hierzulande >>kein Exot ist halte ich für eine ziemlich isolierte Meinung. > Falsch. > Renesas spielt weltweit in den obersten Rängen der > Mikrocontroller-Firmen. > Man könnte höchstens spez. Derivate von Ren. als Exot bezeichnen > (vielleicht weil schlecht kaufbar o.ä.), aber nicht deren ganze > CPU-Familien. Man muss sagen das für den AVR, PIC oder vielleicht noch ARM User ein gewahltiger Sprung ist wenn man auf zB die SuperH Serie umsteigt. Wer von euch benutzt Blackfins ? Ich glaub niemand weil einfach das Gehäuse nichts mehr für Hobbiesten ist. lg Patrick
Olaf Kaluza schrieb: >> Ich votiere aus o.g. Gründen eindeutig GEGEN die Renesas CPUs > > Sehe ich das richtig das du vor allem deprimiert bist weil du nicht so > einfach alles unter Linux machen kannst? > Siehst du Falsch! Mir ist das Ding zu exotisch! *kein offizieller GCC...etc *die Software auf der Renases-Seite scheint mir keinesfalls kostenlos. Alles dort ist als Trial-Version gekennzeichnet - also irgenwie kastriert. Sorry!....offen ist anders. ...und natürlich ist mir der Gedanke mit dem Bootloader auch bereits gekommen. sag mal Olaf!....arbeitest du bei Renases in der Marketing-Abteilung? Harry
Bei Blackfin gibt es rel wenig Derivate, den kann man nicht mit anderen gut verbreiteten Controllern vergleichen. Blackfin würde ich, wenn überhaupt, nur für DSP-Spezialaufgaben nehmen, nicht als Haupt-Prozessor. Ich denke, von kleinen 8 bittern auf (die meisten) 32 bitter ist der Sprung weitaus grösser, als ein Sprung innerhalb 32 bitter. Aber ich würde nicht einzelne Periferiteile (wie beim hier diskut. SH2-A) als ausschlaggebenden Grund für CPU Wahl nehmen, ich würde eher eine CPU wählen, die vieleicht auch GeneralPurpose'd besser aufgestellt ist, (wäre dann universeller), denn so hohe Stückzahlen werden's ja (wahrscheinlich) nicht. Da würd ich mir den RX noch ansehen .
Wenn es nach mir ging würd ich am Liebsten einen ARM Cortex A5 verwenden, leider ist der noch nirgends zu bekommen. So ein OMAP L138 wär auch schön aber BGA gehäuse ....
Wozu überhaupt so eine "fette CPU" auf dem Mainboard? Haben wir uns von dem modularitäts-Gedanken jetzt wieder verabschiedet? Nur wegen der I²S-Ports?....Das wird ja wohl auch anders gehen. Und nochmal: der Renases ist alles andere als offen, solange Renases selbst der einzige Lieferant von Software ist. Selbstbauprojekte mit den Dingern findet man im Netz auch so gut wie nicht. Wir wären also echte Pioniere, und auf uns selbst gestellt. Zum Experimentieren ist sowas ja ganz nett, aber, wir wollen ja irgendwann auch mal ein benutzbares Radio haben. Auf der anderen Seite gibt es für ARM oder AVR32 jede Menge Code, und entsprechend viele Leute, die damit bereits Erfahrung haben. Harry
AVR die mag ich ned früher gabs mal die geilen AVR32 mit 150MHz + aber heut nimmer deswegen eher ARM9.
Harald L. schrieb: > sag mal Olaf!....arbeitest du bei Renases in der Marketing-Abteilung? <sozialarbeitermodus> Och Leute, seid doch nett zueinander. Geht raus, tankt ein bißchen Sonnenstrahlen (=Glückshormone) und kommt zurück ;-) </sozialarbeitermodus>
Kai G. schrieb: > Übrigens find ich das decoupling schon recht ungewöhnlich, bzw. SEHR auf > Sicherheit gebaut. 10µ, 100n, 10n und 1n in Reihe? Was für Typen sind > das? X7R/NP0/? Gibts zufällig ne BOM wo das drinsteht? Wow, das ist schon mächtig. Normalerweise sollten für mittlere Lasten auch 100n und 10n parallel reichen. Allerdings sind die heutigen Cores bei einzelnen Operationen sehr hungrig. Da kann es die gesammte Versorgung sehr beruhigen, wenn diese Spitzen lokal abgefangen werden. Je näher das an den Vcc Pinnen des Chips passiert, desto weniger kann sich die 'Welle' über die Platine ausbreiten. Auch sind die DC/DC Wandler weniger aufwändig, weil die nicht dermaßen impulsfest sein müssen. Außerdem gibt es im Auto genügend Probleme, dass der DC/DC Wandler von der Eingangsseite her mit Bursts und Surges belagert wird. Wenn der kurz aus dem Tritt gerät, würde das dann gleich auf die CPU durchschlagen. Generell sollten alle keramischen im Auto >100°C abkönnen. Das Dashboard ist mit der heißeste Platz im Auto (Sonne!). Also X7R ist für alles entkoppelnde perfekt. (Wer jetzt nicht weiß, wovon wir reden: http://en.wikipedia.org/wiki/X7R) Außerdem ist X7R bei vielen Bestückern vorrätig. Gruß, Ulrich
Klare Frage: Was soll der Controller machen? Mit dieser Info kann man etwas passendes raussuchen. Es scheint in dieser Diskussion 2 Zielrichtungen zu geben (man korrigiere mich falls ich das falsch sehe): 1) Ein Controller der den/die Tuner steuert und über ein Interface von außen parametriert wird und dort seine (RDS-)Daten abliefert. Der 'äußere' Controller steuert dann das Bedieninterface, andere Komponenten des Radios und übernimmt wenn er üppig dimensioniert ist evtl. auch gleich die MP3-Dekodierung. Eine digitale Signalverarbeitung ist bei dieser Variante höchstens in einem eigenen Schaltkreis, Controller, DSP oder was auch immer möglich (der dann vermutlich auch von außen gesteuert wird). Der äußere Controller bindet die spezialisierten Controller sozusagen zusammen. 2) Dann gibt es die Variante wo der Controller den Tuner steuert und gleichzeitig die MP3-Funktionen und warscheinlich auch noch die Signalverarbeitung (Klangregelung usw.) machen soll. Wenn außen nichts dran hängt macht er auch noch das Bedieninterface, ansonsten wird das vom 'äußeren' Controller gemacht. Der Controller auf dem Tuner kann ggf. das gesamte Radio steuern. Angesichts dieser Varianten verstehe ich die unterschiedlichen Ansichten darüber welcher Controller denn nun passt. Mir wäre Variante 1 sympatischer da die Pakete und damit die Abhängigkeiten kleiner sind. Der Tuner ist etwas günstiger und universeller einsetzbar. Just my 4 ct.
Jens schrieb: > Angesichts dieser Varianten verstehe ich die unterschiedlichen > Ansichten darüber welcher Controller denn nun passt. Mir wäre > Variante 1 sympatischer da die Pakete und damit die Abhängigkeiten > kleiner sind. Der Tuner ist etwas günstiger und universeller > einsetzbar. FULL ACK Harry
1.) Ok also einfach 2 Tuner mit Audio-CODEC -> Digital + Analogoutput. Zur Kontrolle des Tuners einen kleinen Cortex M0. 2.)SuperH für MP3, Audio-Manipulation, gegebenfalls Splitten der Signale auf mehrere Kanäle (zB Kinder hören ein hörbuch auf den Rücksitzen) und Bedienteil (direkt oder indirekt). 3.) Wer einen Car-PC will baut sich noch ein Beagleboard (Mx) oder so ein. Der Soundprozessor (SuperH) kann dann entweder über Spdif oder I2S mit Daten versorgt werden. 3 Probleme 3 Lösungen nach der Step by Step Methode. Also ich wär so zufrieden! Patrick
Patrick Weinberger schrieb: > 1.) > Ok also einfach 2 Tuner mit Audio-CODEC -> Digital + Analogoutput. > Zur Kontrolle des Tuners einen kleinen Cortex M0. Lieber einen M3, zumindest die von NXP haben etwas mehr RAM als die M0 und der wird für RDS und freq. diversity benötigt. z.B. der LPC1754 sollte ausreichend sein. > 2.)SuperH für MP3 [...] > 3.) [...] Beagleboard (Mx) oder so [...] > 3 Probleme 3 Lösungen nach der Step by Step Methode. Also ich wär so > zufrieden! Ja, auf so ein Konzept würd ich mich auch einlassen. Ist noch sauberer getrennt und wahrscheinlich auch einfacher zu debuggen. Der Controller in Punkt 2 sollte dann aber den Master spielen und alles kontrollieren, also das Linux board auch über den Controller in Pkt 2 mit dem Gesamtsystem kommunizieren.
Frage: 2 Tuner mit 2 Audioausgängen oder nur einem (2. Tuner für Diversity und aktualisierte Senderliste)?
Hi Jens, Das ist so nicht ganz einfach auf zu schlüsseln. Um einen Tuner zu steuern und die RDS-Daten auf einen Bus zu senden, braucht es nicht mal einen ATmega0,5... Das kann jeder Controller im Vorbeigehen. So ein DIN-Schacht ist verdammt Eng, wenn man das ganze mal im Zusammenhang betrachtet: Große DC-Drossel, einige DC/DC Wandler, 4 Class-D Endstufen, ein paar Kühlflächen und jede Menge Hühnerfutter für die Entstörung. Beim MP3-Decoding ist es auch so eine Sache. Wenn man ausschließlich auf MP3 aus ist, dann tut es jeder ARM7 mit 50MHz problemlos, vor allem, wenn er über I2S Ausgänge verfügt. Wenn es aber um zusätzliche andere Decoder geht, wird es teilweise eng. Allerdings ist das dann auch mit einem schnelleren oder größeren Controller nicht getan, denn dann müsste man entweder gleich Linux einsetzen und dessen gängige Mediaplayer nutzen oder man muss deren Decoder portieren. Außerdem ist das Programmieren von Codecs nicht jedermanns Sache. Abgesehen davon gibt es da von TI bessere Chips mit DSP Core. Da wäre man mit einem VLSI VSxxxx besser beraten. Die Chips decodieren alle möglichen Streams und man muss sie nur zyklisch mit Daten füttern. Auch das Lizenzpflichtige WMA decodieren sie, man muss es nur aktivieren. Der VLSI1051 hat auch I2S Ausgänge und kann damit in den digitalen Mischer eingebunden werden. Auch der Vorschlag, dass der Renesas mit I2S Ein- und Ausgängen das Soundmixing übernehmen kann ist auf den ersten Blick sicherlich verlockend. Aber nicht jeder kann digitale Filter programmieren. Muss allerdings auch nicht jeder können, es ist ja ein Gemeinschaftsprojekt, da reicht es, wenn es einer der anderen kann. Trotzdem gibt es dafür, gerade von NXP, ausgezeichnete Chips. Die beherrschen dann auch das Mischen und Überblenden von Kanälen, wenn es um die Freispreche oder das Navi geht. Die CPU könnte dann noch ein 'Bing' oder 'Beep' beisteuern für besondere Funktionen. Wenn man die Grenzen des Projektes fest umreißt, dann kann man auch die CPU festlegen. Soll das Ding letztendlich 'nur' ein MP3-Radio werden, dann ist der Renesas zu groß, bzw hat mit seinen wenigen I2S Fähigkeiten sogar zu wenig Kanäle um einen separaten Audio-Mixer überflüssig zu machen. Will man nach oben hin offener sein, also eventuell Video erlauben, dann ist er zu klein, wenn man nicht auf fertige DVD-Video Laufwerke zurück greifen kann. Also, wenn MP3-Radio, dann CortexM3, kleiner AVR32 oder SAM7. Wenn mehr, dann ARM9/11 oder CortexAx oder großer AVR32. Wenn All-In-One Lösung, dann TMS32xxx Serie, eventuell sogar mit Software-Defined-Radio. Mal ehrlich, wenn es um ein MP3-Radio geht, dann reicht ein kleiner STM32 oder ein AT90USB128 völlig aus, wenn man die Tuner, einen VLSI Decoder, einen Audio-Multiplexer und ein paar Endstufen dazu packt. Er hat USB-OTG, kann also USB-Sticks auslesen. SPI für SD-Cards und VLSI, I2C für die Tuner und den Mixer. Ein Serial-Flash für die bunte Grafik auf dem Display, beides per SPI angebunden oder das LCD/OLED per Parallelbus. Dann kann man ungenutzten Grafikspeicher gleich noch als RAM verwenden. Hab ich noch was vergessen? Wer viele Knöppe mag, kann noch einen PCA9555 I2C-Parallel Chip nehmen und hat zusätzliche 16 Leitungen. Mit dieser Lösung und meinem DVD Laufwerk ist dann sogar MP3 von Scheibe (auch DVD) und Video mit möglich. Würde mir fast ausreichen. Vermutlich ist es mit einem STM32F103 besser ausgestattet, zumal der auch noch CAN hat. Ob ARM7/9 nun veraltet ist und man unbedingt auf CortexMx oder Ax aufsetzen muss, darüber kann man diskutieren. Alle bezahlbaren ARM CPUs können mit OpenOCD programmiert und GDB debuggt werden. Man muss also für nicht tief in die Tasche greifen. Bei STM32 bin ich mir noch nicht sicher. Die ganzen bei ST genannten Compiler sind nur bis 64k Code frei, dann kostet es Geld. Wenn einer einen gcc für STM32 kennt, ich wäre sehr daran interessiert. Gruß, Ulrich
Ach so... Es ist eigentlich egal, welchen Prozessor man einsetzt oder ob man es auf verschiedene CPUs verteilt. Wenn sauberer C-Code geschrieben wird und jedem Chip seine API gegönnt wird, ist die Hardware Plattform in weiten Teilen egal. Man muss ich halt einfach seine eigene kleine Abstraktion für seinen Prozessor schreiben und kann dann den eigentlichen Chip-Treiber gleich verwenden. Womit ich dann noch mal Nut/OS ins Spiel bringe :) Gruß, Ulrich
Wie beim Objektorientierten Programmieren. Also wenn ich es mal in Level unterteilen darf: Level 1: Tuner, Verstärker und Powermanagment Level 2: SuperH oder Spezielle Audio-Dsp Level 3: Bedienteil am Radio mit Display oder/und Car-PC-Board Ein Teil des Level 2 kann nur Device des Level 1 ansteuern. Wobei es zwischen den Leveln fest definierte Schnittstellen gibt welche wie eine Art Fasade wirken. Also Level 3-> Level 2 -> Level 1
Ulrich P. schrieb: > Das ist so nicht ganz einfach auf zu schlüsseln. Um einen Tuner zu > steuern und die RDS-Daten auf einen Bus zu senden, braucht es nicht mal > einen ATmega0,5... Ich finde der Tuner sollte nicht nur die Daten durchschicken, sondern auch dekodieren und interpretieren. Dann ist etwas größeres als ein Atmega schon hilfreich. > Trotzdem gibt es dafür, gerade von NXP, ausgezeichnete Chips. Die > beherrschen dann auch das Mischen und Überblenden von Kanälen, wenn es > um die Freispreche oder das Navi geht. Ja, solche Chips hatte ich vorhin gesucht. Ich weiss das es sie gibt, hab auch schonmal sowas eingesetzt, aber ich finde es echt nicht wieder. Mit integriertem Tuner oder so => kein Problem, find ich, aber nur mixing/equalizing => Pustekuchen. Ansonsten stimme ich Dir zu...
Kai G. schrieb: > Christian H. schrieb: >> - Frei verfügbare Entwicklungsumgebung (gcc mit Bibliotheken; >> idealerweise gdb). > > Heißt frei denn das es der GCC sein muss? nein, ich nehme auch andere, für die ich nichts bezahlen muss. Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch unter Mac OS-X) verwenden kann.
Ok, das ist die andere Sichtweise. Ich meinte das eher so: Level 3: Applikation Radio Level 2: Tuner, Filesystem, Display, Tasten Level 1: Tuner->I2C Control, Filesystem->USB, Grafix/Text->SPI/Databus->Display, Tasten->I2C MatrixDriver... Level 0: API I2C, API SPI, API GPIO, API... Wenn ich dann eine andere CPU verwenden will, dann muss ich nur Level 0 und vielleicht ein paar Dinge in Level 1 anpassen. Fertig. Patrick, Du meinst sicher, dass die Software auch sinnvoll in Tasks aufgeteilt ist und dort bestimmte Dinge nur von einem bestimmten Task erledigt werden sollten. Diese Sicht verhindert immer noch nicht, dass einer entscheiden kann, dass ein Task von der CPU erledigt werden kann, auf der auch alle anderen Tasks laufen und ein anderer diesem Task eine eigene CPU spendiert. Wichtig ist immer, wer redet mit wem, wer kontrolliert wen. Viele Tasks werden immer laufen, ob ihre Nachrichten vom Haupt-Task dann weiter verarbeitet werden, oder nicht, entscheidet der dann anhand von Benutzervorgaben. So würde der RDS Task immer laufen, denn der erkennt das Bit, dass Verkehrsnachrichten kennzeichnet und stellt die Liste der alternativen Frequenzen. Ob das aktivierte Bit nun dazu führt, dass der Master dem USB-MP3 Task sagt, er soll anhalten, weil er jetzt auf den Tuner wechselt, liegt daran, ob der Benutzer TM Aktiviert hat. Natürlich kann der USB-MP3 Task anhalten, wenn Radio läuft, aber der Tuner muss weiter laufen, damit er im Hintergrund immer auf der richtigen Frequenz bleibt und RDS/TMC laufen. Gruß, Ulrich
Christian H. schrieb: >> Heißt frei denn das es der GCC sein muss? > nein, ich nehme auch andere, für die ich nichts bezahlen muss. > Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch > unter Mac OS-X) verwenden kann. <ironie>und noch Amiga-OS (ab Kickstart/Workbench 1.4) und CPM</ironie> SCNR
Ulrich das mein ich ned. Ich wollt damit sagen jede Schicht über eine bestimmte Schnittstelle verfügt welche nach definition nicht mehr geändert werden darf. So kann man das Modul einfach ersetzen. Bei der Software würd ich mit objektorientierten C arbeiten. Mfg Patrick
> So würde der RDS Task immer laufen, denn der erkennt > das Bit, dass Verkehrsnachrichten kennzeichnet und stellt die Liste der > alternativen Frequenzen. Ist übrigens nicht nur 1 Bit, sondern 2 die für Verkehrsnachrichten interpretiert werden müssen. Die beiden Bits zusammen geben nicht nur an wie Du sagtest ob bei dem aktuellen Sender gerade Verkehrsnachrichten ausgesendet werden, sondern auch ob man prinzipiell für Verkehrsnachrichten in den EON Informationen nachschauen soll (also bei anderen Sendern aus dem Netzwerk, weil der aktuelle keine oder nur "kastrierte" aussendet). Auch an diesem handling kann man gute und schlechte Radios (bzw. RDS implementationen) auseinanderhalten. Schlechte Radios springen nicht auf andere Sender aus dem aktuellen Netzwerk um wenn sie VKnachrichten aussenden. Solche Fehler bekommt man im allgemeinen nicht direkt mit, höchstens durch den Informationsmangel.
Christian H. schrieb: > Kai G. schrieb: >> Christian H. schrieb: >>> - Frei verfügbare Entwicklungsumgebung (gcc mit Bibliotheken; >>> idealerweise gdb). >> >> Heißt frei denn das es der GCC sein muss? > > nein, ich nehme auch andere, für die ich nichts bezahlen muss. > Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch > unter Mac OS-X) verwenden kann. Du verwechselst Open-Source mit kostenlos!!!! Und zu einem Open-Source-Autoradio gehört auch, daß die verwendeten Toolchains Open-Source und frei verfügbar sind! Harry
Hi Kai, ist schon recht :) Es ging in dem Beispiel um das Tasking und die API, nicht um das Bit speziell. Abgesehen davon wäre es für den Master-Task weiterhin nur ein Bit welches sagt, dass es Nachrichten gibt. Dass es auf mehrere Bits und deren korrekte Konstellation ankommt wäre Aufgabe des RDS-Tasks :) Zur Toolchain kann ich nur sagen, dass es ohnehin schon der teuer wird, die Hardware umzusetzen. Es ist daher belanglos, ob die Toolchain kostenfrei oder OpenSource-kostenfrei ist. Allerdings besteht bei den Nicht-O/S Toolchains immer die Gefahr, dass sie limitiert ist ( nur xxkB Code), dass sie mit der Plattform stirbt, wenn die Nachfrage nicht hoch genug ist oder dass sie nicht auf allen Plattformen einsetzbar ist. Bei GCC kann man immerhin Win/Linux/Mac erschlagen, Amiga und CP/M bleiben wohl aussen vor, fürchte ich. Wenn GCC läuft, dann kann ich meinen Source-Insight einsetzen und ein anderer Eclipse. Ist dann egal. Was ich nebenbei für den STM32 wäre ein gcc, kein kostenlos-Tool. Gruß, Ulrich
Ulrich P. schrieb: > Was ich nebenbei für den STM32 wäre ein gcc, kein kostenlos-Tool. Wie ist das zu verstehen? GCC und alles, was man daraus ableitet unterliegt der GPLv2 und ist damit incl. Quellcode offen, egal, was man damit macht oder wie man das verändert. Harry
ach ja....wenn es für STM32 nur kommerzielle Entwicklungsumgebungen gibt, fällt der ja aus o.g. Gründen dann auch aus. (hab ich aber noch nicht recherchiert) Harry
Ok, da hatte ich noch was vergessen. Die Einwände, dass Renesas nicht so verbreitet ist, kann ich verstehen. Sie sind sicherlich gut vertreten, aber nicht in der 'Bastelnden Schicht'. Daher fehlt es an vielen Dingen, die alle erst einmal neu gemacht werden müssten. Man kann sich das ein oder andere Aus den AppNotes von Renesas zusammen bauen, aber ein eigenes System mit TaskSwitching aufzusetzen, heißt wirklich ganz unten anfangen. Ich würde die Plattform noch mal überdenken. Bei den CPUs sollte man genau so wie bei dem Tuner, ganz genau überlegen, ob man das Risiko eingeht. Die CPU ist in Produktion, aber unter den meisten Lesern unbekannt. Risiko: Einige müssen alles komplizierte machen, bis die anderen einsteigen können. Vorsicht auch bei dem Tuner, der ist im Sample-Stadium. Es kann also noch alle möglichen Bugs beinhalten und wir suchen uns nen Ast ab, bis wir merken, dass es an uns garnicht liegt. Außerdem kann es sein, dass außer uns keiner das Teil kauft, also stampft NXP das Teil wieder ein, bevor die ersten B-Samples draußen sind. Naja, NXP ist nicht Maxim, also besteht Hoffnung. Ich habe keinen Kommentar bzgl. Nut/OS (www.ethernut.de) gehört, aber Atmel wird schon vollständig unterstützt. Da könnte man bei der Wahl der CPU in gewissem Rahmen auch Freiheiten erlauben. Der reine SD-Card MP3-Radio Bastler nimmt einen ATmega128, der Fullfeatured Basteler einen SAMx/AVR32. Die Bausteine sind verfügbar, die Treiber existieren, Taskswitching, Semaphoren und Mailboxen gehen auch. Auch TCP/IP ist dabei. An LCD/OLED schreibe ich gerade. Damit wäre die Diskussion um die CPU überflüssig. Wer es gerne mit der groben Kelle mag, der portiert Nut/OS auf den Renesas, warum nicht. Gruß, Ulrich
...und ich kann für den STM32 nichts freies finden. Damit hätten wir einen Kandidaten weniger. Harry
Harald L. schrieb: > Ulrich P. schrieb: >> Was ich nebenbei für den STM32 wäre ein gcc, kein kostenlos-Tool. > > Wie ist das zu verstehen? > GCC und alles, was man daraus ableitet unterliegt der GPLv2 und ist > damit incl. Quellcode offen, egal, was man damit macht oder wie man das > verändert. > Das ist mir klar. Einfach ausgedrückt, freue ich mich über jeden freien kostenlosen Compiler, aber am liebste.... So ein Quatsch, ich bin in meinen Projekten etwas durcheinander geraten. Die Compiler waren ein Problem bei den STM8. Der STM32 ist ein CortexM3 und der GCC funktioniert damit wunderbar. Ich ziehe meine Frage also zurück :) Sorry!
www.ethernut.de sieht sehr vielversprechend aus! Ich werd im Wiki mal einen Hinweis einbauen. Harry
Danke Harry! http://sites.google.com/a/stf12.net/developer-sw-fw/eclipse-demo Zeigt GCC zusammen mit STM32. Der Vorteil der ST CPUs ist, dass sie sehr günstig sind. Sie sind schnell und auch gut mit Peripherie ausgestattet. ST ist auch im Automotive Bereich gut platziert. Ich muss für die Dinger vermutlich eh das Nut/OS portieren, da ich sie beruflich einsetze. Mein EIR und damit auch meine erste Idee den genannten Tuner einzusetzen basieren auf Nut/OS, also wird es einen Treiber dafür geben. Auch ein breitformatiges LCD oder OLED wird es geben, bzw dessen Ansteuerung. Viele andere Sachen sind schon drin. Gruß, Ulrich
Ulrich P. schrieb: > Die Compiler waren ein Problem bei den STM8. Der STM32 ist ein CortexM3 > und der GCC funktioniert damit wunderbar. Ich ziehe meine Frage also > zurück :) Ahh....damit ist der STM32 wieder im Rennen ;) Harry
Hallo, finde die Diskussion äußerst Interessant. Bin sehr an dem Radio interessiert kann aber wahrscheinlich nur wenig dazu beitragen. Möchte es aber auf jeden Fall auch aufbauen. Ich kann mir auch vorstellen, dass es vielen anderen ähnlich geht. Jetzt aber zum Grund meines Geschreibsels. Ihr diskutiert hier gerade über die CPU und es wird immer nur MP3 als Format neben dem Radio erwähnt. Gerade in einem Open-Source Radio finde ich es eigentlich unerläßlich, auch OGG und FLAC zu unterstützen. Ich habe z.B. den größten Teil meiner Musik im Flac Format gespeichert. Ich möchte sie eigentlich nicht jedesmal umkodieren, wenn ich sie mit in's Auto nehmen möchte. Wenn ich dran denke, das mein Sansa Player mit Rockbox drauf diese Formate anstandslos abspielt, und da sicher keine Super CPU drin ist, sollte das hier doch eigentlich auch möglich sein. Schließt aber natürlich Hardware MP3 Dekoder aus. Übrigens müsste man doch, was Implementierung von Codecs angeht, vom Rockbox Projekt einiges übernehmen können?! Just my 2 Cent Gerhard
Der Vorteil von Nut/OS wäre der gleiche wie bei Linux, das System wird separat von der Applikation entwickelt. Also alle Chips und deren API werden im System gepflegt, das Radio selbst wird separat in einem eigenen Repository gehalten. Wer mitmachen will, lädt sich die Quellen des Systems, macht einen Build und lässt das Applikationsverzeichnis erzeugen. In letzteres lädt er dann die Radio-Applikation und kompiliert sie. Dann noch flashen und fertig. Wer einen anderen Tuner Chip oder ein anderes Display verwenden will, schreibt eben seinen eigenen Treiber und macht die API OS-Konform. Dann braucht es auch nur wenige Anpassungen in der Appliaktion ( Größe, Zeilenanordnung, Schrifttype) und schon läuft es wieder. Gruß, Ulrich
Gerhard Zintel schrieb: > Hallo, > > finde die Diskussion äußerst Interessant. Bin sehr an dem Radio > interessiert kann aber wahrscheinlich nur wenig dazu beitragen. Möchte > es aber auf jeden Fall auch aufbauen. Ich kann mir auch vorstellen, dass > es vielen anderen ähnlich geht. So würde ich das nicht sehen. Hier lesen und schreiben alle drei Gruppen. Die, die glauben, dass das alles einfach ist, die denen die Idee schon zu komplex erscheint und die, die wissen, was das alles bedeutet, bzw. das oder ähnliches schon mal gemacht haben. Schau mal was passiert und Du findest Deinen Mitmach-Punkt. > > Jetzt aber zum Grund meines Geschreibsels. Ihr diskutiert hier gerade > über die CPU und es wird immer nur MP3 als Format neben dem Radio > erwähnt. Gerade in einem Open-Source Radio finde ich es eigentlich > unerläßlich, auch OGG und FLAC zu unterstützen. Ich habe z.B. den > größten Teil meiner Musik im Flac Format gespeichert. Ich möchte sie > eigentlich nicht jedesmal umkodieren, wenn ich sie mit in's Auto nehmen > möchte. > > Wenn ich dran denke, das mein Sansa Player mit Rockbox drauf diese > Formate anstandslos abspielt, und da sicher keine Super CPU drin ist, > sollte das hier doch eigentlich auch möglich sein. Schließt aber > natürlich Hardware MP3 Dekoder aus. > Das ist falsch, sorry: http://www.vlsi.fi/en/products/vs1053.html Ogg Vorbis MP3 = MPEG 1 & 2 audio layer III (CBR+VBR+ABR) MP1 & MP2 = MPEG 1 & 2 audio layers I & II optional MPEG4 / 2 AAC-LC(+PNS), HE-AAC v2 (Level 3) (SBR + PS) WMA4.0/4.1/7/8/9 all profiles (5-384 kbps) FLAC lossless audio with software plugin (upto 24 bits, 48 kHz) WAV (PCM + IMA ADPCM) General MIDI 1 / SP-MIDI format 0 > Übrigens müsste man doch, was Implementierung von Codecs angeht, vom > Rockbox Projekt einiges übernehmen können?! > Auch das ist sicherlich eine Lösung. Der Software-Stack des Elektor Internt Radio funktioniert auch auf einem SAM7X256 Board mit einem TI-AudioCoDec als DAC. Der SAM7X macht das Decoding in Software und nutzt dazu einen GPL Decoder. Das Nut/OS selbst ist BSD, sieht für GPL Code aber ein besonderes Verzeichnis vor, dass auf diesen Umstand hinweist. Es ist also möglich BSD und GPL Code zu mischen. Es könnten also auch andere Codecs portiert werden, ohne die GPL zu verletzen. Aber wenn wir auf einen Software-Decoder gehen und dann jeder seine Wünsche für die Formate einklagt, dann landen wir doch wieder bei einem 400MHz ARM oder einem Atom und Linux. Ich denke, die Trennung von CoDec und CPU löst eine ganze Menge Probleme, vor allem für die Mitmacher, die noch nicht 20 Jahre Assemblern und Coden und mal eben auswendig das Framing von MPEG aufschreiben können. Außerdem kann man sich recht schnell auf die eigentliche Sache, das Radio, konzentrieren. Also, nicht übel nehmen, ich kann nachvollziehen, dass man das ganze in einer schnellen großen CPU verarbeiten möchte. Aber ich fürchte, dass die Nachbaubarkeit und die Verstehbarkeit darunter leidet und der Zugang zu den Innereien des OSCARs nur wenigen vorbehalten bleibt. Aber je weniger dabei von Anfang an mitmachen, desto schnell verläuft das ganze auch im Sande.
Patrick Weinberger schrieb: > Ich würd da eher die Luminary bevorzugen, sind etwas schneller. Hmmm, Luminary wird auch gerne zusammen mit dem VLSI eingesetzt :) http://www.watterott.net/projects/webradio-arm
>Man kann sich das ein oder andere Aus den AppNotes von Renesas >zusammen bauen, aber ein eigenes System mit TaskSwitching aufzusetzen, >heißt wirklich ganz unten anfangen. Es gibt doch verschiedene RTOS's, bsp RTEMS, UCOS... , die mit den meisten 32 Bitern gehen. (und das meiste (nicht Scheduler) von RTOS's ist auch meistens in C) ----------------- Bei Coldfire gibts auch Controller mit Audio-Schnittstellen, zB MCF5249 (kostet ca 12eu bei EBV, ist aber kleiner als der SH2A..., ca 125 MIPS, ca 100kB SRAM). Manche Coldfire's werden oft auch im ConsumerMarkt eingesetzt, sind auch alle langfristig verfügbar, ähnlich den legendären 68K-CPUs.
@Ulrich brauch ich bei Nut/OS wirklich dieses ominöse nutconf, wenn ich die libs im Eclipse verwenden will? Auf meinem 64bit-System bekomm ich nämlich einen Segfault. Wenn ich das richtig seh, sollen die doch nur den Input für autoconf und automake generieren. Harry
@Harald: Nein, Du kanst das nuconfigure auch so laufen lassen, oder Dir das qnutconf über Qt generieren. Das NutConf ist schon sehr alt und wird wohl durch qnutconf abgelöst. Traditionell war der code für nutconf immer dabei und man hat es sich selbst generiert. Das ist auch bei qnutconf so. Ich werde mich mal dafür einsetzen, dass es qnutconf auch als binary irgendwo gibt. Ich kann es aktuell aber nur für 32bit win anbieten. Ich habe kein 64bit System.
> Trotzdem gibt es dafür, gerade von NXP, ausgezeichnete Chips. Die > beherrschen dann auch das Mischen und Überblenden von Kanälen, wenn es > um die Freispreche oder das Navi geht. TI (auch NAT,AD) haben da auch CoDecs.
Ulrich P. schrieb: > @Harald: > Nein, Du kanst das nuconfigure auch so laufen lassen, oder Dir das > qnutconf über Qt generieren. Das NutConf ist schon sehr alt und wird > wohl durch qnutconf abgelöst. Traditionell war der code für nutconf > immer dabei und man hat es sich selbst generiert. Das ist auch bei > qnutconf so. Ich werde mich mal dafür einsetzen, dass es qnutconf auch > als binary irgendwo gibt. Ich kann es aktuell aber nur für 32bit win > anbieten. Ich habe kein 64bit System. ahh...ok...ich wollte eigentlich für Nut/OS ganz auf dieses autoconf/automake verzichten. Ich mach mir Eclipse-Projekte da raus. So langsam seh ich da auch schon ein wenig durch. Ethernet-Hardware hab ich zwar nicht hier rumliegen, aber das Multithreading will ich mal testen. Das scheint mir doch sehr spannend zu sein. Aber das qnutconf werd ich mir dann auch mal beschaffen. Achso....das ist übrigens 64bit-Linux ;) Harry
Das ist ja das Problem, wenn man einen allgemeinen Configurator bauen will. Java scheidet aus, weil das ein riesiger Ballast ist, den man dann immer mit sich herum schleppt. Aber wenn man dann einen Installer oder Konfigurator haben will, dann muss man ihn für 4..6 Systeme kompilieren, die man auch erst mal haben muss. Du kannst auch die nutconfigure Datei manuell anpassen und dann das make abfahren. Die Brücke zischen den Einsteigern und den Profis ist halt immer ein architektonisches Meisterwerk :) Da das Nut/OS Modular ist, kannst Du natürlich auch das nutnet raus lassen, wenn Du kein Ethernet hast oder brauchst. Auf einem Treffen der Nut/OS Gruppe nach der letzten Embedded nannte jemand irgendwas um 1.5k für den Kernel des Nut/OS auf den er es geschrumpft hatte. Finde ich beachtlich, repräsentiert aber eben die Idee hinter dem System. So, ich mach mich mal auf in die Horizontale... Bis Morgen!
Ulrich P. schrieb: > Das ist ja das Problem, wenn man einen allgemeinen Configurator bauen > will. Java scheidet aus, weil das ein riesiger Ballast ist, den man dann > immer mit sich herum schleppt. Aber wenn man dann einen Installer oder > Konfigurator haben will, dann muss man ihn für 4..6 Systeme kompilieren, > die man auch erst mal haben muss. > Du kannst auch die nutconfigure Datei manuell anpassen und dann das make > abfahren. > ich hab die Win-Version unter Wine laufen.....sehr fein! Da werd ich mich eingehender mit beschäftigen. Danke für den Tip! Und JA!...das ist auch für unser Autoradio interessant! Harry
Ist ja schön das wir jetzt ein Betriebssystem haben (auch wenn ich den ganzen Ethernet kram lieber draussen sehen wollte), aber das war doch erstmal nicht das kernproblem, oder? Ich habe das Gefühl das wir das System künstlich mehr und mehr vergrößern und nachher entweder eine Platine erhalten mit 10 großen ICs die sich fast nicht mehr routen lässt und man womöglich auf >= 4 LAyer gehen muss, oder wir kriegen zig einzelplatinen und für ein Grundsystem braucht man schon 4 oder 5 Platinen.
Kai G. schrieb: > Christian H. schrieb: >>> Heißt frei denn das es der GCC sein muss? >> nein, ich nehme auch andere, für die ich nichts bezahlen muss. >> Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch >> unter Mac OS-X) verwenden kann. > > <ironie>und noch Amiga-OS (ab Kickstart/Workbench 1.4) und CPM</ironie> > > *SCNR* Das war kein Scherz. Ich habe zuhause drei Systeme, die ich wechselseitig nutze. Hauptsächlich aber Linux und Mac OS-X. Ok, wenn es nur unter Windows funktioniert, muss halt VirtualBox herhalten. Mein Amiga steht noch bei meinen Eltern auf dem Dachboden. Workbench 1.2, wenn ich mich recht erinnere. CPM geht nicht mehr, da ich meinen Commodore 128D vor langer Zeit verkauft hatte ;-) Wäre auch zu viel verlangt.
Harald L. schrieb: > Du verwechselst Open-Source mit kostenlos!!!! Nein, ich spreche in diesem Satz speziell von kostenlosen Programmen; ob Open-Source oder nicht. > Und zu einem Open-Source-Autoradio gehört auch, daß die verwendeten > Toolchains Open-Source und frei verfügbar sind! Da bin ich ja beruhigt ;-)
Ulrich P. schrieb: > Das ist falsch, sorry: > http://www.vlsi.fi/en/products/vs1053.html > Ogg Vorbis > MP3 = MPEG 1 & 2 audio layer III (CBR+VBR+ABR) > MP1 & MP2 = MPEG 1 & 2 audio layers I & II optional > MPEG4 / 2 AAC-LC(+PNS), HE-AAC v2 (Level 3) (SBR + PS) > WMA4.0/4.1/7/8/9 all profiles (5-384 kbps) > FLAC lossless audio with software plugin (upto 24 bits, 48 kHz) > WAV (PCM + IMA ADPCM) > General MIDI 1 / SP-MIDI format 0 Wie sieht es denn aus? Ist MP3 (und Konsorten; ich spreche im Folgenden der einfachheit halber von MP3) wirklich für jeden ein Muss? Gehört ja eigentlich nicht direkt zu einem Radio, da kein Sender in MP3 sendet. Wenn der Prozessor, der die Grundfunktionen des Radios behandelt, auch MP3 (und Zugriff auf die benötigten Speichermedien) beherrscht, ist es ja in Ordnung. Es ist aber für die Grundfunktion nicht notwendig. Reicht der oben genannte Codes denn nicht aus? Ich bin eher für diesen Bausteil, da man den Prozessor dadurch klein halten kann. Auch ist das Basisboard dann wirklich nur ein Radiomodul mit Komfortfunktion. Das muss dann auch kein Autoradio mehr werden. Ich bin da eher für Modularisierung. 1. Ein kleines Board, welches nur das Radio beinhaltet und per RS232 komplett fernbedienbar ist. 2. Ein zweites Board, welches die Audio-Verarbeitung (Filter, MP3, ...) macht. 3. Ein drittes Board, welches die Nutzerschnittstellen behandelt. Dies kann dann auch ein großer, fetter Prozessor mit Linux, Amiga-OS oder CPM sein. > Außerdem kann man sich recht schnell auf die eigentliche Sache, das > Radio, konzentrieren. > > Also, nicht übel nehmen, ich kann nachvollziehen, dass man das ganze in > einer schnellen großen CPU verarbeiten möchte. Aber ich fürchte, dass > die Nachbaubarkeit und die Verstehbarkeit darunter leidet und der Zugang > zu den Innereien des OSCARs nur wenigen vorbehalten bleibt. Aber je > weniger dabei von Anfang an mitmachen, desto schnell verläuft das ganze > auch im Sande. Full ACK.
Christian H. schrieb: > Wie sieht es denn aus? Ist MP3 (und Konsorten; ich spreche im Folgenden > der einfachheit halber von MP3) wirklich für jeden ein Muss? Also für mich definitiv 100%ig! OGG und co. brauche ich nicht, wäre für mich also nicht 100% erforderlich. Weiss nicht wie es bei anderen aussieht. Also ein MP3 decoder in einem µC würde voll und ganz reichen => Ein Lieferant für ein Bauteil weniger. > Reicht der oben genannte Codes denn nicht aus? Ich bin eher für diesen > Bausteil, da man den Prozessor dadurch klein halten kann. Das muss kein 200 MHz x86 sein, es reicht etwas in der ARM7 gegend. Da gibt es bei NXP bestimmt 10 verschiedene die in Frage kommen die alle Lötbar sind. > 1. Ein kleines Board, welches nur das Radio beinhaltet und per RS232 > komplett fernbedienbar ist. > 2. Ein zweites Board, welches die Audio-Verarbeitung (Filter, MP3, ...) > macht. > 3. Ein drittes Board, welches die Nutzerschnittstellen behandelt. Dies > kann dann auch ein großer, fetter Prozessor mit Linux, Amiga-OS oder CPM > sein. Hätte ich mal nicht AMIGA-OS gesagt, das hab ich jetzt davon ;-) >> Also, nicht übel nehmen, ich kann nachvollziehen, dass man das ganze in >> einer schnellen großen CPU verarbeiten möchte. Aber ich fürchte, dass >> die Nachbaubarkeit und die Verstehbarkeit darunter leidet und der Zugang >> zu den Innereien des OSCARs nur wenigen vorbehalten bleibt. Aber je >> weniger dabei von Anfang an mitmachen, desto schnell verläuft das ganze >> auch im Sande. Ja, ich finde auch wir sollten uns bald auf eine Architektur geeinigt haben, andernfalls wird es müßig... Vorschlag: Das mit dem Forum wird für die Diskussion etwas unübersichtlich. Jeder der einen alternativen Vorschlag hat macht eine art Blockdiagram und packt es mit etwas text ins Wiki [1] (Vor/Nachteile Erläuterungstext) und dann stimmen wir ab. Jeder sollte das hier grob ankündigen das er was vorbereiten, andernfalls machen 3 Leute dasselbe. Abstimmung dann am Montag abend (Vorschlag, es sei denn jemand sagt vorher er braucht länger für die Ausarbeitung seines Vorschlags) Was haltet ihr davon? [1] http://osar.it-livetalk.de/ ...man kann es nicht oft genug posten :-) PS: Ich würde dann das System mit 1 großem µC (2 Tuner, RDS, analogem Audio und software MP3 decoder vertreten) und 1 kleinen Frontpanel µC (AtMega Liga).
Olaf Kaluza schrieb: > Ich weiss nicht ob man von uns aus in > Japan bei Amazon bestellen kann. Vielleicht will das mal einer > ausprobieren? Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, probiere ich es sofort aus ;)
Benjamin Maresch schrieb: > Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, > probiere ich es sofort aus ;) Stand oben, aber hier nochmal: http://www.amazon.co.jp/Interface-%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9-2010%E5%B9%B4-06%E6%9C%88%E5%8F%B7-%E9%9B%91%E8%AA%8C/dp/B003D7CGYA
Kai G. schrieb: > Benjamin Maresch schrieb: >> Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, >> probiere ich es sofort aus ;) > > Stand oben, aber hier nochmal: > http://www.amazon.co.jp/Interface-%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9-2010%E5%B9%B4-06%E6%9C%88%E5%8F%B7-%E9%9B%91%E8%AA%8C/dp/B003D7CGYA Habe eines bestellt... Anscheinend ist es möglich.
Benjamin Maresch schrieb: > Kai G. schrieb: >> Benjamin Maresch schrieb: >>> Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, >>> probiere ich es sofort aus ;) >> >> Stand oben, aber hier nochmal: >> > http://www.amazon.co.jp/Interface-%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9-2010%E5%B9%B4-06%E6%9C%88%E5%8F%B7-%E9%9B%91%E8%AA%8C/dp/B003D7CGYA > > Habe eines bestellt... > Anscheinend ist es möglich. Wie teuer ist es (Versandkosten) und WIE um Himmels willen hast Du den Weg durch den Bestellvorgang gefunden? ---- @All: Bitte nicht "überlesen": Beitrag "Re: Open source Autoradio"
Kai das mit dem Tuner-Modul ist schon geklärt. Es muss nur noch gklärt werden wieviel verantwortung 2. µC bekommt und wie das decodieren von MP3 und co geschieht. Mfg Patrick
>> Habe eines bestellt... >> Anscheinend ist es möglich. > > Wie teuer ist es (Versandkosten) und WIE um Himmels willen hast Du den > Weg durch den Bestellvorgang gefunden? Das mit dem Bestellvorgang ist doch einfach, da identisch mit Amazon.de Ich habs soweit versucht, bis Mail-Adresse/PW abgefragt werden, meinen amazon.de-Account nehmen die nicht :)
Kai G. schrieb: > Benjamin Maresch schrieb: >> Kai G. schrieb: >>> Benjamin Maresch schrieb: >>>> Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, >>>> probiere ich es sofort aus ;) >>> >>> Stand oben, aber hier nochmal: >>> >> > http://www.amazon.co.jp/Interface-%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9-2010%E5%B9%B4-06%E6%9C%88%E5%8F%B7-%E9%9B%91%E8%AA%8C/dp/B003D7CGYA >> >> Habe eines bestellt... >> Anscheinend ist es möglich. > > Wie teuer ist es (Versandkosten) und WIE um Himmels willen hast Du den > Weg durch den Bestellvorgang gefunden? > > ---- > @All: Bitte nicht "überlesen": > Beitrag "Re: Open source Autoradio" Das ist ganz einfach... ich habe den Link aufgerufen, dann rechts den Bestellen Button auf Japanisch und dann den Warenkorb aufrufen... Das solltest du noch schaffen ohne Japanisch zu können (ist identisch mit Amazon de) Dann fragt er nach dem Login -> Anmeldung mit Amazon de daten nicht möglich => Neuanmelden (TIPP: oben ist ein Link: "Click here to see in English") -) Email adressse eingeben -) "I am a new customer" auswählen -) Auf der nächsten seite alles Ausfüllen und weiter -) Auf der nächsten Seite ist oben ein Link (International (outside japan)) den anklicken -) Versandadresse ausfüllen -) Zahlungsart ausfüllen -) Bestellen & Fertig TIPP: Das Interface kostet 2200Yen ~ 20 Euro Die Versandkosten 3700Yen ~ 33 Euro Daher würde ich raten gleich eine sammelbestellung für alle machen. Wenn ihr wollt kann ich das Übernehmen.
Angehängte Dateien:
-
Cascade.jpg
740 KB
Ok, um noch mal auf die Basis-Plattform zurück zu kommen: Der/die Tuner brauchen keinen ARM o.Ä Kaliber, um sie zu steuern. Auch die Auswertung welcher Tuner nun sein Audio wegen besserem Empfang auf den Mixer geben kann, braucht keinen ARM. Auch das Auslesen von SD-Cards oder USB-Stick braucht keinen ARM, wenn man das Decoding einem VLSI überlässt. Er muss ja nur alle paar ms ein Paket von 32 Bytes an den VLSI senden. Auch für die Grafik auf einem breiten Farb-LCD braucht es keinen ARM. Ich glaube, die Fähigkeiten eines 8-Bitters mit effektiver Programmierung ( und ich meine damit nicht den Massiven Einsatz von Assembler) werden deutlich unterschätzt. Nur mal als Beispiel: Ich steuere 3 PWM-Lüfter mit PI-Reglern, einen 120W DC/DC Wandler in Software über Highspeed PWM, zwei LEDs, eine RS422, lese 4 Temperatursensoren stelle über USB eine Konfigurationsschnittstelle zur Verfügung. Das alles auf einem ATmega32U4 mit 8MHz. Und es ist trotz USB-Bootloader noch über 1k frei. Trotzdem ist es ratsamer, auf ein 32-Bit System zu gehen, weil - Grafiken sich darin besser verwalten lassen (18-Bit RGB bei LCD/OLED) - Pakete an den VLSI nur 4 Speicherzugriffe brauchen - 32-Bitter DMA/PDC haben - STM32 mit mehr Fähigkeiten weniger/gleichviel kosten wie ein ATmega - I2S Interfaces praktisch sind, um doch noch mehr machen zu können - OnChip Debugging via JTAG praktisch und möglich ist ohne ~250€ für ein spezielles Dongle - System-Timer und andere Features ein Multitasking besser unterstützen ... Wenn man meine Postings verfolgt hat, kann man leicht erkennen, dass die CPU eigentlich nur wenige Pinne benötigt, denn es werden für eine Basisversion des Radios nur 3..4 Bussysteme benötigt: SPI: SD-Card, Serial-Flash I2C: Tuner, Mixer/ Audio-Controller, CD/DVD Drives, Tasten USB: Speichersticks und Software-Update Optional: I2S: Optional, wenn MP3-Decoding per Software oder System-Sounds RS422: Eigene Erweiterungen (von RS232 rate ich eigentlich ab) CAN: für die Anbindung an vorhandene PKW-Features wie Display oder LFB. Der Vorteil der STM32 ist dabei, dass es sie, wie die Atmel Chips, in einer großen 2D-Matrix gibt. Man kann ein und den selben Core sowohl mit wenig oder vielen Pinnen und Features bekommen als auch mit wenig oder viel Speicher. Wer also viele Dinge machen will, kann die OSCAR Software auf einen großen 100-Pinner mit 512kB Flash packen und loslegen, wer nur ein kleines Radio ohne alles will, packt die Software auf einen 32-Pinner mit 128k Flash. Andererseits kann es auch einfach eine Platine geben, die einen 64-Pinner unterstützt und der Nachbauer kann entscheiden, ob er einen mit 64k oder 512k Flash einsetzt. Aus diesen Fakten ergibt sich auch, dass das Layout garnicht so komplex ist, denn alle Teilnehmer hängen mehr oder weniger an 3..4 seriellen Bussen. Sollte zusätzlicher paralleler Speicher erforderlich sein, so kann und muss dieser lokal dicht an der CPU platziert werden. Das halte ich bei den bislang angesprochenen Features für überflüssig. Ob es im Auto nicht ohnehin ratsam ist, ein Layout als 4-Layer zu machen und die Außenseiten hauptsächlich für Masse und Power zu nehmen ist eine andere Diskussion. Man kann durch Beachtung von Abständen auch bei 2-Lagen Audio- und Datenbusse gut nebeneinander führen. Kostet halt ein paar Ferrite mehr. Wir haben bei einem PKW-Radio nicht das Problem, dass da zu viele Käfer auf der Platine sitzen, sondern dass es einiges an Entstörmaßnahmen erfordert. Außerdem werden ein paar DC/DC Wandler benötigt. Wenn der Chip USB ab Haus unterstützt, ist die dafür notwendige Fläche minimal. Ein Power-Controller für die +5V, zwei Induktivitäten und 3 Widerstände. Das passt auf 10x5mm. Es führt kein Weg an 0603 und 0402 SMD vorbei, nur um das gleich fest zu stellen. Aber das ist nichts, was man nicht von Hand löten kann. BGA ist zum Glück nicht erforderlich. Nur um mal zu verdeutlichen wovon wir reden, ein Bild der Becker Cascade Plattform im Anhang.
> Der/die Tuner brauchen keinen ARM o.Ä Kaliber, um sie zu steuern. Auch > die Auswertung welcher Tuner nun sein Audio wegen besserem Empfang auf > den Mixer geben kann, braucht keinen ARM. Es geht sicher auch mit etwas kleinerem weil man nicht viel rechenleistung benötigt, aber für eine gute RDS follow-me und EON implementation braucht es relativ viel Ram. Da ich wirklich Frequency diversity machen will, so wie es Dein Radio von dem Photo übrigens auch macht, zumindest tun es die GrandPrixe von Becker, hätte ich gerne eine große CPU für den Tuner. Wir können ja gerne mal eine Diskussion über RDS starten wenn Du es nicht glaubst, aber dann lieber per PM :-) > Nur mal als Beispiel: > Ich steuere 3 PWM-Lüfter mit PI-Reglern, einen 120W DC/DC Wandler in > Software über Highspeed PWM, zwei LEDs, eine RS422, lese 4 > Temperatursensoren stelle über USB eine Konfigurationsschnittstelle zur > Verfügung. Das alles auf einem ATmega32U4 mit 8MHz. Und es ist trotz > USB-Bootloader noch über 1k frei. Das sollte auch mit etwas kleinerem als einem ATMega gehen :-) Die EINZELLÖSUNGEN brauchen keine großen CPU, aber die gesamtlösung schon. Ich bau Dir auch ein komplettes Autoradio um einen AtMega8 mit akzeptablen RDS, MP3 decoding mit externem decoder und SD Karten support, aber da braucht es halt einige unschöne Konstrukte. ...Hab auch schon z.B. ein komplettes Filesystem für einen AT90S1200 (hat KEIN RAM!!!) programmiert, FAT12/16/32 support, natürlich in assembler, read only, long filename support, directory lesen, ... Aber schön, transparent und übersichtlich ist halt anders. > Wenn man meine Postings verfolgt hat, kann man leicht erkennen, dass die > CPU eigentlich nur wenige Pinne benötigt, denn es werden für eine > Basisversion des Radios nur 3..4 Bussysteme benötigt: > SPI: SD-Card, Serial-Flash > I2C: Tuner, Mixer/ Audio-Controller, CD/DVD Drives, Tasten > USB: Speichersticks und Software-Update > Optional: > I2S: Optional, wenn MP3-Decoding per Software oder System-Sounds > RS422: Eigene Erweiterungen (von RS232 rate ich eigentlich ab) > CAN: für die Anbindung an vorhandene PKW-Features wie Display oder LFB. Das mit den wenig Pinnen ist so ne Sache, such mal die CPU die genau nur Deine Busse zur Verfügung stellt. > Der Vorteil der STM32 ist dabei, dass es sie, wie die Atmel Chips, in > einer großen 2D-Matrix gibt. Man kann ein und den selben Core sowohl mit > wenig oder vielen Pinnen und Features bekommen als auch mit wenig oder > viel Speicher. Wir brauchen uns ja nur auf eine CPU einigen, ich hab nicht vor alle 2 Wochen eine andere zu benutzen. > Wer also viele Dinge machen will, kann die OSCAR Software > auf einen großen 100-Pinner mit 512kB Flash packen und loslegen, wer nur > ein kleines Radio ohne alles will, packt die Software auf einen > 32-Pinner mit 128k Flash. Andererseits kann es auch einfach eine Platine > geben, die einen 64-Pinner unterstützt und der Nachbauer kann > entscheiden, ob er einen mit 64k oder 512k Flash einsetzt. Und jeder Nachbauer macht seine eigene Platine? > Ob es im Auto nicht ohnehin ratsam ist, ein Layout als 4-Layer zu machen > und die Außenseiten hauptsächlich für Masse und Power zu nehmen ist eine > andere Diskussion. Man kann durch Beachtung von Abständen auch bei > 2-Lagen Audio- und Datenbusse gut nebeneinander führen. Kostet halt ein > paar Ferrite mehr. Aus kostengründen, gerade für Prototypen und weil die Platine so groß ist, würde ich stark für 2 Layer plädieren. Das ist auch machbar. Das entstören ist erfahrungsgemäß auch in den Griff zu kriegen. > Wir haben bei einem PKW-Radio nicht das Problem, dass da zu viele Käfer > auf der Platine sitzen, sondern dass es einiges an Entstörmaßnahmen > erfordert. Das sind Äpfel mit Birnen verglichen. Die Käfer STÖREN nicht unbedingt, aber sie machen das Layout komplizierter. > Wenn der Chip USB ab Haus unterstützt, ist die dafür notwendige Fläche > minimal. Das tun ja mittlerweile die meisten. > Ein Power-Controller für die +5V, zwei Induktivitäten und 3 > Widerstände. Das passt auf 10x5mm. Es führt kein Weg an 0603 und 0402 > SMD vorbei, nur um das gleich fest zu stellen. Ich sehe jetzt nicht warum 0402 für ein Schaltnetzteil nötig sein sollten (bzw. warum es so klein sein muss), HF geeignete Schaltnetzteile sind auch schon mit größeren Bauformen realisiert worden. Es gibt übrigens auch seit Jahren integrierte 4 Kanal Verstärker mit integrierten Spannungswandlern für genau diese Applikationen...
Hallo, Kai G. schrieb: > Mathias A. schrieb: >> Auf die Tunerplatine dann nur einen kleinen Controller setzen, der z.B. >> die RDS-Dekodierung, Abfragen von Tasten/Drehgebern etc. übernimmt. Das >> hätte auch den Vorteil, diese (zeitkritischen) Steuerungsaufgaben von >> dem Controller der die Signalverarbeitung macht abzukoppeln (Olaf hatte >> ja auch bereits angesprochen, dass das eine Herausforderung werden >> könnte). > > RDS braucht -wenn man es gut machen will- relativ viel Speicher. Das > Basisfeature follow me (beste Frequenz finden) an sich ist schon echt > nicht ohne und nicht schnell nebenbei am Schreibtisch designed. > Ein AtMega dürfte da aufgrund des geringen RAMs überfordert sein. Wenn > man Frequency diversity zur Empfangsverbesserung einsetzen will braucht > man sogar noch deutlich mehr Ressourcen. hmm ok ein ATmega ist also vielleicht wirklich etwas klein. Aber so eine "Monster-CPU" die es schafft nebenbei noch MP3 zu dekodieren dürfte doch vermutlich auch hoffnungslos überdimensioniert sein (wohlgemerkt wenn es wirklich nur um die Steuerung des Tuners geht). Was heißt eigentlich "relativ viel Speicher" - schätze mal dass einige kB ausreichen dürften, oder? Christian H. schrieb: > Wie sieht es denn aus? Ist MP3 (und Konsorten; ich spreche im Folgenden > der einfachheit halber von MP3) wirklich für jeden ein Muss? also für mich wäre es das nicht, d.h. ich persönlich würde das gerne aus dem Basissystem raushalten. Ich hoffe nämlich (falls es denn dazu kommen sollte dass es zustandekommt ;) ) das Radio über Jahre zu verwenden, und wer weiß was da an Codecs und Speichermedien noch so alles kommt... Könnte mir daher (für mich!) auch vorstellen ein Handy, iPod o.ä. als Zuspieler zu verwenden, der dem Radio direkt Audiosignale liefert, sei es per Kabel (Autohalterung) oder per Bluetooth (A2DP). Entsprechende Adapter gibts ja auch schon fertig. Nett wäre dabei eine Fernsteuermöglichkeit (z.B. per AVRCP). Das eigentliche Radio müsste dafür nur einen Line-In haben; die Fernsteuerung kann ja direkt ans Bedienteil gekoppelt werden. Im Prinzip hätte ich nichts gegen eine "viel zu große" CPU, wenn sie a) mit Hausmitteln lötbar b) vom Layout her noch beherrschbar ohne zig Prototypen anfertigen zu müssen bis alle Entstörungen usw. passen c) gut verfügbar und möglichst mit freien Mitteln programmierbar ist. Der Preis der CPU wäre mir nicht so wichtig, die o.g. 15-20 € für den Renesas wären jedenfalls noch ok; zumindest Punkt a+b scheint er mir aber nicht so ganz zu erfüllen...(oder?) > Ich bin da eher für Modularisierung. > > 1. Ein kleines Board, welches nur das Radio beinhaltet und per RS232 > komplett fernbedienbar ist. > 2. Ein zweites Board, welches die Audio-Verarbeitung (Filter, MP3, ...) > macht. > 3. Ein drittes Board, welches die Nutzerschnittstellen behandelt. Dies > kann dann auch ein großer, fetter Prozessor mit Linux, Amiga-OS oder CPM > sein. hört sich für mich gut an. Wobei man evtl auch 2 und 3 noch zu einem Teil zusammenfassen könnte. > >> Außerdem kann man sich recht schnell auf die eigentliche Sache, das >> Radio, konzentrieren. >> >> Also, nicht übel nehmen, ich kann nachvollziehen, dass man das ganze in >> einer schnellen großen CPU verarbeiten möchte. Aber ich fürchte, dass >> die Nachbaubarkeit und die Verstehbarkeit darunter leidet und der Zugang >> zu den Innereien des OSCARs nur wenigen vorbehalten bleibt. Aber je >> weniger dabei von Anfang an mitmachen, desto schnell verläuft das ganze >> auch im Sande. sehe ich auch so... Mathias
> hmm ok ein ATmega ist also vielleicht wirklich etwas klein. Aber so eine > "Monster-CPU" die es schafft nebenbei noch MP3 zu dekodieren dürfte doch > vermutlich auch hoffnungslos überdimensioniert sein (wohlgemerkt wenn es > wirklich nur um die Steuerung des Tuners geht). Was heißt eigentlich > "relativ viel Speicher" - schätze mal dass einige kB ausreichen dürften, > oder? So überschlagsmäßig würde ich sagen das ca. 32 KB für RDS + Frequency diversity genug sind.
Dann möchte ich nochmal meine Vorstellungen zusammenfassen. Das Mainboard sollte sich als reines Peripheriegerät mit klar definierten Schnittstellen zur Außenwelt präsentieren. Irgendwelche Codes haben m.M.n. auf dem Mainboard nichts verloren, da die Anforderungen (mp3,og,flac,wma....etc) viel zu unterschiedlich sind, und weitere Formate mit ziemlicher Sicherheit in Zukunft dazu kommen werden. Es wäre allerdings sinnvoll, einen I²S Eingang incl. D/A vorzusehen, um hier einen Zuspieler anzuschließen. Ein I2S-Ausgang zum Aufzeichen wäre sicher auch eine sinnvolle Option Auf diese Weise kann der gesamte Analog-Audio-Pfad auf dem Mainboard bleiben, und entsprechend gut vor externen Störungen bewahrt werden. Für die, die das Radio mit allen möglichen Codecs usw. aufmotzen wollen, sollte ein Steckplatz vorgesehen werden, auf den das (optionale) Multimedia-Modul aufgesetzt werden kann. Hier kann man einen grossen Prozessor mit Linux und allen möglichen Codecs unterbringen. Die Bedienlogik kann dann wahlweise im Bedienteil oder Multimedia-Board stecken. Natürlich sollten alle Radio-relevanten Dinge innerhalb der Mainboard-Cpu erledigt werden(Tuning, Diversity, RDS Audio-Regelung und Distribution). Harry
Harald L. schrieb: > Dann möchte ich nochmal meine Vorstellungen zusammenfassen. > Das Mainboard sollte sich als reines Peripheriegerät mit klar > definierten Schnittstellen zur Außenwelt präsentieren. Leute, wir drehen uns im Kreis!!!!!! Und landen im Endeffekt immer beim dem selben System das Harry hier auch umreißt. Ich hab noch niemanden gehört der einen anderen codec haben wollte und es spricht nichts dagegen MP3 im Radio selber zu implementieren. MP3/OGG/AAC/XYZ kann trotzdem auch noch mit Linux abgespielt werden. Den Haupt µC muss man sonst ziemlich leistungsstark wählen und dann ist noch die Frage ob überhaupt irgendwann mal jemand den gewünschten Codec für die gewählte Plattform implementiert (Portieren kann aufwändig werden wenn ASM Hilfsroutinen im codec sind). > Es wäre allerdings sinnvoll, einen I²S Eingang incl. D/A vorzusehen, um > hier einen Zuspieler anzuschließen. Ein I2S-Ausgang zum Aufzeichen wäre > sicher auch eine sinnvolle Option Klar, hatten wir ja schon vorgesehen. > Für die, die das Radio mit allen möglichen Codecs usw. aufmotzen wollen, > sollte ein Steckplatz vorgesehen werden, auf den das (optionale) > Multimedia-Modul aufgesetzt werden kann. > Hier kann man einen grossen Prozessor mit Linux und allen möglichen > Codecs unterbringen. Ja, genau!!! > Die Bedienlogik kann dann wahlweise im Bedienteil oder Multimedia-Board > stecken. Ja. Tastenpolling und co. lieber in einem kleinen µC der dann mittels interrupt/"Data available signal" an den Haupt-µC signalisiert das sich was getan hat. > Natürlich sollten alle Radio-relevanten Dinge innerhalb der > Mainboard-Cpu erledigt werden(Tuning, Diversity, RDS Audio-Regelung und > Distribution). Mein Reden! Kai
@Kai scheint ja, als würden wir uns doch noch einigen können ;) Also gut!...von mir aus ein mp3-Codec mit rein... Daran solls dann auch nicht scheitern! Harry
Na da sind wir ja doch wieder bei der dicken CPU beim Tuner. Bin dann mal weg.
So langsam scheint sich ja eine Einigung zu finden -- bzw. die Missverständnisse aufzuklären da ohnehin bisher schon jeder das selbe gemeint hatte? ;-) Kai G. schrieb: > So überschlagsmäßig würde ich sagen das ca. 32 KB für RDS + Frequency > diversity genug sind. danke, das ist ja schonmal ein guter Wert zur weiteren Planung. Kai G. schrieb: > Harald L. schrieb: >> Dann möchte ich nochmal meine Vorstellungen zusammenfassen. >> Das Mainboard sollte sich als reines Peripheriegerät mit klar >> definierten Schnittstellen zur Außenwelt präsentieren. > > Leute, wir drehen uns im Kreis!!!!!! Und landen im Endeffekt immer beim > dem selben System das Harry hier auch umreißt. > > Ich hab noch niemanden gehört der einen anderen codec haben wollte und > es spricht nichts dagegen MP3 im Radio selber zu implementieren. Aus Softwaresicht klar, man muss es ja nicht verwenden wenn man es nicht braucht. Insofern stimme ich Dir da zu. Dass ich bisher gegen MP3 im Hauptsystem war lag daran, dass ich den Eindruck hatte dass die dafür geplante CPU recht aufwändig und speziell ist was das Löten und die Entwicklungswerkzeuge angeht. Wenn ich z.B. die CPU auf dem Becker Cascade anschaue, also ich hätte schon etwas Respekt davor sowas von Hand zu löten...oder bin ich da die Ausnahme? Zumal wenn man diese CPU dann zu geschätzten 10% auslastet fragt sich schon ob es den ganzen Aufwand wert ist... Wenn nun aber dafür anscheinend auch etwas "hobby-freundlicheres" ;) ausreicht (so habe ich zumindest einige der neueren Posts verstanden, bitte korrigiert mich wenn ich falsch liege) habe ich auch kein Problem damit MP3 ins Mainboard zu integrieren. Mathias
Wenn ich das richtig sehe, bewegen wir uns jetzt wieder in der ARM7-Liga. Ist mir sehr sympatisch! Wir sollten dieses Design jetzt aber auch mal langsam festschreiben, sonst diskutieren wir nächstes Jahr noch Harry
> Ich verfolge diesen Thread schon eine Weile und bin verblüfft > wie hier im Handstreich eigene Meinungen durchgesetzt werden. Welche Meinung meinst du denn? Ich habe eigentlich gedacht das ich etwas (SH7262) zur Diskussion gestellt habe von dessen Eignung ich selber fuer dieses Project ueberzeugt bin. Aber natuerlich bin ich auch immer fuer Gegenvorschlaege offen solange sie begruendet werden. > Der Renesas mag technisch toll sein, aber das er hierzulande > kein Exot ist halte ich für eine ziemlich isolierte Meinung. Dieser Prozessor ist mir sicherheit ein Exot. Sowohl hier wie auch in Japan. Einfach deshalb weil er speziell fuer Audiogeraete enwickelt wurde und darum keine grosse Verbreitung haben kann. Und nun? > Sicher gibt es Leute die damit arbeiten, aber verglichen mit > ARM ist die Verfügbarkeit von Tools jeder Art recht bescheiden. Sowohl der Compiler von Renesas selber wie auch der gcc lassen sich problemlos kostenlos runterladen. Welches tool brauchst du sonst noch? Es gehoert mit zu den bemerksenwerten Besonderheiten dieses Prozessors das man eben nur ein USB-Kabel braucht um den brennen zu koennen und einen Debugger auf Assemblerlevel, C-sourcecode-Level mit Breakpoint, Watchpoints usw zu betreiben. Mit anderen Worten wirklich jeder kann das Teil benutzen. Man brauch eben keine extra Hardware zum brennen anzuschaffen. > Der SuperH ist eine der besten Lösungen wenn man mal von diversen ARMs > im BGA absieht. Außerdem der Olaf spielt schon mit dennen. Wer eine bessere Loesung kennt soll sie doch einfach mal nennen. Ich lese mir gerne das Datenblatt durch! > Ich würd ned immer alles über UART machen wollen es gibt ja auch noch > SPDIF usw. Eben, welcher ARM hat denn z.B SPDIF eingebaut? > Ja, ich bin auch immer noch für den/die SuperHs. Ich nutz zwar Linux, > aber programmieren tu ich meist unter Windows, insofern würde mich der > fehlende GCC nicht stören. Der gcc fehlt nicht. Ich habe den hier bei mir in der compilierten Version fuer Windows auf der Platte liegen! Es gibt nur keinen Grund ihn zu verwenden. Nur wenn man Code groesser als 256k erzeugt wird man das tun muessen. Ansonsten kann man zumindest vermuten das der Compiler von Renesas deutlich effizienter ist. Aber wer langeweilse hat darf gerne auch mal den gcc ausprobieren. > Wenn Arm und BGA wär ich eindeutig für den LPC2888 von NXP. Aber leider > nichtmal nur ein BGA, sondern sogar ein FBGA... Nicht nur BGA ist schlimm. Egal von welchem Hersteller der Prozessor letztlich ist, er sollte schon ohne externe Buszugriffe auskommen. > - Für einen Hobbyelektroniker mit beschränktem Werkzeugpool noch > lötbar; > kein BGA und QFN - Finepitch ist aber kein Problem (sollte halt > herausragende Pins haben, die man mit dem Lötkolben erfassen kann). Nicht nur das. BGA ist mit einer gewissen Wahrscheinlichkeit sogar noch loetbar, springen vielleicht mal 10% der Nachbauer ueber die Klippe. Aber wieviel Testboards mit 4 oder 6Lagen koennen wir uns leisten bis die Platine laeuft? Und wenn die Kiste dann noch externes Ram braucht, dann empfaengt Kais Empfaenger vermutlich in den ersten Versionen ausschliesslich den Ramzugriff und kein Radio. :-) > Optional: > - Gerne auch kostenlosen oder kostengünstigen Debugger. Ohne eine Moeglichkeit zu debuggen kannst du nicht vernuenftig arbeiten! Die Qualitaet des Renesas-Debuggers war fuer mich vor Jahren der Grund warum och von den AVRs weg gegangen bin. > Heißt frei denn das es der GCC sein muss? Eben! Mir reichen die Beschraenkungen des Renesas erstmal aus. Aber es gibt ja den gcc. Es ist also keine Sackgasse! > Zum Debugger: > Der Olaf hat einen Debugger, mit dem kann man sich sicher zusammen > reden. Mit mir oder dem Debugger? :-) Nochmal zur Erklaerung. Die Oberflaeche von Renesas (HEW) enthaelt einen Debugger. Der ist SEHR leistungsfaehig. Der laesst wirklich keine Wuensche offen. Dieser Debugger benoetigt eine Anbindung an den Controller. Dies kann ueber eine Hardware geschehen. Diese heisst z.B E8 (R8C/M16C), E8a (R32), E10(SuperH). Bei den kleinen Prozessoren (R8c/M16C) konnte die Anbindung aber auch ueber eine RS232 geschehen. Hat halt den Nachteil das dies eine der seriellen Schnittstellen gekostet hat. Beim SH7262 kann die Anbindung auch noch ueber USB2.0 geschehen. Ich habe damit jetzt ein paar Stunden rumgespielt und konnte keine Einschraenkung feststellen. Die einzige Einschraenkung die es gibt, solange USB fuers Debuggen genutzt wird kann man da offensichtlich keinen USB-Stick dran haengen. Fuer diese spezielle Anwendung waere ein E10 sicherlich schoen. Und den hat mir Renesas/Glyn netterweise geschenkt. Genauer gesagt der ist heute eingetroffen und steht jetzt hier auf den Schreibtisch. Und nochmal, sollte irgendjemand waerend der Programmierung wirklich den E10 brauchen dann verleihen wie den einfach untereinander. > Renesas spielt weltweit in den obersten Rängen der > Mikrocontroller-Firmen. Naja, in Bastlerkreisen sind sie sicher nicht so verbreitet. Ich verstehe zwar nicht ganz wieso, aber das ist ja erstmal unerheblich. Wichtig ist doch nur das man einen Prozessor nach bestimmten Kriterien aussucht und wenn ein Prozessor sie erfuellt dann nimmt man den. Mir fallen auch eine Menge Anwendungen ein wo ich den SH7262 niemals nehmen wuerde. In einer Firma waere zum Beispiel haeufig ein Problem das man seinen Code nicht vor auslesen schuetzen kann wenn er in einem exteren Flashrom ist. Aber da kann uns ja egal sein. > Man muss sagen das für den AVR, PIC oder vielleicht noch ARM User ein > gewahltiger Sprung ist wenn man auf zB die SuperH Serie umsteigt. Ich weiss nicht ob ich da zustimmen kann. Jedenfalls schwierig zu beantworten. Auf der einen Seite wenn man einen AVR in C programmiert hat dann programmiert man den SuperH genauso in C. Ich habe viel Programmcode den ich beliebig zwischen AVR, R8C, M16C, 68332 und Dragonball ohne Aenderungen hin und hergeschoben habe. Andererseits wenn man eher, wie soll man sagen provienziell(?) programmiert hat dann kann das stimmen. (z.B Intel/Motorola Reihenfolge der Bytes) Einige Dinge werden schwerer werden. Das Datenblatt ist nicht umsonst so dick, andere Sachen werden aber auch einfacher! Schwieriger wird es sicherlich wegen anderer notwendiger Konzepte weil im Hintergrund des Prozessor staendig Daten bewegt werden muessen. Da darf es niemals irgendwelche Probleme geben weil man die sofort als Knackser aus dem Lautsprecher hoert. Aber das liegt bei diesem Project in der Natur der Sache. > *kein offizieller GCC...etc Ich weiss nicht was Offiziell fuer dich ist. Reicht das nicht: http://de.wikipedia.org/wiki/T2_SDE http://www.t2-project.org/packages/gcc.html > sag mal Olaf!....arbeitest du bei Renases in der Marketing-Abteilung? Nein. Ich benutze nur M16C seit vielen Jahren privat weil ich sie gut fand und seid etwas weniger Jahren in der Firma und habe gute Erfahrungen gemacht. Sollte mich aber Renesas abwerben werde ich es euch wissen lassen. :-) Den hier angesprochenen Prozessor und ueberhaubt die SuperH Familie kenne ich noch garnicht! Wenn man mal davon absieht das ich auf einem Testboard eine LED habe blinken lassen und die Datenblaetter gelesen habe. Ich bin nur durch Zufall auf den SH7262 gestossen und fand ihn sehr interessant. Und wenn du ausser zu mosern einen besseren Prozessor aus dem Hut zaubern kannst dann koennen wir den auch gerne nehmen! Mir fallen auch andere Projecte ein die ich alleine mit dem SH7262 durchziehen kann. (Man ueberlege nur mal, SPDIF Eingang und Ausgang und viel Rechenleistung dazwischen. Da faellt mir doch als erstes ein Sampleratenwandler fuer meine DATs mit integrierten AD-DA Teil, Lautstaerkeanpassung, Expander/Kompander usw ein) > ich würde eher eine CPU wählen, die vieleicht auch GeneralPurpose'd > besser aufgestellt ist, (wäre dann universeller), Was versprichst du dir davon? Glaubst du wirklich es werden jemals mehr als 10-20Radios gebaut? Es ist ja nicht so das wir den als Firma mit 10Jahren garantierter Produktlaufzeit einsetzen. Da haette ich dann auch bedenken. > Da würd ich mir den RX noch ansehen . Das Problem das ich mit dem RX haette ist das die halt noch sehr neu sind. Da wuerde ich Probleme mit irgenwelchen Bugs im Prozessor geradezu erwarten. Ausserdem, jedesmal wenn man etwas spezielles aus dem SH7262 bei einem anderen Prozessor durch externe Hardware ersetzen muss dann steigt das Risiko. Ueberleg mal, hier waren doch sogar Leute die wollten einen FPGA einbauen. Also geradezu die Garantie das man so ein Teil nach kurzer Zeit nicht mehr bekommt. > Wenn es nach mir ging würd ich am Liebsten einen ARM Cortex A5 > verwenden, leider ist der noch nirgends zu bekommen Mal abgesehen davon das mein einen Prozessor den man nicht kaufen kann offensichtlich nicht verwenden kann. WARUM bitte soll man einen bestimmten ARM nehmen? Was kann er was ein anderer Prozessor nicht kann, das aber fuer dieses Project wichtig waer? Ich habe manchmal den Eindruck das manche Leute hier bloss das essen wollen was sie schon immer gegessen haben und ihnen der Brei anderer Leute Angst macht weil er die falsche Farbe haben koennte. Soll ich genauso denken? Ich habe noch nie etwas mit ARM gemacht. Sind die deshalb automatisch schlecht? > Wozu überhaupt so eine "fette CPU" auf dem Mainboard? Weil die Alternative ein Autoradio auf dem Level von 1985 ist. Das bekommt man mit einem R8C (oder Mega8) hin der alles ueber I2C steuert. Ich hoffe es macht dir dann nichts aus wieder Musik ueber Kassette zu hoeren. :-) > Und nochmal: der Renases ist alles andere als offen, solange Renases > selbst der einzige Lieferant von Software ist. Sag mal, leidest du unter Paranoia? Glaubst du Renesas loescht dir nachts deine Platte oder so? Ausserdem STIMMT DAS NICHT. Read my lips, es gibt einen gcc! > Selbstbauprojekte mit den Dingern findet man im Netz auch so gut wie > nicht. Weisst du, wenn der Selbstbau bei einem Prozessor darin besteht die Betriebspannung anzulegen dann ist das erstmal nicht so die Herausforderung. > Wir wären also echte Pioniere, und auf uns selbst gestellt. Was denn? Weil du einen neuen Prozessor aus dem fernen boesen Japan kennenlernen musst? Manchmal frag ich mich wie die Wikinger Amerika entdeckt haben oder warum unserer Vorfahren das Feuer kultiviert haben. Und das so ganz ohne Internet.... > Och Leute, seid doch nett zueinander. Geht raus, tankt ein bißchen > Sonnenstrahlen (=Glückshormone) und kommt zurück ;-) Grillen war gestern. Heute ist ernst. :-) [ploep] <---Das war ein Flens! > Wow, das ist schon mächtig. Normalerweise sollten für mittlere Lasten > auch 100n und 10n parallel reichen Ich vermute mal das war eher Angst beim Entwickler. Wichtiger als die Kapazitaet ist IMHO die Baugroesse. > Generell sollten alle keramischen im Auto >100°C abkönnen. Was den Punkt angeht macht mir das Display die meisten Sorgen. > Außerdem ist X7R bei vielen Bestückern vorrätig. Bestueckern? Ich dachte bei diesem Project ist es eher wichtiger was bei Reichel vorraetig ist. :-) BTW: Ich hab noch ein Reel mit 100nF rumliegen. Ich koennte euch sponsern. Und die sind auch nicht von Renesas. :) Loesung1: > Der 'äußere' Controller steuert > dann das Bedieninterface, andere Komponenten des Radios > und übernimmt wenn er üppig dimensioniert ist evtl. > auch gleich die MP3-Dekodierung. Wo bekommt dein aeusser Controller seine Daten her. Ich haette doch gerne die SD-Karte im Radio stecken. Willst du alles zweimal hin und herschubsen? > 2) Dann gibt es die Variante wo der Controller den Tuner > steuert und gleichzeitig die MP3-Funktionen und warscheinlich > auch noch die Signalverarbeitung (Klangregelung usw.) Das wird von mir favorisiert. Das ist StateOftheArt. Ausserdem wuerde da zumindest fuer mich der Spass drin liegen. Man koennte sozusagen mal wieder das was man im NT-Studium gelernt hat zur Anwendung bringen. Loesung 1 ist fuer mich langweiliger Alltagskram. Das habe ich jeden Tag in der Firma. Warum sollte ich mir das auch noch privat geben? > Ich finde der Tuner sollte nicht nur die Daten durchschicken, sondern > auch dekodieren und interpretieren. Dann ist etwas größeres als ein > Atmega schon hilfreich. Nicht nur hilfreich. Warum soll man wegen ein paar Euro mehr sich irgendwelche Zwaenge auferlegen. Wir arbeiten doch nicht bei Blaupunkt wo jeder gesparte Euro bei grossen Stueckzahlen wichtig ist. > nein, ich nehme auch andere, für die ich nichts bezahlen muss. > Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch > unter Mac OS-X) verwenden kann. Seufz! Und nochmal. Es gibt einen GCC und es gibt ihn im Source. Und der SH7262 ist im Gegensatz zu anderen Prozessoren sogar besonders frei. Sein Programm befindet sich naemlich in einem externen SPI-Flash das du immer brennen kannst. Aber all das ist fuer so ein Project UNWICHTIG! Es geht hier um die Zusammenarbeit von hoffentlich vielen Leuten. Es ist notwendig das die dann dieselbe Programmierplatform nutzen. Und damit ist es sehr wahrscheinlich das nicht unter Linux entwickelt wird. > <ironie>und noch Amiga-OS (ab Kickstart/Workbench 1.4) und CPM</ironie> Und PalmOS! Ich mag PalmOS....also das bitte auchnoch. :-) <ironie> Manchmal warte ich darauf das in der naechsten News hier einer unbedingt den 6502 als Steuerprozessor haben will weil er den ersten Sex mit der Zeropage hatte und das so romantisch war. </off> > Allerdings besteht bei den Nicht-O/S Toolchains immer die Gefahr, dass > sie limitiert ist ( nur xxkB Code), dass sie mit der Plattform stirbt, > wenn die Nachfrage nicht hoch genug ist oder dass sie nicht auf allen > Plattformen einsetzbar ist. Renesas ist mittlerweile der weltgroesste IC-Hersteller. Bevor die zumachen hat AVR lange ausgeschissen^W aeh..sind nicht mehr... :-D > Wenn GCC läuft, dann kann ich meinen Source-Insight einsetzen und ein > anderer Eclipse. Sicher, und ich setze dann Makefiles ein. Sagt mal, noch ganz wach? Es kann doch nicht jeder was anderes einsetzen. wie soll da eine Zusammenarbeit erfolgen? > Daher fehlt es an vielen Dingen, die alle erst einmal neu > gemacht werden müssten. Nicht lamentieren! Sag doch einfach mal was genau dir fehlt! > Man kann sich das ein oder andere Aus den > AppNotes von Renesas zusammen bauen, aber ein eigenes System mit > TaskSwitching aufzusetzen, heißt wirklich ganz unten anfangen. Das wuerde ich auch nicht haben wollen. Ich bin mir fuer ein Event-gesteuertes System mit IRQs fuer die schnellen Dinge im Hintergrund. > Außerdem kann es sein, dass außer uns keiner das Teil kauft, also > stampft NXP das Teil wieder ein, Das Risiko halte ich fuer relativ gering und tolerabel. Es wird schliesslich nie eine grosse Produktion sondern nur wenige Teile geben. Da kann man sich die paar Teile doch wohl besorgen. > Ist ja schön das wir jetzt ein Betriebssystem haben (auch wenn ich den > ganzen Ethernet kram lieber draussen sehen wollte), aber das war doch > erstmal nicht das kernproblem, oder? Ich bin gegen die Verwendung eines Betriebssystems. Das kostet nur unoetig Rechenzeit und macht das Zeitverhalten sagen wir mal arbeitsintensiv. Und es bringt keinen Vorteil solange ein Betriebsystem nicht das macht fuer das es erfunden wurde, naemlich unterschiedliche Anwendungen zu starten. [MP3] > Also für mich definitiv 100%ig! DAs sehe ich auch so. MP3 ist durchgesetzer Standard. Entweder das geht oder die Sache ist gestorben. Sonst kann mir doch gleich wie meine altes Kasettenradio einbauen. > OGG und co. brauche ich nicht, wäre für mich also nicht 100% > erforderlich. Weiss nicht wie es bei anderen aussieht. Noe, brauch ich auch nicht. Aber wenn das per Software gemacht wird kann es doch jemand fuer den das wichtig ist einfach programmieren. [Amazon] > Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, > probiere ich es sofort aus ;) Ich glaub das mit dem link reinkopieren klappt hier nicht. Dabei werden irgenwelche Zeichen zerstoert. Geh einfach mal nach Amazon-Japan und Tipp das "Interface" ein. Gleich der erste Treffer ist die Ausgabe 6/2010 fuer 2310Yen. BTW: Die haben echt japanische Zeichen in der URL. Wusste garnicht das dies geht. > Wie teuer ist es (Versandkosten) und WIE um Himmels willen hast Du den > Weg durch den Bestellvorgang gefunden? Das koennte in der Tat interessant sein. :-D Noch was fuer die eventuell anderen Besteller.... Man benoetig zur Benutzung noch einen Treiber den man kostenlos auf der Homepage der Zeitschrift runterladen kann. Dazu muss man sich aber auf dieser Homepage registrieren: http://cc.cqpub.co.jp/system/document/keyword=IF201006SH2A http://www.kumikomi.net/interface/editors/2010/04/sh-2a_1.php Zur Registrierung ist es unbedingt erforderlich das man die Aussprache seines Namens in Hiragana/Katakana angibt. Und es reicht auch nicht wenn man da irgendwelche Japanische Zeichen von woanders reinkopiert. <seufz> Ich hatte aber vor diese Files zur Verfuegung zu stellen und habe auch eine Installationsanleitung in Deutsch geschrieben.... Notfalls mir also eine Mail schicken. > Die Versandkosten 3700Yen ~ 33 Euro Aechz! > ...Hab auch schon z.B. ein komplettes Filesystem für einen AT90S1200 > (hat KEIN RAM!!!) programmiert, FAT12/16/32 support, natürlich in > assembler, read only, long filename support, directory lesen, ... Aber > schön, transparent und übersichtlich ist halt anders. Du arme Sau. :-) Wie hast du das den in das Flashrom der ollen Kiste bekommen? Olaf p.s: War die Laenge der News jetzt neuer Record? Sorry, war gestern den ganzen Tag mit dem Motorad unterwegs und danach grillen. Deshalb heute der Rundumschlag weil es soviele neue News gab.
@Olaf Ok!....es gibt also eine freie Toolchain, und ich hab auch verstanden, daß ich meinen Code via Bootloader in den Chip bekomm; -soweit so gut- Wie debug ich das dann, wenn ich keinen (teuren) E10 hab? (wobei die Debug/Trace-Funktion ja extra kostet, wenn ich die Webseite richtig interprettier) Den Einsatz von GCC/GDB betrachte ich bei einem OpenSource-Projekt als obligatorisch – ganz egal, wie toll der Debugger von Renasis ist! Der andere Punkt: was genau möchtest du denn in der Audio-Signalverarbeitung durch diesen Prozessor gewinnen? Wenn ich das richtig seh, müsste man doch bei einer echten digitalen Signalverarbeitung bereits die ZF digitalisieren, und das Signal per Software demodulieren. Da kann ich mir auch echte Vorteile vorstellen, nur überschreitet das den Horizont meiner (derzeitigen) Fähigkeiten. (und wohl auch den der meisten anderen hier) Außerdem – wenn du anprangerst, daß unser Konzept ein Autoradio der 80er beschreibt, muss ich dich wohl mal daran erinnern, daß der analoge Rundfunk in seiner jetzigen Form deutlich älter ist. Wenn ich die Beschreibung des Tuner-Chip richtig verstanden habe, erledigt der doch bereits den Signal-verarbeitungs/-verbesserungs-Teil....das dekodieren der RDS-Daten sowieso....“so what?“ Wozu brauch ich jetzt unbedingt die tollen Audio-Features des SH?....der wichtigste Teil unserer Signalverarbeitung bei dem Radio ist nunmal analog. Harry
Ach ja....und noch etwas: es wird einen digitalen Ein- und Ausgang in Form einer I²S-Schnittstelle zum Multimedia-Modul geben. Was hindert dich daran, einen SH auf den Erweiterungsslot zu stecken? Harry
@darkover wenn ich was lesen will geh ich in eine Bibliothek Naja ich wär auch für einen SuperH. Wenn man schon digital arbeitet dann gscheid. MFg
Olaf Kaluza schrieb: > Nochmal zur Erklaerung. Die Oberflaeche von Renesas (HEW) enthaelt > einen Debugger. Der ist SEHR leistungsfaehig. Der laesst wirklich > keine Wuensche offen. > > Dieser Debugger benoetigt eine Anbindung an den Controller. Dies kann > ueber eine Hardware geschehen. Diese heisst z.B E8 (R8C/M16C), E8a > (R32), E10(SuperH). > Bei den kleinen Prozessoren (R8c/M16C) konnte die Anbindung aber auch > ueber eine RS232 geschehen. Hat halt den Nachteil das dies eine der > seriellen Schnittstellen gekostet hat. > Beim SH7262 kann die Anbindung auch noch ueber USB2.0 geschehen. Ich > habe damit jetzt ein paar Stunden rumgespielt und konnte keine > Einschraenkung feststellen. Damit ich das jetzt auch verstehe: Bedeutet das, der SH7262 kann komplett über USB2.0 debuggt werden? Ich brauche also nicht zwingend einen E10? >> nein, ich nehme auch andere, für die ich nichts bezahlen muss. >> Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch >> unter Mac OS-X) verwenden kann. > > Seufz! Und nochmal. Es gibt einen GCC und es gibt ihn im Source. Und > der SH7262 ist im Gegensatz zu anderen Prozessoren sogar besonders > frei. Sein Programm befindet sich naemlich in einem externen SPI-Flash > das du immer brennen kannst. Ja, danke, das habe ich auch bereits erfahren. Außerdem ging es bei meiner Bemerkung nicht um den SH7262, sondern allgemein. Mir bringt kein Prozessor etwas, den ich nur mit teurer Hard- und Software programmieren kann (auch das ist allgemein zu verstehen). > Aber all das ist fuer so ein Project UNWICHTIG! Es geht hier um die > Zusammenarbeit von hoffentlich vielen Leuten. Für dieses Projekt ja. Ich schneide mir aber gerne ein Stück von dem Kuchen ab und esse es woanders auf. Sprich, ich würde den Prozessor, wenn ich ihn schon kennengelernt habe, eventuell auch für etwas anderes einsetzen wollen. Dann setze ich vielleicht lieber eine andere Programmierplattform ein. Der Prozessor (oder zumindest die Famile) muss auch das hergeben. > Es ist notwendig das die > dann dieselbe Programmierplatform nutzen. Und damit ist es sehr > wahrscheinlich das nicht unter Linux entwickelt wird. Da ich unter Windows nur arbeite (beruflich, bin Admin) und privat nur spiele, bin ich dann wohl raus. Es kommt aber auf das Projekt drauf an - ist es interessant genug, wäre ich auch bereit, eine Programmierumgebung als VM aufzusetzen. Lieber ist es mir aber, wenn ich unter Linux arbeiten kann - da fühle ich mich zuhause, denn damit bin ich groß geworden. PS: Ich bin trotzdem immer noch der Meinung, nicht alles in einen großen Prozessor zu stecken. Ich wäre mit dem VS1053 zufrieden; gerne auch als optionales Modul.
Christian H. schrieb: > Da ich unter Windows nur arbeite (beruflich, bin Admin) und privat nur > spiele, bin ich dann wohl raus. Es kommt aber auf das Projekt drauf an - > ist es interessant genug, wäre ich auch bereit, eine Programmierumgebung > als VM aufzusetzen. Lieber ist es mir aber, wenn ich unter Linux > arbeiten kann - da fühle ich mich zuhause, denn damit bin ich groß > geworden. Ich seh GCC/GDB als obligatorisch an, und da es sich um Open-Source handelt, geht auch die komplette Entwicklung unter Linux! Ich verwende ebenfalls ausschließlich Linux, und der kleinste gemeinsame Nenner ist da GCC&Co. > > PS: Ich bin trotzdem immer noch der Meinung, nicht alles in einen großen > Prozessor zu stecken. Ich wäre mit dem VS1053 zufrieden; gerne auch als > optionales Modul. Seh ich genauso....für die mp3-only-Fraktion könnte der als lowcost-Lösung auf dem Multimedia-Port stecken. Harry
Mit GeneralPurpose'd hatte gemeint, dass man mit RX evtl mehr machen kann, ausserdem hat der JETZT SCHON Flash bis zu 100MHz !, max 2MB (und zukünft sogar bis 200MHz!!!, 4MB) (bei zB STM32 kannste das vergessen!!!!, der ist 5..6x langsamer!!) Mit GeneralPurpose'd wars auch so gemeint, dass sich der Einarbeitungs-aufwand in den RX M-E-H-R rentiert, eben weil auch später noch für andere Proj gut benutzbar. (Man wird wohl nicht einen SH-Audio-Proz für allgem. Aufgaben wählen) Das RX ist zwar rel neu, aber die Chips wurden bereits seit 2 Jahren getestet, Fehler sind da eher nicht zu erwarten. CPU-Error schon gar nicht. Die Dinger werden ja schon zuhaufe verkauft. Ausserdem: der SH7262 ist AUCH neu, im Catalog von 2009 stand er noch als "Under Development". (gebe allerdings zu, dass der RX (momentan) kein I2S hat , ist aber rel. wenig Aufwand das mit PLD/FPGA zu machen (dann könnte man sogar den Durchsatz im Vergleich zur eingebauten I2S im SH steigern, und wenn nötig auch die Anzahl der Kanäle erhöhen, und wenn nötig sogar ein spez. Audio-Protokoll machen, und wäre so viel flexibler)) ...und hätte halt eine sehr gute GP'd CPU
Harald L. schrieb: > Seh ich genauso....für die mp3-only-Fraktion könnte der als > lowcost-Lösung auf dem Multimedia-Port stecken. Anmerkung: die anderen stecken einen Linux-Rechner auf den Multimedia-Port, und dekodieren mp3 & co eben per Software Harry
Harald L. schrieb: > Den Einsatz von GCC/GDB betrachte ich bei einem OpenSource-Projekt als > obligatorisch – ganz egal, wie toll der Debugger von Renasis ist! Ack > Der andere Punkt: was genau möchtest du denn in der > Audio-Signalverarbeitung durch diesen Prozessor gewinnen? Das möchte ich auch mal erklärt bekommen. > Wenn ich das > richtig seh, müsste man doch bei einer echten digitalen > Signalverarbeitung bereits die ZF digitalisieren, und das Signal per > Software demodulieren. Da kann ich mir auch echte Vorteile vorstellen, Sorry, ich sehe hier gerade keine Vorteile, außer dass die Geschichte in Software abgeglichen wird und nicht mehr über Trimmkonndensatoren und Spulen. > nur überschreitet das den Horizont meiner (derzeitigen) Fähigkeiten. > (und wohl auch den der meisten anderen hier) Zu diesen gehöre ich auch, lerne aber gerne dazu. > Außerdem – wenn du anprangerst, daß unser Konzept ein Autoradio der 80er > beschreibt Hmm, dies soll doch ein Radio werden, oder? Gut, eines, was Features bietet, welche nur von teuren und vergoldeten High-Dollar-Modellen geboten werden. Trotzdem bleibt es ein Autoradio. Mir reicht mein Radio eigentlich aus. Abgesehen von einigen Features, die komplett fehlen (eine Senderdurchstimmung über Drehregler vermisse ich schon seit Ewigkeiten). Wenn ich mich diesem Projekt anschließe, möchte ich ein Radio, welches mir das Radiohören noch besser gestalten lässt. 1. Weniger Störungen -> Diversity 2. Auf welcher Frequenz ist mein aktueller Sender besser zu empfangen? Wenn möglich, automatisch wechseln. 3. Auch wenn ich gerade einen Sender ohne Verkehrsfunk höre, wäre es gut, wenn das Radio die stärksten Nachbarsender kennt und im Bedarfsfall meinen Sender kurz unterbricht (spontane Idee: Time-Shift für Radio-Hörspiele). 4. RDS (TMC) 5. MP3-Karte anstatt Kassette oder CD-Player: gerne 6. Auch hilfreich: Aufzeichnung aller Verkehrsfunkmeldungen, die das Gerät habhaft werden kann. Abspielen auf Knopfdruck mit Navigation zwischen den Aufzeichnungen (zum Beispiel auch eine Meldung einfach nochmal hören, da während der Nennung der Autobahnnummer mein Sohn lauthals los geschrien hat). DVD/Video/Schlagzeug/Kaffeemaschine: Nein, danke.
Frage: wer weiss etwas über "Standalone AD/DA Wandler mit I²S Schnittstelle" ??? Wenn wir die hätten, wären wir wieder beim guten, alten 8bit-AVR....was ich nicht für die schlechteste Lösung halte! Harry
Christian H. schrieb: > Wenn ich mich diesem Projekt anschließe, möchte ich ein Radio, welches > mir das Radiohören noch besser gestalten lässt. > > > DVD/Video/Schlagzeug/Kaffeemaschine: Nein, danke. in allen Punkten: FULL ACK!!!! Harry
Ich werd jetzt einfach Jura oder Medizin studieren und die Technik hinter mir lassen. Es geht nimmer .
Patrick Weinberger schrieb: > Ich werd jetzt einfach Jura oder Medizin studieren und die Technik > hinter mir lassen. > Es geht nimmer . ahja....beruhigt mich, daß deine Argumentation nichts mit unserem Projekt zu tun hat :D Harry
Naja das mit dem im Kreis drehen geht mir auch schön langsam auf die nerven
Patrick Weinberger schrieb: > Naja das mit dem im Kreis drehen geht mir auch schön langsam auf die > nerven ACK aber ein SH muss es nun wirklich nicht sein ;) HArry
Nein von mir aus kanns auch ein 8051er sein. Aber es geht eher darum wie es jetzt mit den Modulen ist. Alle wollen was ähnliches aber jeder einen anderen Controller oder ....
Ich plädier dafür, das ganze "as simple as possible" zu machen. Über den angestrebten Mulitimedia-Slot kann jeder dann treiben was er/sie möchte. Wichtig ist mir, daß dabei am Ende ein wirklich tolles Radio rauskommt. Daß es auf dem Weg dorthin unterschiedliche Meinungen, und auch Konflikte gibt, ist völlig normal. Nur die Open-Source-Projekte, die das aushalten haben eine Chance, irgendwann etwas benutzbares hervor zu bringen. Das bei so einem (nicht gerade simplen Projekt) eine ausführliche/kontroverse Diskussion entsteht, nützt dem Projekt, und schadet ihm nicht! Wir sollten allerdings langsam mal einen Endpunkt finden, und die Features festschreiben. Harry
Aber noch schlimmer sind die immer sagen ich will das und das. Dann will aber niemand was dafür machen. Hab das beim letzten Projekt gehabt wo ich ein paar Mitschüler unterstützt hab. Zum Schluss soll man alles machen wenn man es ned macht, dann jammern sie dahin und werden beleidigend. Mfg Patrick
Patrick Weinberger schrieb: > Aber noch schlimmer sind die immer sagen ich will das und das. Dann will > aber niemand was dafür machen. > Hab das beim letzten Projekt gehabt wo ich ein paar Mitschüler > unterstützt hab. Zum Schluss soll man alles machen wenn man es ned > macht, dann jammern sie dahin und werden beleidigend. > > Mfg Patrick Wart mal ab!...es gibt immer die, die rummeckern, aber sonst nix beitragen...lass die mal machen!....lass dich nicht frustrieren!....im Lauf des Projekt zeigt sich dann ganz klar, wer ernsthaft an dem Radio interessiert ist. Du scheinst mir recht jung zu sein..lerne Geduld! ;) ;) lieben Gruss! Harry
Harald L. schrieb: > Frage: > wer weiss etwas über "Standalone AD/DA Wandler mit I²S Schnittstelle" > ??? > Wenn wir die hätten, wären wir wieder beim guten, alten 8bit-AVR....was > ich nicht für die schlechteste Lösung halte! Ahhhhhhhhhhhhhhhhh!!!!!!!!! Zum Thema RDS hab ich schon was geschrieben, oder? Und zu freq. diversity?!? Oh man, da schläft man mal ein paar stündchen und schwups... 17 neue Nachrichten... und man ist quasi wieder am Anfang angelangt :-( Wir können auch ein Intel 4040 einsetzen. Also auf minimum Arm7 werden wir uns doch einigen können, oder? Damit sollte doch keiner Probleme haben.
Ist ja ein feines Projekt! Ich bin auch an einem qualitativ ansprechendem Radioempfänger für's Auto interessiert. Jedoch hab auf die schnelle noch keinen Anbieter für TEF6616 gefunden... "Sollte recht preisgünstig sein " ist im Wiki zu lesen. Doch bevor ich keinen Lieferant und keinen Preis für ein Bauteil habe, beginne ich persönlich nicht, dieses ernsthaft in ein Projekt zu integrieren. Hab ich mich da nicht genug umgesehen? Weis da jemand mehr? LG Gabriel
Hallo, Wollte auch mal kurz mein Interesse an diesem Radio kundtun. Habe mir schon mehr Gedanken über ein eigenes Projekt gemacht, aber wegen fehlendem Elektronikwissen (und Zeit) bis jetzt verschoben. Meine Anforderungen: - Dual RDS Tuner (Followme oder wie heisst das ?). Damit ich meinen Lieblingssender hören kann. Höre sowieso immer denselben Sender... - 16GB oder besser 32GB SD Kartenanbindung für meine Musiksammlung Wichtig für mich, OGG oder Flac Codec, und nicht nur MP3. Bitte jetzt keine Diskussion über MP3 Qualität ;-) Meine Idee wäre gewesen, ein Board mit einem Cortex-M3, einem VLSI VS1053 für MP3 (und OGG !!), und einem qualitativ guten RDS Tuner zu nehmen. Dazu ein SD-Slot, ein Display und ein paar Knöpfe. Ein grosser Teil des Codes (ohne RDS Anbindung) wäre bereits vorhanden siehe (http://www.watterott.net/projects/webradio-arm). Leider kann ich aus beruflichen Gründen nicht allzuviel mithelfen. Wäre aber sicher bereit in der einen oder anderen Form einen Obolus zu leisten, wenn ich dafür eine Hardwarplattform bekäme. Gruss Daniel
hab hier mal ein paar interessante CODECs: TLV320AIC3254 Very Low-Power Stereo Audio CODEC with miniDSP and Power TuneTM Technology 6 analIns (+MIC) / 4 analOuts (-6..+29dB Gain (step 1dB)) "with miniDSP" also auch Klangregel usw machbar ..sehr hohe Integration [zw. ADC-DAC ist kein I2S(oder sonst) nötig] PCM3168A : 24-bit Multi-channel Audio CODEC 6ch-in/8ch-out with 96/192kHz sampling rate (kein miniDSP) (Outs haben 0 dB to –100 dB in 0.5-dB steps) [zw. ADC-DAC ist I2S(oder sonst) nötig] AD1937: Four ADCs/Eight DACs with PLL, 192 kHz, 24-Bit Codec (Outs haben ATT mit 255 steps a 0,375dB)) (bzw AD1936..39) [zw. ADC-DAC ist I2S(oder sonst) nötig] bei National gibts unter LM49xx auch einige, aber sind glaub nicht so hoch integriert und haben meist ClassD-Output (!) [zw. ADC-DAC ist kein I2S(oder sonst) nötig] weiter gibts von AD noch SigmaDSP, hat mit SigmaStudio graph. Oberflache zum generieren des Audio-Verhaltens , ohne ASM oder C. die SigmaDSPs könnte man als extrem hoch integrierte Codecs ansehen (weiss aber nicht ob SigmaStudio gratis, die SigmaDSPs sind nicht so teuer, haben aber wahrsch. BGA-Geh.(!)) [zw. ADC-DAC ist kein I2S(oder sonst) nötig]
Es gibt auch noch die C54/C55xx Serie von TI die das gleiche kann und trotzdem TQFP haben oder Blackfin, ADS21xx usw Man kann aber auch gleich eine FPGA oder so nehmen....
So viel Text... Wow! Ok, nur um mal einem Missverständnis vor zu beugen. Ich möchte nicht das ganze Radio auf einem ATmega8 laufen lassen, ich wollte nur darstellen, was auf einem kleinen Proz schon möglich ist. Natürlich macht es, allein vom Preis her, keinen Sinn solch einen kleinen Zwerg zu nehmen. Ich dachte eher an einen STM32F103RE. 512kB Flash, 64kB RAM. Das sollte genug sein, um Playlisten, RDS, TMC und weiteres zu verarbeiten. Die Becker Cascade Plattform (Richtig geraten, Kai) macht das alles ebenfalls und hat deutlich weniger RAM und Flash. Das Verlöten eines 64-Pinner ist von Hand kein Problem, und ebenso ist es von Hand kein Problem 0402er Kondensatoren zu verlöten. Ob es 0402er sein müssen oder 0603er reichen, wird das Layout zeigen. Ich bin aber sehr unglücklich mit der Lösung, jede Funktion auf eine Aufsteckplatine zu verbannen. Diese müssten entweder als Sandwich gestapelt werden, was zu enormen Temperaturproblemen führen wird, oder als vertiakel Options-Boards. Letzteres erfordert vernünftige Steckverbinder, die mächtig viel Platz benötigen und sehr teuer sind, weil Wetterfest, temperaturstabil und Vibrationsfest. Außerdem wird damit der Bauraum auch in der Höhe zugepflastert, was das Einbauen einer kleinen Festplatte oder eines CD/DVD Drives unmöglich macht. Der Kompromiss wäre allerdings, dass man es macht, wie die Cascade auf meinem Bild oben. Die Platine beinhaltet alle Funktionen für den gemeinsamen Nenner aller darauf basierenden Geräte. Unten links ist vermutlich der BlueTooth Chipsatz nicht bestückt, weil das Radio nur das Indianapolis, aber nicht das Indi-Pro ist. Das Mexico müsste auch auf diesem Board aufsetzen, da ist dann das Navi (liks) nicht bestückt. Mein Vorschlag wäre also ein Kompromiss der folgenden Art: Basis-Funktionen on Board Optionen als Plugin. Ich persönlich halte es für unsinnig bei einem Radio den Tuner als Plugin zu machen. Der Tuner braucht, gerade bei Dual-Tuner mit Diversity, eine sehr enge Auslegung und räumliche Anpassung. Dagegen ist es sehr leicht, einfach einen Tuner weg zu lassen, wenn man es nicht möchte. Der VLSI-Chip benötigt nur sehr wenig Fläche und kann gleich neben den Ausio-Mux plaziert werden. Es ging in der Aufgabenstellung zu diesem Thread um ein Auto-Radio mit MP3 Fähigkeit. Wenn wir nun jede Aufgabe als Plugin konzipieren, reichen die Steckerleisten bis in den Motorraum oder Leute, die mehr haben wollen müssen auf Doppel-DIN oder auf Eigenentwicklungen zurückgreifen, wo ein Plugin eben neben 2xTuner auch noch MP3 enthält, damit sie noch ein BlueTooth Board, ein Navi-Board, ein Video-Board... Unterbringen. Wir bekommen in dem kleinen MP3-Decoder doch schon viele weitere Formate mit. Leider hat der STM32F103 kein Host-USB/OTG aber auch da gibt es zwei Möglichkeiten. Entweder eine größere CPU ala STM32F107, da wäre dann Ethernet auch gleich mit drinn, oder eben einen Chip, wie den Vinculum, für WLAN ein Modul von Atmel. Allerdings führen bei diesen Chips lange Leiterbahnen und Steckverbinder gleich zu Problemen. Ein 25MHz SPI-Bus ist schon fast HF-Technik. Also lassen wir doch einfach mal abstimmen, wer sich was in der Grundausstattung wünscht. Man muss ja auch beachten, dass eine Platine grundsätzlich erst einmal Kosten verursacht, egal, ob sie klein oder groß ist. Sinken tut der Preis dann nur über die Stückzahl. Es ist viel billiger einfach ein paar unnötige Bauteile weg zu lassen. Gruß, Ulrich
Gabriel Wegscheider schrieb: > Ich bin auch an einem qualitativ ansprechendem Radioempfänger für's Auto > interessiert. Jep, auf jeden Fall und damit bleibt nur NXP für den Tuner übrig :) > Jedoch hab auf die schnelle noch keinen Anbieter für TEF6616 gefunden... > "Sollte recht preisgünstig sein " ist im Wiki zu lesen. Doch bevor ich Das ist auch nicht möglich, denn NXP sagt auf seiner Webseite ja, dass der Chip im Sample-State ist. Ausgesuchte Interessenten bekommen davon Muster, in Stückzahlen kaufen kann man ihn noch nicht.
Ulrich P. schrieb: > Ich bin aber sehr unglücklich mit der Lösung, jede Funktion auf eine > Aufsteckplatine zu verbannen. Diese müssten entweder als Sandwich > gestapelt werden, was zu enormen Temperaturproblemen führen wird, oder > als vertiakel Options-Boards. Letzteres erfordert vernünftige > Steckverbinder, die mächtig viel Platz benötigen und sehr teuer sind, > weil Wetterfest, temperaturstabil und Vibrationsfest. Außerdem wird Es soll nicht alles modularisiert werden, sondern es ist genau 1 Multimedia-Steckplatz vorgesehen, um dort ggf. einen leistungsfähigeren (Linux-)Rechner unterbringen zu können. Ansonsten gibt es nur das Mainboard und das Bedienteil. > damit der Bauraum auch in der Höhe zugepflastert, was das Einbauen einer > kleinen Festplatte oder eines CD/DVD Drives unmöglich macht. CD und/oder Festplatte war nie vorgesehen! > Mein Vorschlag wäre also ein Kompromiss der folgenden Art: > Basis-Funktionen on Board > Optionen als Plugin. > Ich persönlich halte es für unsinnig bei einem Radio den Tuner als > Plugin zu machen. Der Tuner braucht, gerade bei Dual-Tuner mit > Diversity, eine sehr enge Auslegung und räumliche Anpassung. Dagegen ist > es sehr leicht, einfach einen Tuner weg zu lassen, wenn man es nicht > möchte. ACK s.o. > > Der VLSI-Chip benötigt nur sehr wenig Fläche und kann gleich neben den > Ausio-Mux plaziert werden. Es ging in der Aufgabenstellung zu diesem > Thread um ein Auto-Radio mit MP3 Fähigkeit. Wenn wir nun jede Aufgabe > als Plugin konzipieren, reichen die Steckerleisten bis in den Motorraum Entweder die Mainboard-CPU macht das mp3-Decoding (wie von Kai vorgeschlagen), oder der VLSI sitzt als Minimal-Lösung auf dem Multimedia-Board. Die, die dort Linux einsetzen wollen, brauchen den VLSI ja nicht, und setzen eben ein anderes Board ein. > für WLAN ein Modul von Atmel. Sicher nicht Atmel!...wenn dann Atheros! Der kann dann nämlich auch AP-Mode, und ist ordentllich dokumentiert. Steht allerdings im Augenblick auch gar nicht zur Debatte. Wenn WLAN, dann via USB angebunden. Nur so kann man die Antenne an einen sinvollen Ort bauen. Harry
Ulrich P. schrieb: > Gabriel Wegscheider schrieb: >> Ich bin auch an einem qualitativ ansprechendem Radioempfänger für's Auto >> interessiert. > Jep, auf jeden Fall und damit bleibt nur NXP für den Tuner übrig :) > >> Jedoch hab auf die schnelle noch keinen Anbieter für TEF6616 gefunden... >> "Sollte recht preisgünstig sein " ist im Wiki zu lesen. Doch bevor ich > > Das ist auch nicht möglich, denn NXP sagt auf seiner Webseite ja, dass > der Chip im Sample-State ist. Ausgesuchte Interessenten bekommen davon > Muster, in Stückzahlen kaufen kann man ihn noch nicht. Wollen wir WIRKLICH ein Teil einplanen, das noch nicht kommerziell zu beschaffen ist? Irgentwie bin ich offenbar zu ungeschickt, aber ich hab's noch nicht geschafft, Samples von NXP zu bekommen... Wie soll das dann gehen? Jeder interessierte Mitgestalter sampled dann einen TEFxy? Ich weis nicht... Gibt's da nicht gute Chips, die normal via Farnell/Digikey/RS/... für Privatpersonen in Stückzahlen unter 10.000 zu einem fairen Preis zu haben sind? LG Gabriel
Patrick Weinberger schrieb: > Aber noch schlimmer sind die immer sagen ich will das und das. Ja, ich gehöre zu diesen Leuten. Was ist dagegen auszusetzen? > Dann will aber niemand was dafür machen. Bis jetzt kann auch niemand was anderes machen, als Vorschläge machen. > Hab das beim letzten Projekt gehabt wo ich ein paar Mitschüler > unterstützt hab. Zum Schluss soll man alles machen wenn man es ned > macht, dann jammern sie dahin und werden beleidigend. Wer hat gesagt, dass Du das alleine machen sollst? War das Projekt Deine Idee? -------------------------------------------------------------- Im Moment geht es um die Frage, ob MP3 der Hauptprozessor machen, oder ob hierzu vielleicht eher ein IC verwendet werden soll. Ich bin hierbei für das IC. Die Möglichkeit, das IC einfach nicht zu bestücken, sondern MP3 einem dickeren Prozessor zu überlassen, finde ich gut. Modularisierung um jeden Preis, ist nicht gut. Ich wäre für genau drei Module. Das Radio alleine (ohne GUI/MP3), sollte ein Modul sein. Zusätzliche Audioquellen sollten natürlich einspeisbar sein (CD/DVD/Navi/Mobiltelefon/MP3). Das Modul muss dies dann natürlich handeln können. Dieses Modul soll auch schon in dieser Bauform vollständig lauffähig sein (also inklusive Verstärker). Zur Bedienung muss dann halt ein Terminalprogramm verwendet werden. Als zweites Modul kommt für mich die MP3-Geschichte in Frage. Entweder mit Codec-IC (mein Favorit) und/oder in Software. Da MP3 Pflicht zu sein scheint (ist für mich ok), muss dieses Modul auch einen Kartenslot haben. Das bedeutet, es müssen Dateisysteme lesbar sein. Auch USB wäre hier sinnvoll, denn man möchte vielleicht auch einen USB-Stick als Datenlieferant einsetzen. Wenn USB-Sticks möglich wären, sollte eine Festplatte auch kein Problem mehr sein (hoffe ich zumindest). Achtung Idee: An meinem Rechner habe ich einen Mehrformat-Kartenleser. Dieser meldet sich unter Windows mit mehreren Laufwerksbuchstaben. Es können dadurch auch verschiedene Karten gleichzeitig verwendet werden. Das wäre auch für das Radio interessant. Auch dieses Modul soll alleine Lauffähig sein (ok, Verstärker und Terminal müssen noch dran). Dieses Modul würde es wohl in zwei (bzw drei) Varianten geben: a) kleinerer Prozessor und MP3 als IC b) größerer Prozessor und MP3 in Software c) entfällt, da MP3 in der GUI (zB Linux) abgehandelt wird => Car-PC Das dritte Modul wäre die GUI. Dazu gehört auch die optionale Bedienung eines optionalen CD/DVD-Laufwerkes. Wer Videos abspielen möchte, kann das auch in diesem Modul abhandeln. Dieses Modul kann es auch in mehreren Varianten geben: a) kleinerer Prozessor, der nur Tastendrücke auswertet und ein LCD bedient b) größerer Prozessor mit grafischer GUI und Touch-Panel. c) Linux d) ... Dieses Modul könnte auch das zweite beinhalten. Vorteil dieser Aufteilung wäre, dass jeder "sein" Radio so zusammenstellen kann, wie er es braucht. Auch die Verwendung des MP3-Moduls in einem anderen Projekt, wäre denkbar.
Christian H. schrieb: > Ich wäre für genau drei Module. > > > Das Radio alleine (ohne GUI/MP3), sollte ein Modul sein. > > Zusätzliche Audioquellen sollten natürlich einspeisbar sein > (CD/DVD/Navi/Mobiltelefon/MP3). Das Modul muss dies dann natürlich > handeln können. > > Dieses Modul soll auch schon in dieser Bauform vollständig lauffähig > sein (also inklusive Verstärker). Zur Bedienung muss dann halt ein > Terminalprogramm verwendet werden. > Entspricht exakt der bisherigen Planung > > Als zweites Modul kommt für mich die MP3-Geschichte in Frage. > Entweder mit Codec-IC (mein Favorit) und/oder in Software. > > Da MP3 Pflicht zu sein scheint (ist für mich ok), muss dieses Modul auch > einen Kartenslot haben. Das bedeutet, es müssen Dateisysteme lesbar > sein. > Auch USB wäre hier sinnvoll, denn man möchte vielleicht auch einen > USB-Stick als Datenlieferant einsetzen. Das Motherboard selbst hat kein USB. > > Wenn USB-Sticks möglich wären, sollte eine Festplatte auch kein Problem > mehr sein (hoffe ich zumindest). > und wie lange soll die im Auto halten? > Achtung Idee: > An meinem Rechner habe ich einen Mehrformat-Kartenleser. Dieser meldet > sich unter Windows mit mehreren Laufwerksbuchstaben. Es können dadurch > auch verschiedene Karten gleichzeitig verwendet werden. Das wäre auch > für das Radio interessant. s.o. Kein USB – kein USB-Kartenleser > > Auch dieses Modul soll alleine Lauffähig sein (ok, Verstärker und > Terminal müssen noch dran). > > Dieses Modul würde es wohl in zwei (bzw drei) Varianten geben: du meinst das (optionale) Multimedia-Modul? Das läuft auf 3 Varianten hinaus: * mp3-Only (decodierung via Mainboard-CPU) - Multimediamodul wird nicht eingebaut. * mp3 plus weitere Formate per Chip als Multimedia-light Board * kompl. Linux-Rechner incl. Decodierung als Multimediaboard. > > Das dritte Modul wäre die GUI. Dazu gehört auch die optionale > Bedienung eines optionalen CD/DVD-Laufwerkes. Wo und wie willst du das anschliessen? Aber vor allem warum? > > Wer Videos abspielen möchte, kann das auch in diesem Modul abhandeln. Steht derzeit nicht zur Debatte. Das wird ein Autoradio und kein TV-Gerät. > > Dieses Modul kann es auch in mehreren Varianten geben: Nein! Genau ein Bedienteil mit klar definierter Schnittstelle. Kein Linux - kein Schnickschnack Variieren kann man bei dem Multimediamodul. Harry
Hmmm... Lassen wir uns dieses Design mal durch den Kopf gehen: Wenn man Tuner und Verstärker auf ein Modul kleben will und die Basisplatine nur die CPU beinhaltet, dann passt das ganze nicht wirklich in einen DIN-Schacht. Wenn man 4 Class-D Amps zusammen mit zwei Tunern und mind. einem Sound-Controller IC auf eine Platine klebt, dann nimmt diese schon die Breite eines Radios und knapp die Hälfte seiner Tiefe ein. Es wird mechanisch auch interessant die nötigen Kühlflächen an einem Addon-Board zu platzieren. Ebenfalls interessant werden die verwendeten PKW-Stecker, denn die haben bereits die Höhe eines Radios und sind für TH oder SMD Montage auf dem Basis-Board vorgesehen. Es läuft also auf 6..8 Befestigungsbolzen hinaus um das Platinchen sicher und vibrationsarm aufzuhängen. Dazu kommen Steckverbinder, die auf 8..12V fröhliche 6..10A Peak verkraften können. Daneben aber auch welche, die sauber getrennt digitale und analoge Signale übertragen können. Eventuell kann man das Design so auslegen, dass die CPU-Platine unten und die Tuner/Class-D Platine Überkopf als Deckel darüber sitzt. Dazwischen können dann noch andere Boards platziert werden. Wird ebenfalls mechanisch interessant, da damit der Kühlkörper von der oberen Platine getragen wird und alles andere dazwischen sitzen muss. Die Abwärme wird in die Platinenfläche übertragen, die sehr schlecht selbige leitet. Also schauen wir mal weiter. Die CPU Platine wird neben selbiger auch mind. mal folgende DC/DC Wandler beinhalten: 8.5V Tuner, 3.3V Digital, 3.3V Analog, 8.5V oder gefilterte 12V Class-D, 1.8V CPU Core, eventuell noch 10..15V Buck/Boost für OLED oder LCD. Also eigentlich ist das Board nur zu einem Drittel, vielleicht der Hälfte gefüllt. Hinten ist kein Platz mehr, da sitzen der Kühlkörper, der von oben kommt. Bleibt also noch Platz für eine 1.5" oder eine 2" HDD, nur so zum Größenvergleich. Das ist, mit Verlaub gesagt, kein guter Ansatz. Können wir nicht einfach abstimmen, welche Features diejenigen haben wollen, die aktiv zu dem Projekt beitragen wollen? Diese kommen auf die Basisplatine. Alles andere kann dann immer noch in senkrecht einschiebbaren Karten untergebracht werden. Wenn man sich das Becker oben ansieht, wäre es möglich links locker mal zwei Steckkarten unter zu bringen, auch wenn das Laufwerk drin sitzt. Den Bauraum vom Laufwerk könnte man für weitere Karten nutzen oder eben für eine HDD oder Kartenleser oder was auch immer. Gehen wir das ganze Konzept mal von der anderen Seite an: Der VLSI wird in kleinen Häppchen von 32 Bytes bei ca. 1Mbit gefüttert. Kein Problem, der kann auch ins Handschuhfach vom Bus her. Aber, er nimmt kaum Platz weg und würde auf dem Mainboard in der Nähe des Audio-Controllers auch bei FLAC guten Klang bringen, wenn er nicht über weite Leitungen sein Audio zum MUX bringen müsste. Über Stecker und etliche cm Leitung ( ein Stecker sind auch 'nur' ein paar cm Leitung) kann die Qualität leiden und das obige Design würde ja bedeuten, dass es vom MP3-Board erst mal auf das Mainboard und von da aus wieder auf das Tuner/Class-D Board hoch... Das gleiche gilt im Grunde auch für Netzwerk und USB oder SD. Jaja, lasst mich mal zu Ende denken... Ein Host-USB-Bus muss sauber geführt werden, sonst gibt es Probleme beim Verbinden und Daten übertragen. Da die CPU bereits USB hat (haben kann) müsste man also eine eigene Steckkarte für lediglich 6 SMD Bauteile 0603 und einen SO8 Chip machen, die aber mind. 500mA bei 5V zur Verfügung stellt, obwohl man wahrscheinlich schon einen DC/DC für 5V auf dem Mainboard hat, der nur ein paar mm größer ausfallen würde, wenn er die 500mA (oder 1A bei zwei Slots) gleich mitliefern sollte. Auch wenn man USB einfach machen will und einen FTDI Vinculum einsetzt, würde das lediglich ~7x7mm mehr bedeuten, der SPI-Bus muss aber dann wieder ordentlich Speed bringen. Also sollte der nicht zu lang sein, sonst geht er nicht, oder man hört ihn in den Boxen? SD-Card wäre ein Steckboard mit nicht einmal 6 Bauteilen, denn die karte muss lediglich an einen SD- oder auch nur an einen SPI-Bus angeschlossen werden. Allerdings gebe ich zu, dass die SD-Card besser auf einem kleinen Platinchen sitzt, damit man sie nach eigenen Vorstellungen in der Front platzieren kann. Aber auch hier bedeutet ein ungeschicktes Layout und zu viele Stecker das Problem, dass die Busgeschwindigkeit einbricht. Also wenn das Konzept, die Basisfunktionen bereits auf ein Addon Board zu setzen sich durchsetzt, dann steige ich aus. D.h. nicht, das ich garnicht mehr mitmache, aber ich werde dann bei der Hardware eigene Wege gehen. Eventuell gleiche Chips, gleiche CPU aber anderer Aufbau. Wenn es jetzt schon um die Basisplatine und Basis-Features so ein gerangel gibt, bin ich mal auf die Gestaltung der Frontblende gespannt :) OLED mit Capacitive-Touch ganz ohne sichtbare Tasten? Oder doch ein LCD mit ein paar Knöppen darunter? Frontblende als Klappe damit USB und SD dahinter passen, oder USB und SD als Schlitz? Ich persönlich bin gegen Geschosse im PKW, die auch noch leicht abbrechen, wenn man mal nicht aufpasst, also USB lieber hinten raus und als kleines Döschen im Handschuhfach oder in der Mittelkonsole. SD-Card ist ne gut Idee, aber MicroSD und MiniSD sind für PKW ungeeignet, denn sie können in Schlitze fallen aus denen man sie nie wieder befreien kann ohne das Interieur zu zerlegen. Lenkt auch ganz schön ab das fummelige Zeug. Trotzdem ist es praktisch und mit SDHC endlich auch groß genug. Also rein damit. Eventuell SD als Tray-Loader? Einfach 6 Kärtchen auf die Lade legen und dann zufahren lassen. Ist mechanisch aber sehr anspruchsvoll, wenn man keinen Kunststoff-Rapid-Prototyper hat. Ok, genug Ideen ausgeplaudert :) Bin mal gespannt, wie das nun weiter geht. Gruß, Ulrich
@Ulrich das (vorläufige) Blockschaltbild kennst du? http://osar.it-livetalk.de/index.php/Blockschaltbild Das Mainboard beinhaltet Tuner, Verstärker, Stromversorgung eine angemessene CPU und den Multimediaslot auf EINEM Board. Das steht aber auch alles bereits im Wiki, und hier im Forum wurde das auch gefühlte 100mal erklärt. Harry
Hi Harry, sorry, aber die Diskussion oben liest sich anders als es das Blockschaltbild beschreibt. Bin trotzdem verwirrt, wie Du das Audio-Signal aus dem uC in die AMPs bekommen möchtest. Gruß, Ulrich
Harald L. schrieb: > Das Motherboard selbst hat kein USB. Schade, dann fallen USB-Sticks weg. >> Wenn USB-Sticks möglich wären, sollte eine Festplatte auch kein Problem >> mehr sein (hoffe ich zumindest). >> > und wie lange soll die im Auto halten? Muss ja nicht unbedingt im Auto verbaut sein. >> Das dritte Modul wäre die GUI. Dazu gehört auch die optionale >> Bedienung eines optionalen CD/DVD-Laufwerkes. > > Wo und wie willst du das anschliessen? Wie schon gesagt, stelle ich mir die Hauptkomponenten (Radio/Multimedia) so vor, dass ich diese auch autark laufen lassen kann und bei Bedarf per RS232; I2C (oder ähnliches) bedienen kann. Dafür kann ich mir dann auch eine GUI nach eigener Vorstellung zusammen bauen. > Aber vor allem warum? Warum? Wie bediene ich das Gerät? Durch Gedankenverbindung? > Nein! Genau ein Bedienteil mit klar definierter Schnittstelle. Kein > Linux - kein Schnickschnack Ich kann also kein eigenes Bedienteil verwenden? Ich bin also mit diesem Projekt auf genau dieses Gerät mit genau diesen Funktionen und genau diesem Aussehen (GUI) beschränkt. Das habe ich auch bei den kommerziell verfügbaren Geräten. Hmm, also nichts für mich. Dann lehne ich mich einfach zurück und beobachte die weitere Entwicklung. Mal sehen, ob dann doch noch etwas für mich brauchbares abfällt. Ich hatte ja gehofft, dass man bei diesem Projekt seinen Spieltrieb (eigenes Design, eigene Funktionen) verwirklichen kann.
Soo, ich habe mir das Blockschaltbild nochmal genau angesehen. Es ist doch nicht so weit von meiner Vorstellung entfernt. Mein "GUI"-Modul entspricht dem "Frontpanel PCB". Mein "MP3"-Modul entspricht dem "Car PC"-Modul (Multimedia-Modul) nur das letzteres im Blockschaltbild keine Audio-Daten zum "Main PCB" übertragen kann. Mir fehlt zum glücklich werden also nur noch die USB-Funktion des Basismoduls. Dies könnte ich aber auch im "Car PC"-Modul abhandeln, falls eine Audio-Rückführung existiert. Ansonsten schließe ich mich Ulrich P. an: Ulrich P. schrieb: > D.h. nicht, das ich > garnicht mehr mitmache, aber ich werde dann bei der Hardware eigene Wege > gehen. Eventuell gleiche Chips, gleiche CPU aber anderer Aufbau.
Ich habe ja schon ein wenig Überzeugungsarbeit geleistet, was die Basis angeht. Wenn man sich auf Nut/OS als Betriebssystem einigen kann, dann könnte man natürlich die Bibliotheken nutzen, die für einen Chip bereits geschrieben wurden, und muss sich nur noch auf das Layout konzentrieren. Findet man da Probleme, kann man das OSCAR wissen lassen, ehe sie selber drüber stolpern. Man kann auch alternative Bibliotheken schreiben für andere Bausteine und der nächste mischt kunterbunt. Die GUI ist eine ganz andere Sache. Bei einem Radio ist diese in der Regel schmal und informativ, jedenfalls, wenn man ein gewisses Alter erreicht hat. Bunt darf sie schon sein, aber das bedeutet nicht, dass man massenhaft Daten übertragen muss. Es reicht ein kleine Controller, vielleicht mit QTouch, damit man nicht eine kleine Plexiglas-Scheibe mit 40 schiefen Löchern versehen muss. Außerdem wäre das Radio im abgeschalteten Zustand fast unsichtbar. Der kleine Controller bekommt ein mittleres Serial-Flash zur Seite und kann daraus Unmengen an bunten Icons schaufeln und darstellen. Per I2C bekommt er aus dem Audio-Proz noch ein paar EQ/FFT Daten, damit auch ein Spekki dargestellt werden kann. Alles kein Problem. Für die vielen bunten Symbole ist es wirklich billiger einen ATmega8 zu nehmen und ein 512kB Serial-Flash als einen CortexM3 mit 128k Flash. Ist also alles machbar. Momentan ist das Mainboard nach dem Blockschaltbild noch ziemlich leer. Ich denke fast, dass ein VLSI oder FTDI noch dazu kommen, allein um das Board voll zu bekommen. Ich meine, eine Prototypen-Platine kostet ca. 70€. Ich würde mich echt ärgern, wenn ich die berappen müsste, obwohl das Main-PCB noch leer ist. ;) Gruß, Ulrich
Christian H. schrieb: > Ich kann also kein eigenes Bedienteil verwenden? Ich bin also mit diesem > Projekt auf genau dieses Gerät mit genau diesen Funktionen und genau > diesem Aussehen (GUI) beschränkt. Das habe ich auch bei den kommerziell > verfügbaren Geräten. > da hab ich mich wohl misverständlich ausgedrückt. Natürlich kannst du da was Eigenes machen. Nur wird im Rahmen dieses Projekt eben nur 1 Bedienteil entwickelt. Das Blockschaltbild hatte ich bewusst als "vorläufig" gekennzeichnet. Ist auch richtig, daß da noch die Audio-Pfade und weitere Anschlüsse zum Multimediaboard etc fehlen. Das war lediglich unser erster Entwurf, der die Verteilung der Komponenten auf die Baugruppen aufzeigen soll. Harry
Ulrich P. schrieb: > Ist also alles machbar. Momentan ist das Mainboard nach dem > Blockschaltbild noch ziemlich leer. Ich denke fast, dass ein VLSI oder > FTDI noch dazu kommen, allein um das Board voll zu bekommen. Mit FTDI meinst Du ein Vinculum (USB-Interface)? Etwa sowas? http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=20659&flv=1&bereich=&marke= Wenn ich damit "MP3" abspielen könnte, wäre ich bedient.
> Mit FTDI meinst Du ein Vinculum (USB-Interface)? Etwa sowas? > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=20659&flv=1&bereich=&marke= > > Wenn ich damit "MP3" abspielen könnte, wäre ich bedient. Ja, das meinte ich. Der VINCULUM ist ein autonomes USB-System, das sich bereits um Dateisystem und ähnliches kümmert. Man muss praktisch nur noch das Verzeichnis auslesen, eine Datei selektieren und dann kommen die Daten. In wie fern die Realität bei diesem Chip hält, was die Werbung verspricht, kann ich aber noch nicht sagen. Hatte so ein Teilchen mal an einem ATmega32 laufen, funktionierte recht einfach, habe es aber nicht auf alle möglichen Dateisysteme und Naming-Konventionen getestet. Damals war der Chip auch noch sehr jung. Wäre interessant zu wissen, ob der Vinculum per USART gesteuert werden kann aber per SPI dann die Daten streamt. Dann könnte man ihn direkt mit einem VLSI Decoder verheiraten und braucht nur noch einen kleinen Controller um die Steuerung zu übernehmen. Aber da hat sich einiges getan: http://www.vinculum.com/prd_vmusic1.html Gruß, Ulrich
Auweia! Kaum ein paar Tage nicht online und schon kommt man nicht mehr mit. :( Wir sind also vom SH7264 wieder weg und stehen wieder ganz am Anfang?
Pezi schrieb: > Auweia! Kaum ein paar Tage nicht online und schon kommt man nicht mehr > mit. :( > Wir sind also vom SH7264 wieder weg und stehen wieder ganz am Anfang? Nein, keine Sorge, es hat sich nicht alles gehändert. Es sieht schlimmer aus als es ist :-) Das Grundkonzept steht. Mehr dazu später.
Ulrich P. schrieb: > [...Vinculum...] Och nö, nicht so ein fertig-dings (kenn den Vinculum auch nicht nur vom sehen)... Aber dann wird es ja GANZ langweilig. Ich wollte sooo gern einen kleinen, kompakten auf USB Mass storage only zugeschnittenen USB Host stack auf dem µC sehen...
Kai G. schrieb: > Och nö, nicht so ein fertig-dings (kenn den Vinculum auch nicht nur vom > sehen)... Aber dann wird es ja GANZ langweilig. So langweilig finde ich das Teil garnicht. Ich habe mir mal einen geordert, um ihn mal genauer anzusehen/auszuprobieren.
Christian H. schrieb: > So langweilig finde ich das Teil garnicht. Ich habe mir mal einen > geordert, um ihn mal genauer anzusehen/auszuprobieren. Klar, für sich genommen ist das schon ziemlich gut und einzigartig, aber in so einem Autoradio-Gesamtsystem find ich es nicht sehr schön wenn der haupt-µC schon einen USB Host port mit sich bringt.
Hallo Kai! LOL! Also ich bin ja auch eher dafür, dass der uC einen OTG-USB Port hat und der MassStorage Host auf dem uC läuft. Es sind ja nur 6 Bauteile dafür notwendig. Aber man muss da auch viel selber machen. Viele Hersteller geben einem ein Software-Paket mit, dass diese Dinge bereits als Demo realisiert. Wenn man sich dann den Disclaimer durchliest, hat man plötzlich ein Problem mit der GPL oder der BSD Lizenz. Da stehen nämlich so kleine Gemeinheiten drin, dass man den Code nutzen aber nicht anderweitig online stellen darf, oder man mit diesem Code an den Hersteller gebunden ist und so weiter. Das ist ein Grund, warum es für Nut/OS noch keine USB-Lib gibt, den Code schreiben wir gerade selber, weil ATMEL nicht bereit ist eine Klausel aus dem Disclaimer zu entfernen. Der Vinculum würde zudem auch das Problem erschlagen, dass man viel RAM für ein großes Directory-Caching bereithalten muss, oder dass man den USB-Bus über lange Wege und Stecker führen muss. Es läuft halt alles über SPI (USART scheidet in unserem Konzept allein wegen der niedrigen Baudrate schon mal aus). Dass man bei dem Teilchen auch noch die Software ändern kann, macht es um so interessanter.
Christian H. schrieb: > Kai G. schrieb: >> Och nö, nicht so ein fertig-dings (kenn den Vinculum auch nicht nur vom >> sehen)... Aber dann wird es ja GANZ langweilig. > > So langweilig finde ich das Teil garnicht. Ich habe mir mal einen > geordert, um ihn mal genauer anzusehen/auszuprobieren. Was heißt langweilig? Selber bauen ist unwirtschaftlich ... Sowohl vom Zeit- als auch vom Geld-Bedarf ... Ihr dürft auch nicht vergessen, dass die Chance immer kleiner wird, dass das Ding jemals fertig wird, je mehr Geld und Zeit investiert werden muss ... Zum Schluss sind es eh nur 2 Leute, die die ganze Arbeit machen ... Dahergeredet ist gleich, etwas zu tun, ist aber etwas ganz anderes ... Wenn ihr was komplett eigenes entwickelt, müsste das schon einzigartig sein, dass sich der Aufwand rechnet ... Grüße, Thomas
Hi Ulrich! Mit USB kenn ich mich zufällig verdammt gut aus. So einen Host stack der nur für Mass storage ist (Also nichtmal HUB-support) trau ich mir zu from scratch in begrenzter Zeit zu schreiben. Zumal USB auch, wie ich bei den meisten hier raushörte eher optional ist und nicht von beginn an dabei sein muss. Es hat auch keinen Sinn das board komplett Zuzukleistern nur weil man Platz hat und dann ein unheimlich kompliziertes Layout zu haben (ZEIT!). Es ist ja auch nicht nur der Platz für den Chip an sich auf dem Board, für die Verbindungen zwischen den ICs braucht man auch Platz, der je nach anzahl der benutzten Layer nicht zu vernachlässigen ist. Das DIR-Caching für MP3 ist unproblematisch, ich hatte relativ am Anfang mal was dazu geschrieben. viele Grüße, Kai
Kai G. schrieb: > Mit USB kenn ich mich zufällig verdammt gut aus. So einen Host stack der > nur für Mass storage ist (Also nichtmal HUB-support) trau ich mir zu > from scratch in begrenzter Zeit zu schreiben. Wenn das stimmt (bezweifle ich nicht), kann man das auch gerne im Hauptprozessor machen. USB finde ich halt sehr interessant, da ein Stick einfach nicht so empfindlich, wie eine SD-Karte ist. Letztere hat meine Frau schonmal abgebrochen - die Karte steckte in einem USB-Adapter und schaute etwas 1cm raus. Sie ist noch verwendbar, aber ich vertraue ihr nur noch Testdaten an.
Christian H. schrieb: > Wenn das stimmt (bezweifle ich nicht), kann man das auch gerne im > Hauptprozessor machen. USB finde ich halt sehr interessant, da ein Stick > einfach nicht so empfindlich, wie eine SD-Karte ist. Letztere hat meine > Frau schonmal abgebrochen - die Karte steckte in einem USB-Adapter und > schaute etwas 1cm raus. Sie ist noch verwendbar, aber ich vertraue ihr > nur noch Testdaten an. OK, neue (mechanische) Design Anforderung: SD Karten dürfen nicht zu weit rausstehen :-) USB steht bei mir zumindest nicht so weit oben auf der Liste weil es mechanisch gesehen nicht so toll ist. Ich will nicht ständig einen USB Stick in der Radio-Front stecken haben (Gefährlich wg. abbrechen wenn man wild um sich fuchtelt weil man sich gerade über den Vordermann aufregt). Höchstens um neue Daten auf die SD/MMC Karten zu packen oder so wär es akzeptabel in der Front zu haben... Andernfalls wäre ein Kabel denkbar das hinten aus dem Radio rauskommt und man irgendwo im Handschuhfach versteckt oder so.
Bzgl. USB sind wir dann schon zwei, obwohl ich mehr auf der Device-Seite arbeite :)
Ulrich P. schrieb: > Bzgl. USB sind wir dann schon zwei, obwohl ich mehr auf der Device-Seite > arbeite :) Astrein, wenn Du die Device-Seite von der Mass-storage Klasse kennst hast Du schon die halbe Miete und ich nicht die ganze Arbeit alleine :-)
Wie ich immer leichtfertig sage, USB ist auch nur ein serieller Bus :) MS-Class habe ich nich nicht gemacht, nur CDC und Vendor-Specific, aber ich habe schon in den Sourcen gestöbert und sehe da kein größeres Problem.
Was haltet ihr von dem Chip? http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT2348_S.pdf oder auch dieser... http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT12311-s.pdf
Benjamin Maresch schrieb: > Was haltet ihr von dem Chip? Genau sowas suchte ich gerade. Ist der irgendwo außerhalb von China zu bekommen? Edit: Sorry, Taiwan nicht China :-)
Ok, dann machen wir den Topf doch mal mit Deckel Anforderung 1: System soll mit einer dokumentierten API existieren, dass Hardware und Steuer-Software voneinander trennt. Dabei gibt es zwei Extrema: 1) Schnelles spezialisiertes System, einfach und Laien-gerecht 2) Linux forever mit Video/CoDecs/QT.... Anforderung 2: Puristische Hardware mit diskreten Chips, die mit wenigen I2C Kommandos das erste Audiosignal vom Tuner in die AMPs schiebt. Aber auch komplexe CoDecs auf Linux-CPU mit Video-Out, Headrest-LCD, Optical SPDIF nach hinten, Remote-Control u.s.w. Und doch soll sich auch alles mit Hausmitteln löten lassen. Das ganze ist machbar. Wir machen ein Audio-Board mit einem CPU-Träger: http://www.ic-board.de/index.php?cat=c25_OEM-Module.html&XTCsid=0fb264979ec45cd8bb932418861f5b93 Die ADB1000 Module bzw deren Hirose-Stecker sind mit den gleichen Tricks Handlötbar, wie man sie auch für vielpinnige SMDs verwendet. Die auf den Modulen verbauten AVR32AP7000 CPUs sind aber sowohl für Linux ( Buildroot) als auch Nut/OS verwendbar. Ja, das kleinste ADB Modul ist schon sehr teuer im vergleich zu einem einfachen Controller, deshalb noch ein etwas erweiterter Kompromiss: Man kann einen AVR32UCxx auf das Mainboard setzen und die Sockel für das ADB1000 drum herum. Könnte passen und dann eine echte Bestückungsalternative werden. Entweder Chip oder Modul. Auf jeden Fall erschlägt diese Option beide Wünsche. Aber es geht noch weiter. Nut/OS setzt auf die std-libraries auf, kennt was von Posix und orientiert sich generell an Linux. Ein Treiber für das eine System kann auch in das andere portiert werden. Eigentlich kann auch das Nut/OS Radio alles, was das Linux Radio kann. Beide spielen alle gängigen Medien ab, außer Video, das bleibt nur denen vorbehalten, die entweder an einen Video-Drive heran kommen ( bei Interesse kann ich mal fragen, ob wir davon welche bekommen) oder Linux einsetzen. Ein weiterer Einwand der Linux-Gemeinde wird noch sein, dass Storage+WLAN darunter einfacher ist. Ja, aber ich möchte keinem Laien raten mit 100mW WLAN direkt unter dem Dashboard herum zu basteln. Natürlich muss im Auto alles gegen alles geschützt sein, aber auch die Hersteller müssen sparen. Also ist die Option das WLAN auf ein Modul hinter dem Himmel zu verbannen und die Dach-Antenne zu patchen besser. Damit ist der Vorteil dahin, dass man ein Atheros Modul in das Radio steckt, man macht TP und leitet das dahin, wo man einen WLAN-Client platzieren kann. Jep, ich weiß, dass es hier einige gibt, die das Modul doch ins Radio bauen können und damit dann auch noch eine Zulassung erhalten könnten, ich vielleicht auch, aber denkt bitte an die Nachbau-Sicherheit. Wenn man aber auf rein RJ45/TP geht, kann Nut/OS das auch. Bluetooth gibt es zum Glück als fertiges Modul inkl. Antenne und Zulassung. Das Teilchen kann direkt hinter der Frontblende sitzen und es ist gut. Das WLAN muss aber nach draußen funken. Ok, nun ist gut, Christian, Kai, Harry, lasst uns einen Deckel drauf machen. Vorschlag: AVR32UC3A1512 (100Pin TQFP) Nut/OS, Rest wie geplant. Wenn es der Platz erlaubt platzieren wir darüber das ICNova Modul AP7000OEM. Beide AVR32 werden mit I2S-In und I2S-Out an den Audio Router angeschlossen. Leider gibt es für meinen Favouriten, den SAA7706H keine Preise oder Lieferdaten. Dieser hätte aber alles, was wir brauchen. Alternative 1: Linuxer gucken in die Röhre, wir nehmen einen verbreiteten SAM7X oder einen SAM9XE, letzterer kann auch wieder Linux, aber nicht ohne externes RAM/FLASH für Nut/OS reichen die internen 128..512kB Alternative 2: AT91SAM9XE128 + externes Flash und Ram und es geht doch wieder alles. Allerdings halte ich die 9XEs nicht für so leistungsfähig in Bezug auf Audio/Video unter Linux, wie die extra dafür beworbenen AVR32. Trotzdem kann man Alternative 1 und 2 auch leicht als Bestückunsoption machen. Für alle genannten CPU stehen mit OpenOCD, gcc, libc, Nut/OS, gdb, buildroot... jeweils komplette CSPs zur Verfügung. Gruß, Ulrich
Benjamin Maresch schrieb: > Was haltet ihr von dem Chip? > > http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT2348_S.pdf > > oder auch dieser... > > http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT12311-s.pdf Hihihi... Hast Du Dir mal die Datenblätter angesehen? Also entweder hat mein Adobe einen an der Waffel oder ich habe es an den Augen, wenn Du mal auf Seite 3 des PT12311-s.pdf schaust.... Wenn der Chip so ist, wie seine Beschreibung... Ich bin ganz strickt gegen Chinakracher in der Kiste, sorry. Gruß, Ulrich
Die stellen die Pinbelegung doch tatsächlich von unten betrachtet dar ROFL.
Ulrich P. schrieb: > Hast Du Dir mal die Datenblätter angesehen? Also entweder hat mein Adobe > einen an der Waffel oder ich habe es an den Augen, wenn Du mal auf Seite > 3 des PT12311-s.pdf schaust.... zeigt mir der Foxit-Reader auch spiegelverkehrt an. gibt wohl auch ne andere richtige Version: http://www.alldatasheet.net/datasheet-pdf/pdf/311275/PTC/PT12311-S.html Nur ausführlich und mit Befehlsatz ist das auch nicht. Gruß Gerd
> Auweia! Kaum ein paar Tage nicht online und schon kommt man nicht mehr > mit. :( Ehrlich gesagt mir wird das hier auch langsam zu unuebersichtlich. Der Thread ist viel zu fett und eine Forumseite zu unleserlich wenn man mal 2-3Tage keine Zeit hatte. > Wir sind also vom SH7264 wieder weg und stehen wieder ganz am Anfang? Wieso? Der ist doch perfekt? Was soll es denn besseres geben? Ich hab uebrigens mal einen an Kai gegeben damit er sich den mal anschauen kann. Olaf
Also die CPU Frage wird sich in den nächsten Tagen klären, eventuell mit einer Überraschung für alle beiden Fronten, die Spartaner und die Linuxer. Aktuell ist eher das Problem, dass es kaum noch analoge Audio-Controller oder Multiplexer gibt. Es gibt sie sicherlich, aber man kommt kaum an die vollständigen Datenblätter und erst recht nicht an die Chips. Auch da gibt es fast nichts rein analoges mehr, sondern die Großen wechseln alle zu integrierten DSPs und das gleich mit voller Kraft. Da ist also noch Arbeit zu leisten. Außerdem wollen wir ja ein paar Class-D Endstufen verbauen. So 4..6 Stück sollten es schon sein. Hier ist TI recht fleißig: http://focus.ti.com/apps/docs/viewdevices.tsp?blockdiagramId=6175&blockId=8151&designOptionId=8793&appId=472 Schön, dass es einige interessante Chips mit gleich vier Class-D AMPs gibt und die Dinger ziemlich ausgefuchst sind was die interne Überwachung angeht. Das steigert die Nachbau- und Experimentier-Sicherheit. Gruß, Ulrich
Oh, noch was gefunden, hat sehr viele analoge Inputs und bereits PWM Outputs. http://focus.tij.co.jp/jp/lit/ds/symlink/tas3308.pdf Naja, suchen wir mal weiter nach einem Audio-Controller.
Ulrich P. schrieb: > Oh, noch was gefunden, hat sehr viele analoge Inputs und bereits PWM > Outputs. > http://focus.tij.co.jp/jp/lit/ds/symlink/tas3308.pdf > Naja, suchen wir mal weiter nach einem Audio-Controller. tda7418 macht genau was wir suchen: http://www.st.com/stonline/books/pdf/docs/13246.pdf Bezugsquelle: ?!? Auf die schnelle nicht gefunden. Wobei bestimmt Blitze überspringen wenn den ST-IC an einen NXP-IC koppelt :-)
> Auch da gibt es fast nichts rein analoges mehr, sondern die Großen > wechseln alle zu integrierten DSPs und das gleich mit voller Kraft. Ist doch kein Problem, koennen wir kleinen doch auch. :) Olaf
Kai G. schrieb: > tda7418 macht genau was wir suchen: > http://www.st.com/stonline/books/pdf/docs/13246.pdf > endlich mal ein sinnvoller Vorschlag! > Bezugsquelle: ?!? Auf die schnelle nicht gefunden. > Nicht nur das!...ich hab auch kein .pdf gefunden, was den Prozessor und die Peripherie beschreibt... > Wobei bestimmt Blitze überspringen wenn den ST-IC an einen NXP-IC > koppelt :-) dann kommt der Blitzableiter auf die Feature-List :-D Harry
Jaja, ich hatte da aber schon was weiter gedacht :) Der TI chip hat neben einigen analogen Eingängen auch 3 digitale und ebenso entsprechende Ausgänge. Der DSP-Core kann die Signale beliebig hin und her routen. So könnte man die beiden Tuner analog einspeisen, der TI digitalisiert sie, sschickt sie an den uC für die Diversity und nimmt sie auf einem I2S wieder entgegen um sie ggf. noch passend zu machen ( Höhen, Bässe...) und dann auf entweder einem PWM oder einen analogen Ausgang zu geben. Der DSP ist mit einer grafischen Suite zu programmieren, die TI kostenfrei zur Verfügung stellt. Man schiebt sich einfach die nötigen DSP Module zwischen die Signale und fertig. Da man auch eigene DSP Module schreiben kann ( groß ist er aber nicht) könnte man auch die Diversity später vielleicht in den DSP verschieben? Damit wären noch 2 I2S Eingänge frei, also für den VLSI perfekt, und dann ist noch einer für einen SPDIF Eingang, oder in meinem Fall ein I2S für das DVD Drive übrig. Ist nur ein Vorschlag und erspart einige externe ADCs/DACs, wäre also auch ein Vorteil für Fläche und Bauteilzahl.
Harald L. schrieb: > Nicht nur das!...ich hab auch kein .pdf gefunden, was den Prozessor und > die Peripherie beschreibt... Das ist das Problem bei ST und NXP, sie machen Werbung für die Systeme wir bekloppt, aber Datenblätter gibt es nur spärlich und Chips keine, jedenfalls nicht an privat mal eben so. Bei TI kenne ich das so nicht, habe aber auch noch keine Samples aus diesem Bereich geordert. Alles andere von TI ist i.d.R. innerhalb von einem Tag da. Der Rekord war eine Sample-Order um 17:35 und der Eingang des Päckchens (Absender Atlanta/USA) um 10:30, dabei kann man getrost noch fast ne Stunde Hauspost abziehen :)
Was auch immer süß ist, ist so eine TI C54/c55xx DSP. http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dsp§ionId=2&tabId=50&familyId=114
Wenn ich das richtig verstanden hab, ist das Ziel doch, ein wirklich gutes Radio zu bauen, und nicht ein DSP-Experimentierboard, das keiner der beteiligten wirklich beherrscht. Ein Audio-DSP ist sicherlich eine tolle Sache, aber kann dann ggf. auch auf dem (optionalen) Multimediamodul sitzen. Wenn wir eine (völlig neue) Baustelle nach der anderen aufmachen, wird das nie was! Was wir brauchen sind Komponenten, die für jeden beteiligten beherrschbar, beschaffbar und lötbar sind! Dazu eine ausreichende, aber nicht völlig überdimensionierte CPU. Klar sind ein paar Reserven wünschenswert, aber mir konnte bisher noch niemand hier erklären, warum ich für die gestellten Anforderungen eine SH-Irgendwas-CPU und wohl möglich noch einen DSP brauch... Klar ist sowas ein "nice-to-have".....aber Leute!....das soll ein Radio werden, kein Experimentier-Brett. Ich bin nach wie vor für ARM7!(bekannt, beherrschbar, beschaffbar, weit verbreite, billig und völlig ausreichend) Macht euch lieber mal ein paar Gedanken über das Gehäuse! Bevor das nicht geklärt ist, braucht man mit einer Platine gar nicht erst anfangen. ...just my 2 cent Harry
Ok warum immer so herum reden ? Wir haben 2 Vorteile Gegenüber Kommerziel: 1. Keine Personalkosten 2. Keinen Zeitdruck Also man kann einen einfachen Tuner mit µC aufbauen und eine Schnittstelle festlegen. Ich will damit sagen ob ein Monat mehr oder weniger is ja wurscht ob die Module einzeln entwickelt werden oder zusammengefasst is ja egal. Warum nicht erst ein Tunermodul und ein anderes Team arbeitet an einem oder mehreren "Mainboards". Man kann ja noch immer sagen ok wir nehmen einen einfachen ARM oder eine DSP + ARM wenn man mal beide Lösung hat. Also mal anfangen statt herumreden !
Seennoob schrieb: > > Also mal anfangen statt herumreden ! die Vorstellung solltest du bei einem Projekt dieser Größe begraben! Exakte Planung ist alles!!! Harry
Harald das ist ned Planung was jetzt gemacht wird sondern mit Verlaub eher eine Sammlung von Gehirn Abfall. Normalerweise fängt mit einem Lastenheft an, darauf erstellt man ein Pflichtenheft. Also auf Deutsch es gehört mal fixiert was rein muss und wie es gemacht werden soll. Also Schreibt mal wer ein Lastenheft (Anforderungen + Randbedingungen) und dies muss ins Wiki. Dann neuen Thread auf wo es ums Pflichtenheft geht. Als externer Vorschlag gg
Seennoob schrieb: > oder mehreren "Mainboards". Man kann ja noch immer sagen ok wir nehmen > einen einfachen ARM oder eine DSP + ARM wenn man mal beide Lösung hat. > Wie stellst du dir das vor? Das Gehäuse gibt die Abmessungen, Lage der der Anschlüsse, Befestigungsmöglichkeiten, Kühlmöglichkeiten etc vor. Bevor das Gehäuse nicht steht, kannst du die Konstruktion des Mainboard komplett vergessen. Allein die Lage der zu kühlenden Bauteile wird mass geblich durch das Gehäuse bestimmt. Das selbe gilt für die Verbindungen zur Aussenwelt. Ich denke, daß wir die Rahmenbedingungen jetzt weitgehend fixiert haben. Jetzt sollte sich mal jemand mit Erfahrungen in Mechanik-Desig ein paar Gedanken zum Gehäuse machen. Ich hab das letztens mit Kai diskutiert, und wir sind bei 5mm dicken Alu-Profilen gelandet. Bei der Stärke kann man auch in die Stirnseite ein Sackloch (M3) bohren. Diese Profile müssen natürlich gefräste Schlitze für Leiterplatten und Deckel und entsprechende Durchbrüche für Anschlüsse enthalten. So, wie wir die brauchen werden, wird es die vermutlich nicht als Meter-Ware geben. D.h.: wir müssten einen Betrieb finden, der bereit ist, uns sowas in Kleinserie bezahlbar zu fertigen. ...aber vielleicht hat ja jemand eine bessere Idee. Ohne das Gehäuse ist das ein Experimentier- aber kein Auto-Radio, daher sollten/müssen wir dieses Problem als eines der Ersten lösen. Harry
Nana, Abfall ist das sicherlich nicht, es sind immerhin mind. zwei Leute aus der Branche dabei, die Tuner, Mixer, Audio/Video DSPs und auch die gerade genannten TiDSP C55xx sehr gut kennen. Der Abfall ist lediglich dadurch hervorgerufen, dass die Hersteller von Chips alles einfach so übers Internet oder Distis verkloppen was sie haben, aber genau diese Chips, die wir brauchen eben nicht. Bei Ti ist das vielleicht noch einfach via eMail zu klären, bei ST und NXP eben nicht, weil die mal eben ganze Abteilungen an einander verkaufen und dann wiederum mit anderen zusammen fassen und wieder verkaufen. Selbst wenn Du von einem ehemaligen Kollegen noch eine VCard hast, kann es sein, dass der schon längst wieder woanders ist oder was anderes macht. Kai's ursprüngliche Anforderung war ein gutes Radio, und dabei ging es nicht darum alles ein zu bauen, was eben noch passt, sondern eben, weil es sein Steckenpferd ist, guten Klang aus der Antenne auf die Boxen zu zaubern. Dadurch, dass nun vielleicht zwei Chips hinzu kommen und beim Prozessor eben nicht der Minimalistischste verwendet wird, gibt es einige, heute übliche, Features 'geschenkt', bzw. es sind für den geneigten Nachbauer noch ein paar Verbindungen, RAM und FLASH übrig um eigene Optionen zu ermöglichen. ARM7 oder ARM9 macht keinen Unterschied, wenn der ARM9 über genug eigenes FLASH verfügt um eine minimalistische Applikation zu bauen. Ich prüfe aber gerade eine Huckepack-Lösung um alternativ einen Controller mit eigenem Flash aufs Mainboard zu packen, alternativ kann man diesen Weg lassen und ein kleines Linux taugliches Board darüber stecken.
Harald L. schrieb: > Bevor das Gehäuse nicht steht, kannst du die Konstruktion des Mainboard > komplett vergessen. Allein die Lage der zu kühlenden Bauteile wird mass > geblich durch das Gehäuse bestimmt. Das selbe gilt für die Verbindungen > zur Aussenwelt. Da kommt noch hinzu, dass nicht jeder bereit ist, den Kabelstrang in seinem Dashboard zu zerrupfen. Also sollten die ISO-Anschlüsse auch da liegen, wo sie hin gehören. ISO Links, Antenne Rechts. Außerdem kommen noch die Befestigungskrallen hinzu, die seitlich vorne liegen sollten. Wird noch ne nette Aufgabe :)
Seennoob schrieb: > Was auch immer süß ist, ist so eine TI C54/c55xx DSP. > http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dsp§ionId=2&tabId=50&familyId=114 Wenn die Preise sich seid etwa 2 Jahren nicht deutlich geändert haben, willst Du die nötige Toolchain (Compiler, IDE und JTAG Adapter) für diese Dinger nicht bezahlen müssen. Da sind schnell 2k€ weg.
schlimmstenfals muss man mit Kabelpeitsche arbeiten, und Adapterkabel aus dem Zubehörhandel anflanschen. Ein Spaß wird das aber auch nicht, bei Strömen im 2stelligen A-Bereich. Passende DIN-Einbaustecker dürften nicht leicht zu finden sein; wer braucht sowas außer die Autoradio-Hersteller? Und da hat auch jeder was eigenes. Vielleicht gibt es ja sowas im Car-PC-Bereich zu kaufen...da hab ich noch nicht geschaut. Harry
Ulrich ich werd ab August beruflich auch Richtung TI DSP gehen die sind da sehr "Günstig" mit der Entwicklungsumgebung im Vergleich zu anderen Herstellern noch eher günstig mit 1600€. Vielleicht kann man da auch noch etwas unterstützung von TI bekommen wegen der Entwicklungsumgebung. Mfg
Ja, 1600€ kommen hin, für eine Einzelplatzlizenz mit JTAG Adapter. Hoffentlich haben die an der IDE fleißig weiter entwickelt. Die CCS war nämlich damals grotten schlecht. Die stürzte ja noch öfter ab als Windows ohnehin schon. Hat aber auch gerne mal das ganze Windows mit sich gerissen. Aber 2 Jahre sind eine lange Zeit und die CCS2 war schon deutlich besser. Ich mach aber jetzt mal Haia! Gn8!
> Ich bin nach wie vor für ARM7!(bekannt, beherrschbar, beschaffbar, weit > verbreite, billig und völlig ausreichend) Also ich kenne keinen ARM7! Ist mir total unbekannt. Da kenne ich meinen SuperH besser, von dem habe ich naemlich schonmal ein Datenblatt gelesen. .-) Und billig, beschaffbar und beherschbar ist er auch. > Normalerweise fängt mit einem Lastenheft an, darauf erstellt man ein > Pflichtenheft. Das ist absolut richtig. Ich glaub ehrlich gesagt mittlerweile nicht mehr das die Sache noch was wird. Das Problem ist das es keine Boss gibt der sagen kann es so gemacht wird oder man soll sich einen anderen Job suchen. Es gibt zu viele unterschiedliche Moeglichkeiten die gleichwertig sind. Und unter Druck setzen kann man ja auch keinen. Ich bin jetzt von dem SuperH so begeistert das ich auf jedenfall etwas damit machen werde. Ob ein Autoradio oder was anderes ist mir relativ egal und davon werde ich mich auch nicht abbringen lassen. Olaf
Ich persönlich bin nach dem ich die Datenblätter gelesen habe, vom Super-H voll begeistert. ABER es gibt leider ein paar mächtige Hacken. - Beschaffung sieht nicht so einfach aus (muss vom anderen Ende der Welt importiertwerden) - IDE scheint nicht frei zu sein sondern nur TRIAL (verstößt gegen die Open-Scource-Regeln) - Am µ-Controller selbst gibt es einige Sachen die unter NDA fallen (verstößt gegen die Open-Scource-Regeln) Daher fällt, meiner Ansicht nach, der Super-H aus dem Rennen. :-( Die Alternative mit dem ARM ist da eher was für uns. > Passende DIN-Einbaustecker dürften nicht leicht zu finden sein; wer > braucht sowas außer die Autoradio-Hersteller? Und da hat auch jeder was > eigenes. Ich denke die Stecker und Buchsen sollten schon zum Auftreiben sein. Wenn es wirklich nicht klappen sollte dann steigen wir einfach auf 16-polige Modul Kupplungen um. Die bekommt man einfach und im Zubehör gibt es für kleines Geld den passenden Adapter. Stecker sind wohl unser gerinstes Problem ;-) > Harald das ist ned Planung was jetzt gemacht wird sondern mit Verlaub > eher eine Sammlung von Gehirn Abfall. Das nennt man Brainstorming und das ist innerhalb von so kurzer Zeit noch ein normales Stadium. ;-) Lg Pezi
> - Beschaffung sieht nicht so einfach aus (muss vom anderen Ende > der Welt importiertwerden) Nein, den kannst du bei Glyn kaufen. Auch in Kleinstueckzahlen von 10-20 Stueck. Ich hab da angerufen! > - IDE scheint nicht frei zu sein sondern nur TRIAL (verstößt gegen die > Open-Scource-Regeln) Die Programmierumgebung ist frei solange du nicht mehr als 256k Code erzeugst. Es gibt aber auch einen gcc und du kannst auch alles mit einem Makefile machen und dann bist ganz frei. Und im Gegensatz zu allen anderen Prozessoren bist du sogar richtig vogelfrei weil der Prozessor sein Programm aus einem externem SPI-Flash zieht das du einfach so programmieren kannst. Du brauchst also noch nichtmal irgendein spezielles Programmiergedoens. > - Am µ-Controller selbst gibt es einige Sachen die unter NDA fallen > (verstößt gegen die Open-Scource-Regeln) Es gibt genau eine Sache die darunter faellt. Das ist das SD-Karteninterface fuer die Anbindung der Karten im 4Bit-Modus. Aber absolut niemand hindert dich daran die Karte einfach an einem 1-Bit SPI-Interface zu haengen wie ihr das vermutlich an jedem anderen Controller auch machen wuerdet. BTW: Koennen eigentlich ARMs ueberhaubt eine Speicherkarte im 4Bit-Modus ansprechen? Und das ist da ohne NDA? > Daher fällt, meiner Ansicht nach, der Super-H aus dem Rennen. :-( Bis jetzt waren das IMHO nur vorgeschobene Argumente ohne Inhalt und Substanz. > Die Alternative mit dem ARM ist da eher was für uns. Ich glaub eher hier wird nach der Methode "Wat de Buer ni kennt dat freet he nie!" verfahren. Bloss mal nicht den eingefahren Weg verlassen.... > Ich denke die Stecker und Buchsen sollten schon zum Auftreiben sein. Nein, ich denke auch das dies ein Problem wird. Natuerlich ist es kein Problem irgendeinen Stecker aufzutreiben, aber es waere schoen wenn man diese genormten Stecker haetten wie sie seit kurzem bei allen Hersteller verwendet werden. Aber ausser durch ausschlachten eines alten Radios wird man da kaum dran kommen. Es waere vielleicht interessant solche Sachen wirklich auszuschlachten. Aus irgendeiner Witzkiste wie sie die Hersteller als Alibiradio in Neuwagen bei VW oder Opel eingebaut haben und die man vermutlich nachgeworfen bekommt. Und dann koennte man von da auch gleich das Blechgehaeuse verwenden. Es sollte halt nur ein gaengiges Modell sein das sich jeder besorgen kann. Olaf
Olaf schrieb: > BTW: Koennen eigentlich ARMs ueberhaubt eine Speicherkarte im 4Bit-Modus > ansprechen? Und das ist da ohne NDA? Ja, alle LPCs mit SD card interface. Ohne NDA. Evtl. setzt der SH da einfach auf einem niedrigeren Level an und man braucht deshalb die NDA. Oder Renesas ist einfach sehr vorsichtig. > Es waere vielleicht interessant solche Sachen wirklich auszuschlachten. > Aus irgendeiner Witzkiste wie sie die Hersteller als Alibiradio in > Neuwagen bei VW oder Opel eingebaut haben und die man vermutlich > nachgeworfen bekommt. Und dann koennte man von da auch gleich das > Blechgehaeuse verwenden. Es sollte halt nur ein gaengiges Modell sein > das sich jeder besorgen kann. Also die VW Dinger (Alpha/Beta/Gamma) sind selbst gebraucht noch relativ teuer, weiss nicht ob es da noch was anderes gibt. Aber da wir eh eine andere Front haben wollen bringt es doch wahrscheinlich eh nicht so viel wie man sich erwünscht. Eine Bezugsquelle für die Radioseitigen stecker für print-montage hab ich leider noch nicht gefunden, aber auch noch nicht besonders intensiv gesucht.
Angehängte Dateien:
-
BlockdiagramV2.png
84 KB
Was die CPU betrifft: Ich finde den SH gut, um nicht zu sagen sehr gut und es würd mich reizen mal eine neue CPU-Architektur zu programmieren (den SH werd ich also so oder so irgendwann mal mit eigener Software füllen)... ...aber aus einem Grund würde ich gerne den ARM7 bevorzugen und das ist einfach das mehr Leute das Ding kennen und für die meisten der Einstieg einfacher ist. Ich glaube auch das die meisten hier eher ARM programmieren. Ich habe mal an dem Blockdiagram weitergearbeitet und upgedated (werde es nachher noch ins WIKI packen). Dort ist ein möglicher ARM7 gelistet. Also, dann "erschiesst" mich mal... Ansonsten was mir noch an offene Punkte auffällt: - Was für ein Frontpanel-Display (Um ein passendes Interface auszuwählen, z.b. SPI oder parallel) - Mechanisches Design, z.B. aluprofile für den Einschub - Bezugsquelle: vom MUX/sound controller. Oder Auswahl eines alternativen. Digikey und co haben den nicht lagernd. ein reiner sound controller würde reichen, den MUX kriegen wir einfach diskret aufgebaut. - Auswahl eines geeigneten I2S ADC/DAC oder CODEC - Auswahl eines Verstärkers. Ulrich hat da z.B. ein paar posts zurück einen geeigneten und beschaffbaren (Farnell) genannt. - Stromversorgung: Abschätzung der Leistungen für die einzelnen Spannungen und Design. Ich könnte mir ein gemischtes Buck converter/LDO Konzept vorstellen (z.B. die 3.3V aus den 5V, die 5V aus einem Schaltwandler, ...). - Bezugsquelle für Print "DIN Radio"-buchsen
> Ich glaub eher hier wird nach der Methode "Wat de Buer ni kennt dat > freet he nie!" verfahren. Bloss mal nicht den eingefahren Weg > verlassen.... Jij bedoeld zeker: "Wat de boer niet kent, dat eet hij niet". Is echt mal wieder faszinierend wie nah Platt an Niederländisch ist ;-)
> Also die VW Dinger (Alpha/Beta/Gamma) sind selbst gebraucht > noch relativ teuer, weiss nicht ob es da noch was anderes > gibt. Hm..haette ich jetzt nicht gedacht. > Aber da wir eh eine andere Front haben wollen bringt es doch > wahrscheinlich eh nicht so viel > wie man sich erwünscht. So eine Vorgehensweise haette den Vorteil das man wirklich die ganzen Blechteile, Seitenteile, Deckel, Klemmen usw verwenden koennte. Klar, niemand will etwas das wie ein VW Alpha aussieht. :-) Da muesste man dann halt das Blech begradigen und dort eine Halterung fuer die eigene Front schaffen. Mir gefaellt die Vorstellung soetwas zu machen auch nicht so ganz wenn man bedenkt das dies ja meherere Leute fuer einige Radios machen sollen/muessen. Aber wenn man so ein Radio fuern fuffi bekommt dann klingt das zwar erstmal nach viel Geld fuer so eine Witzkiste, aber das koennte trotzdem noch billiger sein als Blechteile zusammenzuschrauben und was eigenes zu machen. Noch besser waere es vielleicht soetwas auszuschlachten: http://www.amazon.de/dp/B002MPSTNG?m=A3JWKAKR8XB7XF&tag=idealocom Problem dabei ist natuerlich das man das in einem Jahr kaum noch nachkaufen kann wenn einer spaeter einsteigt. Hm...koennte sogar fast die Frage aufwerfen ob man nicht auch die Front verwenden kann und nur das Gehirn auswechselt. Modell Blaupunkt Frankenstein. :-D > - Auswahl eines geeigneten I2S ADC/DAC oder CODEC Das ist das naechste was ich brauche wenn ich mit der I2C-Programmierung fertig bin. Son mist, ich hab Codecs bis zum abwinken rumliegen, aber alles nur 8Bit. Seufz. Olaf
Olaf schrieb: > Nein, den kannst du bei Glyn kaufen. Auch in Kleinstueckzahlen von 10-20 > > Stueck. Ich hab da angerufen! Ok! Das ist natürlich was anderes. Ich hab halt nix gefunden. > Die Programmierumgebung ist frei solange du nicht mehr als 256k Code > > erzeugst. > > Es gibt aber auch einen gcc und du kannst auch alles mit einem Makefile > > machen und dann bist ganz frei. Und im Gegensatz zu allen anderen > > Prozessoren bist du sogar richtig vogelfrei weil der Prozessor sein > > Programm aus einem externem SPI-Flash zieht das du einfach so > > programmieren kannst. Du brauchst also noch nichtmal irgendein > > spezielles Programmiergedoens. > Es gibt genau eine Sache die darunter faellt. Das ist das > > SD-Karteninterface fuer die Anbindung der Karten im 4Bit-Modus. Aber > > absolut niemand hindert dich daran die Karte einfach an einem 1-Bit > > SPI-Interface zu haengen wie ihr das vermutlich an jedem anderen > > Controller auch machen wuerdet. > > BTW: Koennen eigentlich ARMs ueberhaubt eine Speicherkarte im 4Bit-Modus > > ansprechen? Und das ist da ohne NDA? Aber genau diese Sachen widersprechen den OpenScource-Gedanken. >> Daher fällt, meiner Ansicht nach, der Super-H aus dem Rennen. :-( > > Bis jetzt waren das IMHO nur vorgeschobene Argumente ohne Inhalt und > > Substanz. Ist halt meine Meinung. ;-) > Ich glaub eher hier wird nach der Methode "Wat de Buer ni kennt dat > > freet he nie!" verfahren. Bloss mal nicht den eingefahren Weg > > verlassen.... Wenn man was nicht kennt läuft man schnell in die Gefahr das etwas schief geht. > Es waere vielleicht interessant solche Sachen wirklich auszuschlachten. > > Aus irgendeiner Witzkiste wie sie die Hersteller als Alibiradio in > > Neuwagen bei VW oder Opel eingebaut haben und die man vermutlich > > nachgeworfen bekommt. Und dann koennte man von da auch gleich das > > Blechgehaeuse verwenden. Es sollte halt nur ein gaengiges Modell sein > > das sich jeder besorgen kann. ACK!
Also ich habe schon einige Radios gesehen und muss feststellen, dass die Leiterplatten von den Formaten her sehr dicht bei einander liegen. Das kann man also im Design berücksichtigen und an der Außenkante ein paaar mm Luft lassen. Dann kann man die nötigen Ecken noch rein feilen, bzw. die nötigen Bohrungen anbringen. Zum Thema CPU/TUNER/MIXER: Es ist villeicht möglich, dass man einen Hersteller überredet bekommt auch die guten Bauteile raus zu rücken, wenn man alle Chips aus seinem Haus nutzt, also quasi ein Referenz-Design entwickelt. Es wäre schließlich eine Art Werbung für ihn. Eventuell legt er ja auch etwas Support oder Code-Schnipsel oben drauf. Das ganze wird aber nur dann funktionieren, wenn man es unter BSD, nicht aber unter GPL macht. Sonst hat der Hersteller ja nix davon. Frontpanel Anschluss: 3.3V für Logic 5V od. 8V für LED/OLED/LCD Driver SPI für grafische Displays I2C für Tasten, LED control 2xPWM für Backlight, Contrast GND macht 12 Pinne bei GND auf zwei Pinne Man kann auf die PWM verzichten, wenn man einen I2C Controller oder ein 'intelligentes' Display einsetzt, wo man diese Parameter konfigurieren kann. Mainboard CPU: Wie sieht es mit einem 'Betriebssystem' für die verschiedenen CPUs aus? Wollen wir alles von Hand machen oder lieber auf einen schon mal passenden Rahmen aufsetzen, so dass einige nach unten hin die Treiber programmieren und andere ncoh oben hin die Applikation? Da es zwischen diesen beiden Welten eine recht klar definierte und durch das System vorgegebene Schnittstelle gibt, werden die beiden Welten vermutlich besser zusammen arbeiten. Mein Vorschlage war ja Nut/OS, aber es ist noch nicht auf LPC2xxx portiert, auch wenn etwas passendes bereits seid ein paar Wochen bei mir herum liegt. Was geht ist SAM7-Serie, SAM9-Serie und AVR32-Serie. Was kommen wird ist STM32-Serie und LPC-Serie, ersteres muss ich machen (Brötchen), letzteres möchte ich machen (Spaß). IDE oder nicht IDE, Frei oder Beschränkt. Ich persönlich lege bei dem verwendeten Chip mehr Wert auf gcc, gdb und openocd, als auf eine schöne fette IDE. Ich programmiere ausschließlich mit SourceInsight als Editor, auch mittels Wine unter Linux. Mit einer limitierten IDE kann man in dem Moment schnell nix mehr anfangen, wenn der Code für andere Chips Blobs (Code, der in einen anderen Chip transferiert wird) enthält und damit schnell mal über 256kB anwächst. Dito gilt für Grafiken für das Frontpanel oder Tabellen für Software-Decoder, -Filter. Ja, man kann vermutlich die IDE-Internen Makefiles so drehen, dass die Tabellen und Blobs nachträglich gelinkt werden oder man baut ein Script, dass die HEX files zusammen pfercht. Sicher, aber wer versteht das nach einem Jahr dann noch alles. Gruß, Ulrich
> Aber genau diese Sachen widersprechen den OpenScource-Gedanken. Darf ich daraus schliessen das generell kein Microsoftbetriebsystem fuer die Entwicklung verwendet werden darf weil das nicht Opensource ist? Fuer mich besteht open source darin das du dir spaeter die Sourcefiles downloaden kannst. Und du kannst dir dann sogar aussuchen womit du sie uebersetzt. Und wenn den Leuten hier andauernd einer abgeht vor Angst, warum installieren sie sich dann nicht den gcc? Es gibt ihn ja. Und der laesst sich bestimmt auch mit make benutzen. > Wie sieht es mit einem 'Betriebssystem' für die verschiedenen CPUs aus? Ich hatte mich mit Kai schonmal darueber unterhalten. Ergebnis war wohl in etwa, wir sind uns nicht ganz schluessig. :-) Ich bin auf der einen Seite sehr stark gegen ein Betriebsystem. Es kostet nur unnoetig Resourcen, macht einem Probleme beim Timing und bringt keine Vorteile weil man die Aufgaben die ein Betriebsystem normalerweise erledigt in einer Ein-Programm-Hardware nicht benoetigt. Andererseits leuchten auch mir ein paar kleinere Vorteile, besonders bei der Arbeitsteilung ein. Ich programmiere auf meinem SuperH gerade I2C, und habe bereits RS232 programmiert. Dabei achte ich darauf das die Funktionalitaet versteckt wird und ueber Buffer im Hintergrund in Interrupts laeuft. So sollten beliebige Funktionen ohne Ruecksicht solche Basisfunktionen nutzen koennen. Ich bin mir noch nicht ganz klar ob das klappt, aber so moechte ich vermeiden das man ein Betriebssystem braucht. Die wirklich wichtigen Sachen wie das verschieben der Audiodaten werden ja wohl sowieso von einer DMA Hintergrund gemacht. > Mit einer limitierten IDE kann man in dem Moment schnell nix mehr > anfangen, wenn der Code für andere Chips Blobs (Code, der in einen > anderen Chip transferiert wird) enthält und damit schnell mal über 256kB > anwächst. Nicht das ich es fuer notwendig halte, aber dir ist schon klar das man bei einem Konzept wie dem des SH7262 mit externem SD-Flash und externer SD-Karte und Bootloader im Source, beliebige Anwendungen und Teile jederzeit nachladen kann? Insbesonders das laden von der SD-Karte wuerde mit zu den ersten Sachen gehoeren die ich machen wuerde weil ich nicht immer meinen Laptop ins Auto schleppen moechte. Da waere es doch viel besser wenn ein Fenster aufgeht und man gefragt wird welche der fuenf Firmwareversionen auf der SD-Karte man heute probieren moechte. > Sicher, aber wer versteht das nach einem Jahr dann noch alles. Hm..die Idee von Projecten unter HEW ist es gerade sich solche Sachen zu merken. Und wenn man ueber Makefiles eins sagen kann, dann doch wohl das sie in der automatisierung von Prozessen noch leistungsfaehiger sind. Aber 256kb Code in einem Autoradio? Das bekommt man niemals voll. Jedenfalls nicht bei der Art Radio wie ich es mir vorstelle... Olaf
Für die Arme gibts ne Toolchain komplett kostenlos. Das einzige, was man dann noch kaufen muss ist nen popeliger JTAG Adapter für 25€...
Sven H. schrieb: > Für die Arme gibts ne Toolchain komplett kostenlos. Das einzige, was man > dann noch kaufen muss ist nen popeliger JTAG Adapter für 25€... Auf was beziehst du dich jetzt ?
Olaf schrieb: >> Aber genau diese Sachen widersprechen den OpenScource-Gedanken. > > Darf ich daraus schliessen das generell kein Microsoftbetriebsystem fuer > die Entwicklung verwendet werden darf weil das nicht Opensource ist? > Quatsch! - es geht um die Entwicklungsumgebung/Toolchain. Ob du die unter Linux, Windoof oder Commodore-Basic verwendest spielt keine Rolle > Fuer mich besteht open source darin das du dir spaeter die Sourcefiles > downloaden kannst. Und du kannst dir dann sogar aussuchen womit du sie > uebersetzt. Und wenn den Leuten hier andauernd einer abgeht vor Angst, > warum installieren sie sich dann nicht den gcc? Es gibt ihn ja. Und der > laesst sich bestimmt auch mit make benutzen. > und was ist mit debugging? Ist ja toll, wenn dir Renases einen 1k€ treuren Debugger schenkt – nur wir Anderen haben da leider gar nicht von... > Ich bin auf der einen Seite sehr stark gegen ein Betriebsystem. Es > kostet nur unnoetig Resourcen, macht einem Probleme beim Timing und > bringt keine Vorteile weil man die Aufgaben die ein Betriebsystem > normalerweise erledigt in einer Ein-Programm-Hardware nicht benoetigt. > ...jaja...was der Bauer nicht kennt.... > Andererseits leuchten auch mir ein paar kleinere Vorteile, besonders bei > der Arbeitsteilung ein. > > Ich programmiere auf meinem SuperH gerade I2C, und habe bereits RS232 > programmiert. Dabei achte ich darauf das die Funktionalitaet versteckt > wird und ueber Buffer im Hintergrund in Interrupts laeuft. So sollten > beliebige Funktionen ohne Ruecksicht solche Basisfunktionen nutzen > koennen. Ich bin mir noch nicht ganz klar ob das klappt, aber so moechte > ich vermeiden das man ein Betriebssystem braucht. > Die wirklich wichtigen Sachen wie das verschieben der Audiodaten werden > ja wohl sowieso von einer DMA Hintergrund gemacht. > Und wo ist der Unterschied zu einem Minimal-OS, wenn du ohnehin eine oder mehrere Abstraktionsebenen definierst? Kennst du überhaupt andere Betriebssysteme ausser Windows? Solche "Frameworks" zu benutzen ist "Stand der Technik". Das sollte auch dir klar sein! Ausserdem kann man bei einem solchen Projekt sehr wohl von Dingen wie Task-Scheduler etc profitieren. >> Mit einer limitierten IDE kann man in dem Moment schnell nix mehr >> anfangen, wenn der Code für andere Chips Blobs (Code, der in einen >> anderen Chip transferiert wird) enthält und damit schnell mal über 256kB >> anwächst. > > Nicht das ich es fuer notwendig halte, aber dir ist schon klar das man > bei einem Konzept wie dem des SH7262 mit externem SD-Flash und externer > SD-Karte und Bootloader im Source, beliebige Anwendungen und Teile > jederzeit nachladen kann? s.o.: was ist mit debuggen? > Aber 256kb Code in einem Autoradio? Das bekommt man niemals voll. > Jedenfalls nicht bei der Art Radio wie ich es mir vorstelle... > und wozu dann so eine fette CPU auf dem Mainboard??? Harry
seennoob schrieb: > Sven H. schrieb: >> Für die Arme gibts ne Toolchain komplett kostenlos. Das einzige, was man >> dann noch kaufen muss ist nen popeliger JTAG Adapter für 25€... > > Auf was beziehst du dich jetzt ? Ich hab beim durchlesen des kompletten Threads das ein oder andere Mal Bedenken zu Kosten für die Entwicklungsumgebung gesehen und da dachte ich, wäre es erwähnenswert...
Sven H. schrieb: > seennoob schrieb: >> Sven H. schrieb: >>> Für die Arme gibts ne Toolchain komplett kostenlos. Das einzige, was man >>> dann noch kaufen muss ist nen popeliger JTAG Adapter für 25€... >> >> Auf was beziehst du dich jetzt ? > > Ich hab beim durchlesen des kompletten Threads das ein oder andere Mal > Bedenken zu Kosten für die Entwicklungsumgebung gesehen und da dachte > ich, wäre es erwähnenswert... Billig oder teuer kann man das heut noch so leicht sagen ? Für einen ist eine IDE für 500€ noch billig und ein anderer will alles opensource haben das er ja nix zahlen muss. Wenn man mit neuer HW arbeiten will ist es oft nix mit gcc usw.
seennoob schrieb: > Für einen ist eine IDE für 500€ noch billig und ein anderer will alles > opensource haben das er ja nix zahlen muss. > > Wenn man mit neuer HW arbeiten will ist es oft nix mit gcc usw. Eben!....und dann wäre es kein "OpenSource-Projekt" mehr.... http://de.wikipedia.org/wiki/Open_source Harry
> Quatsch! - es geht um die Entwicklungsumgebung/Toolchain. Ob du die > unter Linux, Windoof oder Commodore-Basic verwendest spielt keine Rolle Aber das Betriebsystem ist doch Teil der Entwicklungsumgebung. Wie kannst du dich daran stoeren das der Compiler von einer kommerziellen Firma ist, aber das Filesystem und die Grafikoberflaeche ist dann auch nicht frei? > s.o.: was ist mit debuggen? Du kannst dir kein USB-KAbel leisten? Mehr brauchst du nicht. Oder bist du lernresistent weil ich das bereits mindestens zweimal in epischer Breite erklaert habe? Olaf
Olaf schrieb: >> Quatsch! - es geht um die Entwicklungsumgebung/Toolchain. Ob du die >> unter Linux, Windoof oder Commodore-Basic verwendest spielt keine Rolle > > Aber das Betriebsystem ist doch Teil der Entwicklungsumgebung. Wie > kannst du dich daran stoeren das der Compiler von einer kommerziellen > Firma ist, aber das Filesystem und die Grafikoberflaeche ist dann auch > nicht frei? > Wenn die Toolchain frei ist, kann ich die auf nahezu beliebige Betriebssysteme portieren. >> s.o.: was ist mit debuggen? > > Du kannst dir kein USB-KAbel leisten? Mehr brauchst du nicht. > > Oder bist du lernresistent weil ich das bereits mindestens zweimal in > epischer Breite erklaert habe? > Ja!...und ich habs auch gefühlte 100mal erklärt: wenn der einzige verfügbare Debugger "closed Source" UND eine "kastrierte Trial-Version" ist, die mir auch noch das OS vorschreibt, ist das eben NICHT offen!!!! Falls du es noch nicht mitbekommen hast...ich arbeite mit Linux!..ausschliesslich mit Linux!!! Entweder, wir benutzen Software, die4 JEDER benutzen kann, egal, ob Windoof MacOS oder Linux, oder wir lassen es....nur ist es dann kein OpenSource mehr, und ich bin raus! Harry
Harald L. schrieb: > und ich bin raus! Du warst noch nie drin. open source deiniert sich nicht über die verwendeten Tools, Prozessoren oder Betriebssysteme oder sonstige Nebensächlichkeiten wie Wunschlisten oder gar Wunschlistenersteller. open source definiert sich über diejenigen, die etwas realsieren und es zur Verfügung stellen. Da gilt die brutale Kraft des Faktischen. Wer etwas tut, setzt die Standards. Und wenn Kai am Ende eine Platine entwirft, nimm sie, wie sie ist, oder mach selber eine neue (wenn du kannst). Wie bei 99,999% aller allen anderen open-source-projekte auch. sourceforge ist voll davon. Die kanpp zwei Dutzend lebdenden Projekte, bei denen das anders ist (linux, gcc, apache, etc.), kann man da vernachlässigen. Oliver
Oliver schrieb: > Harald L. schrieb: >> und ich bin raus! > > Du warst noch nie drin. > Ach?.....aber du?...oder was willst du mir damit sagen? "drin" sind imho die, die sich für das Projekt stark machen, und was dazu beitragen.... > sourceforge ist voll davon. Die kanpp zwei Dutzend lebdenden Projekte, > bei denen das anders ist (linux, gcc, apache, etc.), kann man da > vernachlässigen. Ach!..."vernachlässigen"???....soso! Diese Projekte sind deshalb so erfolgreich, WEIL der OpenSource-Gedanke hier voll zum Tragen kommt! Harry
Ich möchte diese Diskussion aus den letzt paar Posts an dieser Stelle beendet sehen, ich denke das dieser Eingriff in die Diskussion auch im Sinne des Thread-Openers ist, sonst möge er mir verzeihen. Die Plattform wird so ausgelegt, dass gcc verwendet werden kann. Es wird nicht nötig sein, eine IDE vorzuschreiben. Es wird nicht nötig sein mehr als ein paar Euro für einen Programmer/Debugger auszugeben, so er nicht ohnehin schon vorhanden ist. Wenn keine der möglichen Chiplieferanten sich zu einer Art Sponsoring überreden lässt, wird die Plattform selbst ohne Gehäuse bei geschätzten 200..300€ liegen, und da sind wir uns noch nicht mal Sicher, ob da schon ein schönes Display mit drinn ist. Daher wird es ein JTAG ala openocd-usb o.Ä. tun müssen um zum einen die Systemkosten nicht noch weiter explodieren zu lassen und außerdem etwas zu haben, was man später auch für andere Projekte nutzen kann. Wer unter Linux entwickeln will, wird das tun können, wer unter Windows entwickeln will, wird das auch tun können. Unter MAC-OS fehlt mir die Erfahrung um dazu was zu sagen, vermutlich gibt es aber auch eine Lösung dafür, wie es Yagarto für Windows ist. Damit ist dieser Punkt geklärt.
Oliver schrieb: > Harald L. schrieb: >> und ich bin raus! > > Du warst noch nie drin. > Solche Posts sind insgesammt im uc.net nicht gerne gesehen. Bitte ändere Deinen Ton ein wenig. Danke! Deine Ausführungen zur Definition von open-source sind nur teilweise richtig. Es ist entscheidend ob jemand, der den open-source-code nutzen möchte mit vertretbarem Aufwand auch dazu in der Lage ist. Wenn sich bei einem Projekt gleich von Anfang an interessierte und versierte Interessenten finden, die auf unterschiedlichen Plattformen arbeiten, dann ist es billig und recht auf diese Belange einzugehen. In dieser frühen Phase kann man ganz getrost entscheiden, ob eine CPU wegen solcher, in manchen Augen vielleicht banalen, Faktoren wie Betriebssystemvoraussetzung der IDE, drin ist oder raus. Das liegt im Ermessen der Projektbetreiber. In jedem Thread über Linux oder Windows finden sich Leute, die diese Diskussion um der Diskussion willen anstacheln, hier nicht. Siehe Post von vorhin. An sonsten ist open-source eine schwammige Geschichte, auch open-source Code kann mit closed-source code vermischt sein, siehe diverse Treiber unter Linux. Wenn NXP uns zusichert, dass alle, die auf dieses Projekt referenzieren eine kostenlose IDE für irgendwas bekommen, dann ist das für mich auch open-source, wenn nur die vier Initiatoren diesen Luxus erhalten, ist es kein open-source, weil der Quelltext zwar offen wäre, aber niemand mehr ohne Zusatzkapital damit was anfangen kann.
Ulrich P. schrieb: > Solche Posts sind insgesammt im uc.net nicht gerne gesehen. Bitte ändere > Deinen Ton ein wenig. Danke! Ach je, wer wann was in den wilden Weiten des Internets oder auch im uc.net insgesamt oder auch ganz persönlich nicht gerne sieht, ist ziemlich belanglos. Aber um die Sache mal etwas deutlicher auf den Punkt zu bringen: Das hier ist bisher kein open source Projekt, und es wird auch niemals eins werden. Selbst wenn am Ende hier ein, zwei Spezialisten eine funktionsfähige Hardware erstellen, und das Ding auf dem Labortisch tatsächlich Musik empfangen sollte, und alle Unterlagen dazu auch noch unter GPL veröffebtlicht werden, wird es genau das blieben: Eine Bastelübung von ein bis zwei Spezialisten. Solange das alles auf für Privatpersonen nicht beschaffbaren Chips und nicht verfügbaren Entwicklungstools basiert, kann das noch so open source im Sinne von frei nutzbar sein, es wird niemals irgend jemand nachbauen, geschweige denn drann mitentwickeln. Es drängt sich mir eher der Verdacht auf, daß von dem einen oder anderen eine als Bausatz/Fertigplattform vermarktbare Basis für eine (dann vielleicht eher open-source-geeignete) Software geschaffen werden soll. Nun ja, warum nicht. Solange allerdings noch nicht einmal von den (anscheined sich selbst ernennenden) Projektleitern formuliert werden kann, was das Gerät am Ende aus ihrer Sicht besser/schneller/anders/billiger/schöner können kann, als ein Fertiggerät von Feinkost Albrecht-Wühltisch, ist das alles doch völlig zweckfrei. Ausser dem Selbermachen des Selbermachen willens hat so etwas keinen Sinn. In diesem Sinne Oliver
Oliver schrieb: > Ulrich P. schrieb: >> Solche Posts sind insgesammt im uc.net nicht gerne gesehen. Bitte ändere >> Deinen Ton ein wenig. Danke! > > Ach je, wer wann was in den wilden Weiten des Internets oder auch im > uc.net insgesamt oder auch ganz persönlich nicht gerne sieht, ist > ziemlich belanglos. > Genau!....und darum schreibst du hier auch anonym als Gast.. > unter GPL veröffebtlicht werden, wird es genau das blieben: Eine > Bastelübung von ein bis zwei Spezialisten. Solange das alles auf für > Privatpersonen nicht beschaffbaren Chips und nicht verfügbaren > Entwicklungstools basiert, kann das noch so open source im Sinne von > frei nutzbar sein, es wird niemals irgend jemand nachbauen, geschweige > denn drann mitentwickeln. > Wer bist du, daß du das so genau weisst? Du hast ja offensichtlich nichtmal den Tread vollständig gelesen. > Solange allerdings noch nicht einmal von den (anscheined sich selbst > ernennenden) Projektleitern formuliert werden kann, was das Gerät am > Ende aus ihrer Sicht besser/schneller/anders/billiger/schöner können > kann, als ein Fertiggerät von Feinkost Albrecht-Wühltisch, ist das alles > doch völlig zweckfrei. Ausser dem Selbermachen des Selbermachen willens > hat so etwas keinen Sinn. > und warum langweilst du uns mit deinen (anonymen) Posts, wenn dich das Projekt sowieso nicht interessiert? Harry
Es ist wie in der Liebe: Am Anfang schwebt man auf Wolke Sieben aber schon bald kommt das zerdepperte Geschirr ;-)
Das macht die Entfernung wenn man das Projekt zB gestartet hätte mit 2 bekannten oder so dann wären die ganzen anfänglichen Sachen schon ausdiskutiert gg
Sicherlich, aber wo bleibt der ganze Spaß? Ohne Kai wäre ich vermutlich nie auf den Dirana2 Chip gekommen, egal ob NXP ihn jetzt raus rückt, oder nicht. Kai wäre vielleicht nicht auf Nut/OS gekommen, Harald säße vielleicht allein auf einem SuperH, wer weiß. Jedes Projekt beginnt mit der Sammlung von Ideen unterschiedlicher Kompetenzen. Leider scheint das nicht allen klar zu sein und so quasseln sie völlig am Thema vorbei rein und ziehen das ganze in eine persönliche Richtung. Ist wie in einer großen Firma :) Tragen wir das doch einfach mit dem nötigen Humor. Wenn es ein Projekt für ein paar Spezialisten bleibt, was ist daran schlimm? Vielleicht reicht es bei dem einen, den Tuner nebst dessen Software zu verwenden, bei einem anderen hilft die I2C-Bus Implementation, der Dritte ist glücklich, weil er sich einen anderen Teil der Entwicklung zu Nutze machen kann. Ich habe auch mal in einem Thread über PID Regelung viel gelernt ohne mir da besprochene Motorsteuerung nach gebaut zu haben, ich wollte einen Kühler regeln. Ich bin, sobald das OSCAR gewisse Grundformen angenommen hat, diesen Thread zu schließen und einen neuen auf zu machen.
Kai G. schrieb: > Hallo! > > Ich wollte mal vorsichtig fragen ob es Leute gäbe die prinzipiell > Interesse daran hätten an einem noch nicht existierenden Open source > Projekt teilzunehmen bei dem es darum geht ein komplettes Autoradio zu > entwickeln. Sowas in der Richtung baue ich gerade... > Was mir vorschwebt: > - Optik: Das Radio sollte nicht wie ein "Ufo" aussehen Wie dann? > - Größe: Single DIN > - Evtl. eine Gehäusevariante für ein Stand alone radio (AKA > Küchen/Kofferradio) > - Es soll möglich sein eine komplette MP3 Sammlung inkl. Cover zu > speichern Ich verwende SDHC Karten und 32 Gbyte sollten auseichend sein > - Farbdisplay (soll auch MP3 cover anzeigen können) Wo bekomst DU ein TFT mit 8x3cm (mindestens) her? > - 2*Rotary button bedienung (Ähnlich Becker Grandprix) + ein paar feste > Funktionstasten Wo bekommst Du die Rotary buttons? Ich habe nur sockhe wie in den Handies gefunden. > - Radio features: > * FM only (Mittelwelle/Langewelle und co ist denk ich heutzutage nicht > mehr echt interessant) SiLabs Si4735 macht dann alles in einem UKW, KW, MW und LW und hat eine minimale Beschaltung > * Frequency diversity zur Empfangsverbesserung mit einer Antenne wäre > schön > * evtl. DRM (?) Ehm und die Lizenz? Paßt igendwie nicht mit OSS zusammen > * RDS, inkl. Follow me, Radio text (+), TA, EON RDS ist mm SiLabs Si4735 drin > * Evtl. TIM (Aufzeichnung von Verkehrsnachrichten wenn das Radio > eigentlich aus ist und wiedergabe wenn das Auto das nächste mal > gestartet wird). > * search tuning up/down > * automatische Suche nach den aktuell stärksten Sendern (inkl. > Aussortierung von dubletten auf Basis von RDS Infos) Ist ja irgendwie standard oder? > * Der Empfang sollte wirklich sehr gut sein. Gutes Groß- und > Kleinsignalverhalten. > * Abschaltbare Phantomspeisung (wichtig für "moderne" Autos, sonst ist > der Empfang sehr besch§$%) > * nur wenn Platz im Display ist: Senderlogogs sollten angezeigt werden Reine programmiersache > - "MP3"-funktion: > * MP3 Wiedergabe (alle Bitraten/VBR/ID3V1 und ID3V2 support) > * MP3s, evtl. andere codecs (OGG, FLAC, ... ?) VLSI Solutions: VS1053 (MP3 + sonstwas Lizenz bereits im Chip drin) > * Einfache und schnelle (!) Navigation durch große MP3 Sammlungen > (Evtl. Hierachie Artist/Album/Track) > * Datenspeicher: z.B. SDHC Karten. Es wäre auch denkbar mehrere Karten > gleichzeitig zu unterstützen um den Speicher zu erweitern. Alternativ: Ist ja wohl standard... > Ein USB OTG Host mit Mass storage support. Hat ja sowieso jeder Microcontroler bei 200MHz und mehr drin Ich verwende übrigends einen Atmel AT91SAM9263 > - Audio Optionen: > * 4 Kanal Verstärker (Evtl. Class-D) Maxim hat excelente ClassD 25W endstufen > * Fade / Balance > * Einfacher Equalizer Kann jeder I²S AudioCODeC > - Evtl. Bluetooth Hands free option Ich würde aber eine leistungsfähigen BlueTooth LMX9338 chip nehmen, damit man das Radio auch fernbedinen kann > - Design Grundsätze: > * Funktionen sollten leicht erreichbar sein (keine 3 fach > Shiftfunktionen auf Buttons, etc...) > * Die Reaktion auf Benutzerfunktionen sollten schnell erfolgen. Wenn > eine Funktion länger dauert sollte sie vor Beendigung schon eine > Reaktion auf dem Display zeigen. > - Sehr schön wäre auch die Möglichkeit um den CAN Bus von Autos mit > einzubinden um Sonderfunktionen wie z.B. PDC auf dem Radio anzuzeigen. > Sowas ist Herstellerspezifisch, man kann es jedoch in der Hardware > vorsehen und in Software auswählbar gestalten. > - Evtl. Optionen um andere selbst entwickelte Boards einfach in die > Hard- und Softwareumgebung einzubinden, z.B. Amateurfunk transceiver, > Datenlogger, ... > - OBD2 Diagnose Option / Anzeigen oder Loggen von Sensordaten? Hmmm, wennd as alles dazu kommen soll, würde ich einen TI OMAP 3530 empfehlen, allerdings auc nur, wel ich einem GSM/UMTS-Receiver mit drinn habe, der mir Video-Telefonie erlaubt, ein ImageSensoer Interface hat und mit einem ausklappbaren 5"7 Display umgehen kann. > Was haltet Ihr davon? Die Liste ist nur als Vorschlagliste zu verstehen > und natürlich nicht 100% fest. Nach dem heutigen Stand der Technik könnte ich die Liste verdreifachen und aus dem "Autoradio" eine "eierlegende Wollmilchsau" machen... > Das Decoding von MP3 kann man in der CPU machen, da gibt es einige Open > source projekte die fertigen code anbieten der schon auf ARM7 > controllern gut läuft. Vergiß es den streß ist es nicht wert! Einen Treiber für den VS1053 kann man schneller schreiben als die frickeleim mit den Liux Audio-CODECS > Da ich sowas ähnliches schon gemacht habe weiß ich sicher das solch ein > Projekt definitiv auch mit wenig Leuten (2) machbar ist, allerdings > würde ich sowas gerne mit mehreren Leuten zusammen machen. > So kommt man sicher auch noch auf andere gute Ideen und Sachen sind > einfacher zu realisieren weil man einfach nicht auf allen Gebieten ein > Experte ist. ;-) > Ich würde übrigens auch gerne wirklich alles Quelloffen machen, inkl. > der Hardware. Willkommen im Club! > Viele Grüße, > Kai Grüße Michelle
Hörmel schrieb: > Ähm aber hey ich will ja nix miesmachen hier aber wie issn des mitti ABE > bei so selbstbastelkram? > :-/ Also ich habe mittlerweile weit über 200 ABE's hinter mir sowie ein gutes dutzend Serienzlassungen. Für Autoradios sind die absolut nicht relevantund kosten so um die 400-600 Euro. Sollte bei dem Project eine Firma sich beteiligen und eine Serienzulassung für ein besimmtes baumuster beantragen, kostet das auch nur 2000-4500 Euro. Grüße Michelle
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.