Sven H. schrieb: > Kai G. schrieb: >>> * 2 MB Ram >>> * 16MB Flash >>> Notfalls würde bei Ram und Flash auch die Hälfte reichen, aber so hätte >>> man mehr Luft für zukünftige Entwicklungen. Mehr darf es natürlich immer >>> sein. >> >> Puh, das ist eine Menge und würd auf jeden fall Richtung externes >> Flash/Ram gehen. Ich dachte eher über kB, statt Mb nach... > > Da kann aber ein einsamer Programmierer lange dran rum programmieren ;-) Die "Selbstprogrammierer" müssen das RAM ja nicht bestücken... Für Linux ist das Vorraussetzung. Harry
Sven H. schrieb: >> Puh, das ist eine Menge und würd auf jeden fall Richtung externes >> Flash/Ram gehen. Ich dachte eher über kB, statt Mb nach... > Da kann aber ein einsamer Programmierer lange dran rum programmieren ;-) Mit Linux scheinbar schon ;-) Wenn man sagen wir mal so etwa 128KB RAM hat braucht man keine Kunstgriffe mehr, ohne Linux.
Patrick Weinberger schrieb: > Die Linux Seite hat den Vorteil > das nach kleinen Anpassungen des Kernel eine gute Schnittstelle zur > verfügung steht welche ein leichtes einarbeiten ermöglicht. Ob ich mit einem Kernel header file arbeite oder mit einem spi.h/i2c.h/xyz.h von "irgendwoanders" ist doch kein großer Unterschied. Die Build Umgebung und das nötige Wissen um mit Linux was zu machen ist doch viel komplexer. Für jemand der seit Jahren nichts anderes macht gut, aber für den normalen 0815-WinAVR Programmierer dürfte die andere Lösung deutlich einfacher sein. > Wenn man aber das Ganze auf mehrere Controller aufsplittet hat es den > Vorteil es ist einfaches Layout möglich. (nur QFP Gehäuse)Die Software > kann einfach auf mehrere Teilkomponenten aufteilen. > Nachteil man muss die HW wirklich kennen für jede änderung außer man > schreibt ein art OS -> mehr Aufwand als Kernel. Ein HAL reicht schon voll und ganz und den würde man so oder so bauen. Ich brauch keinen echten Treiber mit Device handles und co.
Kai G. schrieb: > Sven H. schrieb: >>> Puh, das ist eine Menge und würd auf jeden fall Richtung externes >>> Flash/Ram gehen. Ich dachte eher über kB, statt Mb nach... >> Da kann aber ein einsamer Programmierer lange dran rum programmieren ;-) > > Mit Linux scheinbar schon ;-) > Wenn man sagen wir mal so etwa 128KB RAM hat braucht man keine > Kunstgriffe mehr, ohne Linux. Ich glaube nicht, daß ich der Einzige bin der so denkt, aber ohne die Möglichkeit ein Linux auf das Radio zu bringen, wär das Projekt für mich absolut uninteressant. Ich seh da keinen Mehrwert zu käuflichen Lösungen. Ausserdem ist die Hardware inzwischen so billig geworden, daß es ohneweiteres vertretbar ist, die Hardware deutlich überzudimensionieren. Son Radio ist ohnehin nicht in ein paar Monaten aufgebaut. Das wird ne grössere Baustelle. Daher meine ich, daß man sich auch bei den Möglichkeiten (Software) eher am "Morgen", als am "Heute" orientieren sollte. Ansonsten laufen wir Gefahr, daß das Gerät schon veraltet ist, bevor der 1. Prototyp läuft. Harry
Warum immer lang alles neu machen ? Man kann ja mal bei anderen Projekten fragen wegen unterstützung. Mir fällt da das Beagleboard ein. Gibt sicher noch andere...
Für mich stellt sich momentan die Frage wieviele hier dann auf der Linux Ebene mithalten können. Ganz ehrlich, ich nicht. :( Harld L. schrieb: > ich will ja keinen kompletten Car-PC (dann wär ich auch in einem anderen > Forum) - Ich will Linux in meinem Autoradio, um das nach meinen > Vorstellungen anpassen zu können. Genau das ist eigentlich die Idee die hinter einem Car-PC steckt. ;) Harald L. schrieb: > Kai G. schrieb: > >> Naja, wenn dann vorschläge wie externer Kopfstützenmonitor für Kinder > >> kommt und so, dann wird aber auch die Hardwareplattform schon extrem > >> anders aussehen. > > > > man wird ja wohl noch träumen dürfen ;)...aber andererseits reicht eine > > Ethernetschnittstelle um sowas nachzurüsten. Und Ethernet halte ich eh > > für Pflicht. Für was braucht man eine Ethernet-Schnittstelle im Auto? Und Kopfstützenmonitore kommen sicher nicht. Wir wollen ja ein Radio bauen und keinen Videoplayer. ;-) lg Pezi
Patrick Weinberger schrieb: > Warum immer lang alles neu machen ? > > Man kann ja mal bei anderen Projekten fragen wegen unterstützung. > > Mir fällt da das Beagleboard ein. > > Gibt sicher noch andere... Das Beagleboard halt ich jetzt eher für einen technischen Overkill. Und wenn man bedenkt was dann noch alles dazukommt viel zu teuer. Meiner Meinung nach sollten wir uns eher auf ein einfaches und modular erweiterbares Radio konzentrieren. Vielleicht sollten wir uns auch mal überlegen was wir eigentlich wollen. Danach sehen wir welche Methode und Plattform wohl die Beste ist. Ich fange mal mit einer Wunschliste an: - UKW-Empfang - RDS inkl. aller Funktionen wie TA,TP,Follow Me, RadioText, ect - evtl. DAB - Empfang auch bei 200km/h auf der Autobahn - Übertragung von Daten via USB
Für die ohne Linux: Bevor wir jetzt noch mal alle unsere Wunschliste posten, sollten wir eine wiki Seite anlegen (intern/extern), wo alles aufgelistet wird und anschließend mit Strichen gewählt wird. Sonst verlieren sich die Wünsche im Sande. Für die Leute mit Linux gibt es schon eine: http://osar.it-livetalk.de, die sollten ebenso wählen
Wenn es einen guten Empfänger und einen Signalpfad bis zur Endstufe gibt, die über eine Standardschnittstelle (UART, SPI,...) konfiguriert werden würde mich das Projekt interessieren. Richtig genial wäre die Fähigkeit ständig eine Liste der empfangbaren Sender zu haben wie bei Becker mit dem 2. Empfänger. Dann noch ein Ausgang mit dem Tunersignal und einige Eingänge für zusätzliche 'externe' Audioquellen und ich wäre begeistert. Damit könnten die Linux-Freunde einen Linuxrechner für das Bedien- interface und zusätzliche Funktionen benutzen, die Car-PC-Fraktion könnte das Modul auch benutzen und alle anderen verwenden einen Controller ihrer Wahl für die Steuerung. Das mehrfach angesprochene Problem des Gehäuses sehe ich auch, allerdings zeichnet sich ja schon ab das hinsichtlich Bedienung die Vorstellungen ja auch deutlich auseinander gehen. Für mich wäre evtl. ein geschlachtetes Radio + evtl. noch ein zusätzliches Display eine Option.
Ich denke, das wichtigste ist im Moment, sich auf eine Hardwareplatform zu einigen, mit der beide Fraktionen leben können. Sowas wie das Beagleboard find ich gar nicht so übel, und als "Overkill" seh ich das auch nicht. Reserven zu haben kann ganz sicher nicht schaden. Aber in dem Punkt will ich mich nicht festlegen, solange Linux darauf läuft ohne grosse Verrenkungen machen zu müssen.
Hi, was mir gerade noch bzgl. der Bedienung einfällt: Die Bedienung mit zwei Drehgebern gefällt mir, warum nicht den nicht-Lautstärke-Drehgeber mit einem Steuerkreuz erweitern? Also ähnlich wie die Mittelkonsolenbedienung in verschiedenen Audis, also: - Drehen - Drücken - Schieben (oben, unten, rechts, links) Wo es solche Bedienelemente zu kaufen gibt, weiß ich nicht. Allerdings kann ich mir mit etwas Geschick auch einen Eigenbau vorstellen: Drehgeber auf eine Platine, die mit einer weiteren mit einem flexiblen Element verbunden (Sandwich) ist. Dort befinden sich 4 Taster, die je nach Kippen geschlossen werden. Problematisch: Durch hineindrücken können bei druckelastischer Verbindung die Taster fehlerhaft ausgelöst werden. Um das Problem zu umgehen (und wahrscheinlich auch einen besseren Druckpunkt zu bekommen) könnte man die Taster stehend an einer Platine befestigen, die auf die Achse des Drehgebers angebracht wird, also in etwa so: +-----+ | # | |# o #| | # | +-----+ #: Taster o: Achse des Drehgebers Bei der Bedienung könnte ich es mir wie folgt vorstellen: Drehen: (fällt mir gerade nix ein) Rechts/Links: Titel vor/zurück Oben/Unten: Album vor/zurück Drücken: Titelmenü im Titelmenü, Beispiel Titelsuche: Drehen: Buchstabe auswählen Rechts/Links: Position Oben/Unten: Suchart (Titel, Interpret, Album, Genre) Drücken: Suche starten
Noch ein Einfall: Anbindung an den Infotainment-Bus? Sprich: Anbindung an die Lenkradfernbedienung und das Infodisplay (oder HUD ;)) zwischen den Tachos, haben ja mittlerweile nahezu alle Autos (zumindest als Sonderausstattung)
Aber OMAP ist für die Firmware bastler nicht wirklich was weil er schon komplex wird, aber ich finde das ist die beste MPU mit echt Zukunft für so ein Projekt. MFG
Patrick Weinberger schrieb: > Aber OMAP ist für die Firmware bastler nicht wirklich was weil er schon > komplex wird, aber ich finde das ist die beste MPU mit echt Zukunft für > so ein Projekt. > > MFG ACK
Ich muss ehrlich zugeben ich hab mal nach einer alternative zum OMAP gesucht aber das lässt sich ned viel finden. Entweder man muss min 5000 Prozessoren nehmen oder teure Software dafür. Von Renesas gibts was in die Richtung und die anderen ähnlichen verdächtigen. EMV mäßig haben sie auch Vorteile mit der PoP technologie. Wo direkt über dem Prozessor der RAM montiert wird. Der Flash kann dann langsamer getaktet werden. MFG
Wie wärs denn, wenn man eine "kleine" CPU mit den Abmessungen und Anschlüssen des Beagleboard (identische Abmessungen und Lage der Stecker) designen würde, was dann Huckepack auf die Hauptplatine kommt. Dann kann jeder selbst entscheiden, ob er ein Beagleboard, oder eine einfachere CPU haben möchte. Das würde ja dem Modul-Gedanken auch sehr entgegen kommen. Harry
Naja Beagleboard selbst ist in meinen Augen ungeeignet. Weil es nicht für Audio ausgelegt ist. Daher würd ich mich mal eher mit den Entwicklern des Beagleboards zusammenschließen. Denn da ist das Know-How für so ein vorhaben da (erfahrung mit dem Layout für so ein Monster). Alternativ würde vielleicht das IGEPv2 gehen. Das Problem ist das nur 2 I2S Schittstellen zur verfügung stehen bei dem Beagleboard oder IGEPv2. Wobei die OMAP Serie 5 zur Verfügung stellt. Mal ein Beispiel: Bluetooth einen I2S Verstärker einen I2S LineIn/AUX und Cinch Ausgang einen I2S dann vielleicht noch ein oder 2 Mikrofone einen I2S dann will noch einer SPDIF bedeutet auch wieder einen I2S also würden Fast alle I2S benötigt MFG
Patrick Weinberger schrieb: > Bluetooth einen I2S Die Bluetoothmodule die ich so gesehen habe haben alle einen rein analogen Eingang. Das vereinfacht den Entwicklern der Module so einiges, denn Sie müssen keinen Samplerateconverter entwickeln, erst recht keinen der verschiedene Sampleraten und UP/Down conversion unterstützt. > Verstärker einen I2S Verstärker sind normalerweise analog. Selbst neuere Sigma-Delta Verstärker (Class D) haben nur einen analogen Eingang. > LineIn/AUX und Cinch Ausgang einen I2S LineIn/Aux und Chinch Ausgang ist auch etwas rein analoges, wieso sollte man den Umweg über AD/DA gehen?
Patrick Weinberger schrieb: > Naja Beagleboard selbst ist in meinen Augen ungeeignet. Weil es nicht > für Audio ausgelegt ist. Daher würd ich mich mal eher mit den > Entwicklern des Beagleboards zusammenschließen. Denn da ist das Know-How > für so ein vorhaben da (erfahrung mit dem Layout für so ein Monster). es muss ja nicht das Beagleboard sein. Ausserdem hatten wir bereits diskutiert, daß wir die Audiofunktionen nicht in der HauptCPU machen, sondern für die HiFi-Freaks optional ein DSP-Modul vorsehen. Die von der Firmware-Fraktion bevorzugten CPUs wären damit sicher überfordert. > Alternativ würde vielleicht das IGEPv2 gehen. Das Problem ist das nur 2 > I2S Schittstellen zur verfügung stehen bei dem Beagleboard oder IGEPv2. > Wobei die OMAP Serie 5 zur Verfügung stellt. > > Mal ein Beispiel: > > Bluetooth einen I2S > Verstärker einen I2S > LineIn/AUX und Cinch Ausgang einen I2S > dann vielleicht noch ein oder 2 Mikrofone einen I2S > dann will noch einer SPDIF bedeutet auch wieder einen I2S > > > also würden Fast alle I2S benötigt Das wäre aber auch das KO-Argument für Linux. Ich stell es mir schwierig vor, in einer selbstgeschriebenen Firmware 5 Audiostreams(alle mehrkanalig) zu bedienen. Die Audio-Möglichkeiten liessen sich auch noch ganz anders erweitern: Würde ich mir heute an so einem Radio einen Zusatzverstärker anschliessen wollen, würde ich mir ein USB-Kabel in den Kofferraum legen, und dort einen USB_Audio-Stick verwenden. Das ergibt kurze Audio-Leitungen, und wenig Störungen. (Ich liebe die Dinger, und verwende die auch, um meinen PC-Sound über die HiFi-Anlage wiederzugeben - Der hat sogar S/PDIF) Harry
Also, meine Meinung um eine Lösung für die 2 Lager zu finden: Ich denke man wird nicht so einfach alles unter einen Hut bekommen, das haben auch schon viele andere hier gesagt. Meiner Meinung nach sollte man ein Basis Autoradio entwickeln das sich über eine API steuern lässt (z.B. über RS232) und auch ohne Display/Tasten arbeitet. Dazu kann in die echte linuxfreie Autoradiofirmware ein startup check erfolgen der testet ob ein Display/TastenuC angeschlossen ist und wenn nicht, dann arbeitet es in einem reinen API Modus. Basierend auf dem System kann die Car-PC Fraktion das Multimediasystem entwickeln. Man kann von mir aus z.B. vorsehen ein vorgegebenes Modul in die Platine des Basis Autoradio zu stöpseln, wenn es nicht gerade die Ausmasse von einem A5 Blatt oder so hat. Wobei das Radio an sich flach sein wird und der Platz nicht so sehr begrenzt ist, abgesehen von der Endstufe und der Spannungsversorgung. Da sich das Autoradio auch ohne Display/Tasten betreiben lässt bleibt dann den Leuten die Linux + Touch panel haben wollen etwas nach eigenen Vorstellungen zu entwickeln ohne die Möglichkeit zu rauben von dem Autoradio an sich zu profitieren. Das entkoppelt die Arbeit immens und generell entspricht das doch auch eher der angesprochenen Modulbauweise. In einen PC steckt man doch auch eine TV-Tunerkarte. OK, hier ist es umgekehrt, aber im Prinzip ist es doch wieder dasselbe. Zu der Featureliste: Ich würde 2 getrennt Featurelisten vorschlagen, daher hatte ich im Wiki schon eine Trennung vorgenommen. Es wäre wirklich gut wenn man eine Art Strichliste machen könnte, bzw. Features hinzufügen (keine löschen und JEDER NUR 1 KREUZ, äähhhh STRICH PRO FEATURE!). Hier noch mal die URL von Harald: http://osar.it-livetalk.de/index.php/Hauptseite Zum Namen: OSCAR ist evtl. auch nicht schlecht als Name. Open source CAR radio. Ist so schön rekursiv...
@Kai Einverstanden!!!! allerdings gehört MP3 dann auch auf ein separates Modul (was ein Linuxer ja gar nicht benötigt) Harry
Ich finde dieses Projekt echt super, auch wenn ich noch kein Auto fahre, dauert leider noch 1-2 Jahre. Ein wichtiger Aspekt ist auch der Preis, denn so etwas wie das Beagleboard, kann man sich als Schüler nicht mal eben so leisten. Ich persönlich finde auch die Linux Variante besser, weil ich mir überlegt habe man könnte das Radio ja auch als HTPC benutzen. man würde nur eine kleine Grafikkarte bauen um z.B. einen Fehrnseher anschließen kann und dann nen Ethernet anschluss dran, dann kann man nen Video Player (VLC?) drauf installieren, dann hat man ein System, mit dem Man übers Netzwerk Filme gucken kann. @Harald MP3 können die Anti-Linuxer auch in Software machen, AT91SAM7S64 is zu 50% mi tMP3 ausgelastet, ein etwas größeres Modell und das Thema hat sich erledigt. Viele Grüße
Der OMAP hat zusätzlich noch eine DSP integriert (für non Comercial gibts die IDE von TI + Codec dings gratis). Das wär die schönste Lösung. Aber wie schon mal erwähnt wär sowas wie redmine (www.redmine.org) praktisch zu Verwaltung des Projektes. MFG @Kai es ist Standart das man nur mehr mit I2S sprich Soundstreams arbeitet im Audio-Bereich. Es außerdem gut für die Qualität.
Hallo, ja, finde auch dieser Vorschlag (von Kai um 20:27) hört sich gut an! (inklusive der Ergänzung von Harald, dass MP3 nicht unbedingt mit dem Tuner auf eine Platine muss) Ist im Grunde auch das was ich oben meinte, nur wohl etwas unverständlich/knapp ausgedrückt hatte ;-) (da keiner drauf eingegangen ist...) Gruß, Mathias
Patrick Weinberger schrieb: > Der OMAP hat zusätzlich noch eine DSP integriert (für non Comercial > gibts die IDE von TI + Codec dings gratis). > Das wär die schönste Lösung. Ich kann warscheinlich nen OMAP kostenlos bekommen. > Aber wie schon mal erwähnt wär sowas wie redmine (www.redmine.org) > praktisch zu Verwaltung des Projektes. Das ist eine Super Idee von dir, damit habe ich auch schon gearbeitet. Wie wäre es mit einem IRC Channel für dieses Projekt? Viele Grüße
@programm-noob Das mit der Grafikkarte geht ned, ich wüsste nicht wirklich wie man das mit wenig Aufwand realisieren soll wenn man mit so vielen Modulen arbeitet. Man braucht dann wieder eine DSP oder HW-Video-Decoder usw Preis ist immer so eine Sache zB die Produkte die zB eine DSP drin haben bei Autoradios kosten gleich mal über 300€. Bei geringer Stückzahl kommt nie unter 100€ (das wird wahrscheinlich platine + Dsiplay alleine kosten).
Harald L. schrieb: > @Kai > Einverstanden!!!! Super <freu> ;-)) > allerdings gehört MP3 dann auch auf ein separates Modul (was ein Linuxer > ja gar nicht benötigt) Linuxer brauchen MP3 von dem Autoradio ja nicht nutzen (vereinfacht die API auch stark). Wenn wir uns wirklich für eine reine MP3 decoder uC Variante entscheiden kann man ja drüber nachdenken das ganze so zu machen, das die Linuxer den MP3 decoder uC nicht bestücken brauchen. Wenn alles im selben uC sitzt ist es sowieso egal. Bleibt auch noch die Frage wer wäre dabei, wo liegen die Interessen. Ich bin gerade dabei dafür eine Seite im Wiki fertig zu machen.
Ich möchte nochmal Kais Vorschlag aufgreifen: Wenn man wirklich ein Basisgerät mit "ordentlichem" Tuner (am besten 2), vernünftigen Endstufen, ordentlicher Stromversorgung, und einem ordentlichen API hat, ist das schonmal die halbe Miete. Ob man das dann hinterher mit einer Atmel oder OMAP-CPU ansteuert ist für diesen Teil doch erstmal völlig zweitrangig. Gleichzeitig hätte man die übelsten Hürden beim Bau eines Autoradio schonmal aus dem Weg geräumt. Jetzt müssen wir uns als nächstes über die Schnittstellen verständigen. (elektrisch, mechanisch und logische) Wenn wir Verkehrsnachrichten zwischenspeichern wollen, ist eine I²S-Schnittstelle im Tuner allerdings schon fast wieder Pflicht ;) Harry
Ok wär ist der server Admin beim wiki ? I2S ist Pflicht! Ich will ned interchip komminukation mit analogsignalen machen!
Hallo nochmal, wie würde eigentlich der FM-Tuner dann genau arbeiten? hat der direkt ein Interface (I2C?) mit dem er gesagt bekommt auf welche Frequenz usw. er sich einstellen soll und auf dem er RDS-Daten abliefert, oder muss man da noch mehr selbst machen? Audiodaten kommen dann denke ich einfach analog heraus, oder? habe mich mit sowas noch nie näher beschäftigt... Gruß, Mathias
> @Kai es ist Standart das man nur mehr mit I2S sprich Soundstreams > arbeitet im Audio-Bereich. Es außerdem gut für die Qualität. Naja, das mag sicher korrekt sein, für Autoradios kann ich das aber nicht 100%ig unterstreichen. Da Audioverstärker einen analogen input haben wird man sowieso ab einem gewissen Punkt analog arbeiten müssen. Unnötig über einen D/A und A/D Wandler zu gehen nur um ein bißchen Signale zu multiplexen oder ein klein bißchen zu filtern bringt auch nicht gerade eine Qualitätsverbesserung mit sich. Lasst uns doch später genau schauen was man für einen AutoRadioIc nimmt und basierend darauf entscheiden wie man das mit dem Audio alles lösst.
>...es ist Standart das man nur mehr mit I2S sprich Soundstreams >arbeitet im Audio-Bereich. aber doch nicht bei Verstärkern, die sind (und bleiben) analog! Ausserdem -falls nötig-, so ein bisschen I2S oder ähnliches kann man auch einfach in CPLD/FPGA reinmachen (evtl mit DMA-Anbindung) , das ist kein ausschlaggebender Grund um einen bestimmten Controller zu nehmen. OMAP ist glaubich nix, wenn man nicht sehr hohe Stückzahlen hat.
Patrick Weinberger schrieb: > I2S ist Pflicht! Ich will ned interchip komminukation mit analogsignalen > machen! Interchipkommunikation würd wohl eher über sowas wie SPI, I2C, Uart laufen. Und warum bitte meinen alle Analog = schlecht?!? Wo I2s sinnvoll ist, kann man was machen, aber wo es keinen Sinn macht und das ist z.B. der Audiosignalpfad vom Radio selbst würd ich es auch nicht machen. Ausserdem sollt man erstmal mit nem Blockdiagram oder sowas anfangen bevor man sofort erstmal auf sowas schiesst. Sonst reden wir alle leicht aneinander vorbei und keine hat nachher mehr lust überhaupt was zu machen.
Patrick Weinberger schrieb: > Ok wär ist der server Admin beim wiki ? Wiki: Kai & Ich Server: Ich Harry
Ich würde sagen, das Interface zwischen dem Basissystem und dem eigentlichem Hirn sollte was selbsgemachtes sein , z.B. ein Bus mit RS232(2), I²C(2) I²S(3), SPI(4), Strom(GND, 3,3V, 5V) Das wären dann 14 Pins also eine 2*7 Stiftleiste. Dann hätten wir eine gute Verbindung zwischen den beiden Hauptelementen Worüber alles an Daten ausgetauscht werden kann. Viele Grüße
Mathias A. schrieb: > wie würde eigentlich der FM-Tuner dann genau arbeiten? hat der direkt > ein Interface (I2C?) mit dem er gesagt bekommt auf welche Frequenz usw. > er sich einstellen soll und auf dem er RDS-Daten abliefert, oder muss > man da noch mehr selbst machen? So ein Auto "FM Tuner" besteht eigentlich aus mehreren Komponenten. 1.) Tuner (meist integriert in einem IC, ab und zu auch als extra IC) 2.) Der "FM Empfänger" an sich (komplexe Sache, selbst nach der FM Demodulation, demultiplexen und co wird noch viel gemacht, z.B. weak signal handling, d.H. je nach Empfangsbedingungen wird z.B. die FM Bandbreite (ein Filter bei der ZF) angepasst oder ähnliches. 3.) Ein bißchen Audio "processing", d.H. Multiplexer (z.B. um zwischen mehreren Signalquellen zu wählen wie CD, Radio, ...), einstellbare audiofilter, ... Kommunikation läuft in 99% der Fälle über I2C. Für RDS Daten gibt es verschiedene Konzepte, z.B. einfach ein Bitstrom, ein gepufferter Bitstrom, oder ein paar I2C Register die man auslesen kann. > Audiodaten kommen dann denke ich einfach analog heraus, oder? Bei den einfachen tunern wie dem oben erwähnten JA, weil halt der ganze signalpfad analog ist. Bei "großen" Autoradio DSPs die schwer zu beschaffen und zu teuer sein dürften auch digital über I2S.
@Mysth Kannst dir mal http://www.redmine.org/ ansehen. Dabei handelt es sich auf ein Webbasierendes Projektmanagment system mit noch ein paar Feautures.
Patrick Weinberger schrieb: > @Mysth > > Kannst dir mal http://www.redmine.org/ ansehen. Dabei handelt es sich > auf ein Webbasierendes Projektmanagment system mit noch ein paar > Feautures. Ganz nett....aber, meinst du nicht, daß das etwas overdosed ist? Nen SVN sollte doch reichen....Wiki und Forum haben wir bereits. Harry
Harald L. schrieb: > Ganz nett....aber, meinst du nicht, daß das etwas overdosed ist? Denk ich auch. Es soll spaß machen und das macht es nicht wenn wir 20 Milestones definieren, Stress und Zeitdruck machen. > Nen SVN sollte doch reichen....Wiki und Forum haben wir bereits. Sollen wir das µC.net SVN nutzen?
Es gubt immer 2 Seiten der Medaille. Einer Seits kann dies für manche eine Art überwachung bedeutung wer wann was macht. Andererseits kann man sich so etwas synchronisieren wenn zB neue Leute dazu kommen kann man mal schauen wo Not am man ist oder einmal jemand auf wem warten muss und sich fadisiert kann dann einfach mal schaeun was noch zu machen ist usw. Außerdem gibt es möglichkeiten Abstimmungen zu machen usw
Ich finde Redmine Gut, is halt alles drinnen, was man braucht. Das Wiki können wir ja ins neue eintargen. Das sollte nicht das Problem sein.
Kai G. schrieb: >> Nen SVN sollte doch reichen....Wiki und Forum haben wir bereits. > > Sollen wir das µC.net SVN nutzen? Ja!
Kai G. schrieb: > So ein Auto "FM Tuner" besteht eigentlich aus mehreren Komponenten. > 1.) Tuner (meist integriert in einem IC, ab und zu auch als extra IC) > 2.) Der "FM Empfänger" an sich (komplexe Sache, selbst nach der FM > Demodulation, demultiplexen und co wird noch viel gemacht, z.B. weak > signal handling, d.H. je nach Empfangsbedingungen wird z.B. die FM > Bandbreite (ein Filter bei der ZF) angepasst oder ähnliches. > 3.) Ein bißchen Audio "processing", d.H. Multiplexer (z.B. um zwischen > mehreren Signalquellen zu wählen wie CD, Radio, ...), einstellbare > audiofilter, ... > > Kommunikation läuft in 99% der Fälle über I2C. ok, danke! zu dem Punkt 2 noch: sind das Dinge die man selbst in Software gießen muss, oder gibts dafür fertige ICs die das übernehmen? Ich überlege nämlich gerade wegen der Schnittstelle zwischen Basis- und Linuxsystem: Falls das oben beschriebene alles fertige Komponenten sind wäre es doch denkbar, dass dieses I2C-Interface auch gleichzeitig schon das "API" zu einem möglichen Linux-System ist... >> Audiodaten kommen dann denke ich einfach analog heraus, oder? > > Bei den einfachen tunern wie dem oben erwähnten JA, weil halt der ganze > signalpfad analog ist. Bei "großen" Autoradio DSPs die schwer zu > beschaffen und zu teuer sein dürften auch digital über I2S. ok, also ich hätte kein Problem mit analogen Signalen :-) d.h. I2S wäre für mich an dieser Stelle kein Muss. Mathias
Ich hab im Wiki gerade noch die Rubrik "externe Links" eingerichtet. Wer also Hinweise auf relevante Seiten, Datenblätter oder ähnliches hat, sollte diese Links mit einer kurzen Beschreibung dort einstellen. Zum Wiki -> http://osar.it-livetalk.de Harry
Mathias A. schrieb: > ok, danke! zu dem Punkt 2 noch: sind das Dinge die man selbst in > Software gießen muss, oder gibts dafür fertige ICs die das übernehmen? Nein, alles das ist fertig und gibts in einem IC Gehäuse. > Ich überlege nämlich gerade wegen der Schnittstelle zwischen Basis- und > Linuxsystem: Falls das oben beschriebene alles fertige Komponenten sind > wäre es doch denkbar, dass dieses I2C-Interface auch gleichzeitig schon > das "API" zu einem möglichen Linux-System ist... Dann macht man vermutlich die selbe Arbeit zwei mal und was RDS betrifft muss man evtl. sehr schnell reagieren, sonst hat man Datenverlust. Das RDS I2C register ist nämlich nicht unbedingt gelatched. > ok, also ich hätte kein Problem mit analogen Signalen :-) > d.h. I2S wäre für mich an dieser Stelle kein Muss. FM Radio ist sowieso fern ab von CD-Qualität (schlechte stereo seperation, schlechter SNR, kleinere Dynamik).
Kai G. schrieb: > FM Radio ist sowieso fern ab von CD-Qualität (schlechte stereo > seperation, schlechter SNR, kleinere Dynamik). Von dem eingeschränkten Frequenzgang mal ganz zu schweigen :-D
Naja Auto + Hifi = Lüge Ich finde ein Projektmanagmentsystem schon eine gute idee, wie schon gesagt der Überblick ned so leicht verloren geht.
Kai G. schrieb: > Mathias A. schrieb: >> Ich überlege nämlich gerade wegen der Schnittstelle zwischen Basis- und >> Linuxsystem: Falls das oben beschriebene alles fertige Komponenten sind >> wäre es doch denkbar, dass dieses I2C-Interface auch gleichzeitig schon >> das "API" zu einem möglichen Linux-System ist... > > Dann macht man vermutlich die selbe Arbeit zwei mal und was RDS betrifft > muss man evtl. sehr schnell reagieren, sonst hat man Datenverlust. Das > RDS I2C register ist nämlich nicht unbedingt gelatched. gut, stimmt, das mit dem RDS hattest Du ja auch schon erwähnt; wenn man da wirklich permanent am I2C lesen muss ist das mit Linux in der Tat wohl eher unschön zu machen... Ich hatte halt überlegt ob man den geplanten dicken µC nicht weglassen könnte, wenn sowieso noch ein (noch dickerer) Linuxrechner daneben werkelt. Wobei ja noch gar nicht feststeht wie "dick" dieser Controller für die Nicht-Linuxer überhaupt sein wird, vielleicht wird das ja auch gar nicht so wild wie es sich oben schonmal anhörte, mit externem RAM usw. Harald L. schrieb: > Kai G. schrieb: >> FM Radio ist sowieso fern ab von CD-Qualität (schlechte stereo >> seperation, schlechter SNR, kleinere Dynamik). > > Von dem eingeschränkten Frequenzgang mal ganz zu schweigen :-D ...und ganz nebenbei kommt es ja sowieso schon analog über die Luft ;-) (den Sonderfall "DSP-Empfänger" lasse ich jetzt mal unter den Tisch fallen) Gruß, Mathias
Moinse ... um mein Senf mal ab zulassen ;) ich finde die Idee mehr als super !!! und werd def. weiter verfolgen. Zum Thema FM Tuner .. ich kann nur den TEA5991 empfehlen .. der ist absolut relaxt ... einfach anzusprechen und im Layout sehr verzeihlich;) Gruß Micha
Michael G. schrieb: > ich finde die Idee mehr als super !!! und werd def. weiter verfolgen. > Zum Thema FM Tuner .. ich kann nur den TEA5991 empfehlen .. der ist > absolut relaxt ... einfach anzusprechen und im Layout sehr verzeihlich;) Ich habe SEHR (SEHR) viel mit den TEA599x-teilen gemacht und kann sagen das sie für Autos nicht taugen. Sie sind von der Softwareseite wirklich leicht anzusprechen, aber es sind reine portable FM-Empfänger (Für handies und co. und dafür sind sie echt verdammt gut). Alleine darum sind viele Sachen die in einem Autoradio praktisch sind, schon von vornhinein nicht vorhanden (z.B. Es kommt z.B. bei großen Signalen zu intermodulation). Weak signal handling gibt es keins, als Qualitätsindikator für die Empfangsqualität gibt lediglich den HF-SignalLevel, aber sonst nix anderes. Es gibt keinen Audio source multiplexer und man darum auch keine Bässe/Höhen/... für andere Audioquellen regeln.
ok .. sind durchaus Argumente ... ich nutz den primiär um RDS abzugreifen .. so als billiger DCF77 Ersatz für die Zeit .. das Audio war nie wirklich meine Prämisse .. bzgl Audio hab ich nur mit dem ST EVM rumgespielt ... wie gesagt der TEA5991 fließt bei mir nur bei einigen Projekten als einfache Zeitquelle ein ... Gruß Micha
@Michael G. stell doch mal einen Link zu dem Datenblatt zum Chip ins Wiki! @Kai welchen Tuner würdest du empfehlen? Harry
Harald L. schrieb: > @Kai > welchen Tuner würdest du empfehlen? Ich würde momentan sowas wie den schon erwähnten TEF690x empfehlen. Lieber nutzen würde ich etwas deutlich aktuelleres das weniger externe Komponenten benötigt. Ich hab da auch etwas konkretes im Auge aber ich check im Hintergrund gerade ab ob es das schon "offiziell" und vor allen dingen nicht nur als sample gibt. Bitte noch kurz warten ;-)
Hi, auch ich bin von der Idee begeistert. Ich finde Linux als Basis bringt zwar einen großen Einarbeitungs-Aufwand mit sich, dafür wird man aber mit einem extrem flexiblem System belohnt. Vor allem das erwähnte IGEPv2 Board bringt ja eigentlich schon alles mit was benötigt wird. Ein paar tasten, Dreh-encoder Touchscreen und FM-Modul dran und man hat im Prinzip alles bis zum Verstärker erschlagen. Als Software würde ich auf Android oder MeeGo setzen. Vor allem bei MeeGo sehe ich viel Potential für die Zukunft. Die ganze Entwicklung würde sich somit aufs anpassen des Betriebssystems und die Entwicklung einer Intuitiv zu Bedienenden Oberfläche (gutes Bedienkonzept mit Touch + Hardware tasten) reduzieren. Gruß Jörn
Für einen Prototypen ist das IGEPv2 sicherlich ned schlecht, aber der EMV zu liebe muss man wohl oder übel selbst ein Board entwerfen. Mit den Passenden Erweiterungsslots usw
> Ist das notwendig? Am Ende muss es doch sowieso wieder Analog sein. > Oder hast Du mit den Daten noch etwas spezielles vor? Man muss die Daten ja irgendwie faden und filtern. Oder auch nur die Lautstaerke aendern, Loudness. Entweder macht das der Controller, oder man macht es auf klassische Art mit einem AnalogIC. Im Controller hat halt vorteile weil man flexibler ist. (Laufzeitverzoegerung :-) Es gaebe auch noch eine andere Funktion die ich ganz interessant faende, die man aber normalerweise nicht in Autoradios findet. Naemlich einen Dynamikkompressor fuer MP3s und einen Dynamikexpander fuer Radio (weil die Sendestationen nur noch gequetschten Muell senden) BTW: Gibt es eigentlich einen Anti-Exciterfilter? Vielleicht kann man die Klangqualitaet dann wieder auf den Level von 1995 anheben. Ich denke auch das man es notfalls mit einem AnalogeIC machen kann, besonders wenn es in Kais EMpfaenger gleich eingebaut ist, aber digital waer schoener weil flexibler. > Evtl. wäre es sinnvoll (der Geschwindigkeit wegen) ein direktes > Interface > vom Haupt uC zum Display zu machen. Wird den Geschwindigkeit gebraucht? Es sollen ja keine Videos laufen. Eine Aufteilung haette den Vorteil das an dieser Stelle eine schoene Schnittstelle im Project waere. Sowohl fuer Zweitverwertung, wie auch um die Arbeit aufzuteilen. > * 2 MB Ram > * 16MB Flash Viel zu fett. Dann muss wieder alles extern sein. Du willst SD-Ram haben. Es laeuft auf eine Multilayerplatine raus. Kostet ein Riesenaufwand fuer nichts. Wenn du das willst dann hole dir einen CarPC und wandel den nach deinen Beduerfnissen ab, das ist einfacher. > Ich glaube nicht, daß ich der Einzige bin der so denkt, aber ohne die > Möglichkeit ein Linux auf das Radio zu bringen, wär das Projekt für mich > absolut uninteressant. Ich seh da keinen Mehrwert zu käuflichen > Lösungen. Und fuer mich waere das Project so wie du es dir vostellst absolut uninteressant weil ich das ganze naemlich als Freizeitspass sehe und nicht unendlich viel Arbeit da reinstecken will. > Bluetooth einen I2S > Verstärker einen I2S > LineIn/AUX und Cinch Ausgang einen I2S > dann vielleicht noch ein oder 2 Mikrofone einen I2S > dann will noch einer SPDIF bedeutet auch wieder einen I2S Der von mir angesprochene SuperH von Renesas hat 4x I2S, 2x Codecausgaenge fuer 16Bit Stereo, und SPDIF in/out direkt integriert. Und er hat auch zwei Sampleratenwandler integriert. Wollte ich nur mal erwaehnt haben. .-) Oh..und er hat ein paar spezielle Befehle (multiply und add) in 3 oder 6 Takten wie man sie fuer Filter und aehnliches braucht. Lesst wirklich mal die ersten 20Seiten des Datenblatts wo nur die Hardware grob vorgestellt wird. .-) Und ich habe nicht vor Linux zu verwenden, aber es gibt fuer die SuperH auch ein Linux... > Wenn wir Verkehrsnachrichten zwischenspeichern wollen, ist eine > I²S-Schnittstelle im Tuner allerdings schon fast wieder Pflicht ;) Ich wuerde es sogar nett finden wenn man auf Tastendruck mal eine Radiosendung auf Speicherkarte aufzeichnen koennte. Also irgendwann mal, ist sicher nicht so wichtig, aber sicher nett. Olaf
Olaf Kaluza schrieb: > >> * 2 MB Ram >> * 16MB Flash > > Viel zu fett. Dann muss wieder alles extern sein. Du willst SD-Ram > haben. Es laeuft auf eine Multilayerplatine raus. Kostet ein > Riesenaufwand fuer nichts. Wenn du das willst dann hole dir einen CarPC > und wandel den nach deinen Beduerfnissen ab, das ist einfacher. Eben nicht! ich bin begeisterter Radiohöhrer. MP3 interessiert mich nur am Rande. Ich hab bisher noch keinen CarPC mit ordentlichem Tuner gefunden. > >> Ich glaube nicht, daß ich der Einzige bin der so denkt, aber ohne die >> Möglichkeit ein Linux auf das Radio zu bringen, wär das Projekt für mich >> absolut uninteressant. Ich seh da keinen Mehrwert zu käuflichen >> Lösungen. > > Und fuer mich waere das Project so wie du es dir vostellst absolut > uninteressant weil ich das ganze naemlich als Freizeitspass sehe und > nicht unendlich viel Arbeit da reinstecken will. > Wenn du den Thread verfolgt hättest, wüsstest du bereits, daß wir uns dahingehend geeinigt haben, das auf Teilprojekte aufzusplitten: Es wird ein DIN-Gehäuse mit Stromversorgung, Verstärker, Tuner, ein wenig Eigeninteligenz und einem klar umrissenen API (Hard- und Software) entwickelt. Dieses kann dann mit versch. Bedienkonzepten und/oder CPU-Board erweitert werden. > Ich wuerde es sogar nett finden wenn man auf Tastendruck mal eine > Radiosendung auf Speicherkarte aufzeichnen koennte. Also irgendwann mal, > ist sicher nicht so wichtig, aber sicher nett. > Nette Idee, aber im Moment eher sekundär. Trag den Link zum Datenblatt der von dir empfohlenen CPU bitte ins Wiki ein! http://osar.it-livetalk.de/ Harry
Ich hab mal begonnen, im Wiki in der Rubrik "Hardware" ein paar Eckdaten für das Mainboard aufzuzeichen. Bitte ergänzen/bearbeiten! Harry
Harald L. schrieb: > Olaf Kaluza schrieb: >> >>> * 2 MB Ram >>> * 16MB Flash >> >> Viel zu fett. Dann muss wieder alles extern sein. Du willst SD-Ram >> haben. Es laeuft auf eine Multilayerplatine raus. Kostet ein >> Riesenaufwand fuer nichts. Wenn du das willst dann hole dir einen CarPC >> und wandel den nach deinen Beduerfnissen ab, das ist einfacher. > > Eben nicht! > ich bin begeisterter Radiohöhrer. MP3 interessiert mich nur am Rande. > Ich hab bisher noch keinen CarPC mit ordentlichem Tuner gefunden. Das größte Problem bei CarPCs ist die Abwärme. zB ein Atom Board hat immer so 10W Abwärme meistens sogar über 20W ! Zum vergleich ein moderner OMAP 3530 oder die neuen kommen mit RAM und Co weit unter 5W (der OMAP selbst nur so 1 bis 1,5W). Wie willst jetzt aus einem DIN Gehäuse bei Umgebungstemp von 45°C 20W abführen wenn sogar schon 10W schwer sind ? Dann kommen noch so 20W vom Verstärker hinzu. So ein FM-Radio Chip wird auch warm. Dann ist man gleich bei 40 bis 50W abwärme. Mit einem OMAP sinds nur mehr 25 bis 30W. >> >>> Ich glaube nicht, daß ich der Einzige bin der so denkt, aber ohne die >>> Möglichkeit ein Linux auf das Radio zu bringen, wär das Projekt für mich >>> absolut uninteressant. Ich seh da keinen Mehrwert zu käuflichen >>> Lösungen. >> >> Und fuer mich waere das Project so wie du es dir vostellst absolut >> uninteressant weil ich das ganze naemlich als Freizeitspass sehe und >> nicht unendlich viel Arbeit da reinstecken will. >> > Wenn du den Thread verfolgt hättest, wüsstest du bereits, daß wir uns > dahingehend geeinigt haben, das auf Teilprojekte aufzusplitten: > Es wird ein DIN-Gehäuse mit Stromversorgung, Verstärker, Tuner, ein > wenig Eigeninteligenz und einem klar umrissenen API (Hard- und Software) > entwickelt. > Dieses kann dann mit versch. Bedienkonzepten und/oder CPU-Board > erweitert werden. > Das mit KO-Kriterium gilt für mich auch. Sonst bestell ich mir einen bei dem Großen Versandhaus ggg.
> Man muss die Daten ja irgendwie faden und filtern. Oder auch nur die > Lautstaerke aendern, Loudness. Entweder macht das der Controller, > oder man macht es auf klassische Art mit einem AnalogIC. In single chip Car Radio ICs wie den erwähnten ist das sogar schon alles integriert. > Im Controller > hat halt vorteile weil man flexibler ist. (Laufzeitverzoegerung :-) > Es gaebe auch noch eine andere Funktion die ich ganz interessant faende, > die man aber normalerweise nicht in Autoradios findet. Naemlich einen > Dynamikkompressor fuer MP3s und einen Dynamikexpander fuer Radio (weil > die Sendestationen nur noch gequetschten Muell senden) Kompressoren (eigentlich für CD gedacht) und Expander auf jeden Fall auch drin, Deemphasis natürlich, ... > BTW: Gibt es eigentlich einen Anti-Exciterfilter? Vielleicht kann man > die Klangqualitaet dann wieder auf den Level von 1995 anheben. Was ist ein anti-Exciterfilter? > Ich denke auch das man es notfalls mit einem AnalogeIC machen kann, > besonders wenn es in Kais EMpfaenger gleich eingebaut ist, aber digital > waer schoener weil flexibler. Für delay braucht man eh einen ADC, wenn man eine I2S VAriante wählt, kann man es an fast jeden uC anschliessen. Man müsste parallel fahren können um die Frustration für den Anfang gering zu halten (weil man erstmal analog fahren kann und sich die arbeit für den digitalen Kram erstmal sparen kann). > Wird den Geschwindigkeit gebraucht? Es sollen ja keine Videos laufen. Je nachdem wie das Interface aussieht und wieviel fifo puffer der UC mit sich bringt kann es sinnvoll sein weil die Zeit für die Übertragung evtl. aktives Warten für den uC bedeutet. > Eine Aufteilung haette den Vorteil das an dieser Stelle eine schoene > Schnittstelle im Project waere. Sowohl fuer Zweitverwertung, wie auch > um die Arbeit aufzuteilen. Stimmt. Es kann aber auch bedeuten das man ein recht aufwändiges Interface definieren muss, wenigstens wenn es High level Kommandos gibt wie gib Text an der X und Y-Koordinate aus mit dem Font. Zeichne Rechteck, ... Wenn das natürlich jemand übernimmt, kein Problem :-) > Viel zu fett. Dann muss wieder alles extern sein. Du willst SD-Ram > haben. Es laeuft auf eine Multilayerplatine raus. Kostet ein > Riesenaufwand fuer nichts. Wenn du das willst dann hole dir einen CarPC > und wandel den nach deinen Beduerfnissen ab, das ist einfacher. Jo! > Und fuer mich waere das Project so wie du es dir vostellst absolut > uninteressant weil ich das ganze naemlich als Freizeitspass sehe und > nicht unendlich viel Arbeit da reinstecken will. Auch ACK. > Der von mir angesprochene SuperH von Renesas hat 4x I2S, 2x > Codecausgaenge fuer 16Bit Stereo, und SPDIF in/out direkt integriert. > Und er hat auch zwei Sampleratenwandler integriert. Wollte ich nur mal > erwaehnt haben. .-) Im Idealfall brauchen wir die nicht ;-) > Oh..und er hat ein paar spezielle Befehle (multiply und add) in 3 oder 6 > Takten wie man sie fuer Filter und aehnliches braucht. > Lesst wirklich mal die ersten 20Seiten des Datenblatts wo nur die > Hardware grob vorgestellt wird. .-) Bei was für einer Taktfrequenz eigentlich? > Und ich habe nicht vor Linux zu verwenden, aber es gibt fuer die SuperH > auch ein Linux... Hat da jemand Jehova gerufen? ;-) > Ich wuerde es sogar nett finden wenn man auf Tastendruck mal eine > Radiosendung auf Speicherkarte aufzeichnen koennte. Also irgendwann mal, > ist sicher nicht so wichtig, aber sicher nett. SEHR gute Idee!!!
> Dann kommen noch so 20W vom Verstärker hinzu. So ein FM-Radio Chip wird > auch warm. Die Car DSP Variante auf jeden fall, die rein analoge kaum.
>> Ich wuerde es sogar nett finden wenn man auf Tastendruck mal eine >> Radiosendung auf Speicherkarte aufzeichnen koennte. Also irgendwann mal, >> ist sicher nicht so wichtig, aber sicher nett. > > SEHR gute Idee!!! Klingt nach koomplexer Einfachheit. Wie wärs wenn wir als Projektsprache Englisch nehmen, wär dann für andere leichter einzusteigen. Lg
> Zum vergleich ein moderner OMAP 3530 oder die neuen kommen mit RAM und > Co weit unter 5W (der OMAP selbst nur so 1 bis 1,5W). Ich kenne noch keinen Daten, aber mein SuperH hier laeuft als Testboard am USB Anschluss und wird gefuehlt gerade mal lauwarm. Die CPU laeuft intern auch nur mit 1.x Volt. Und das ohne das irgendwelche Stromsparmodi genutzt werden. Es laeuft nur ein while(1); .-) > Was ist ein anti-Exciterfilter? Boeser Sarcasmus. (._.); Ein Filter der den Excitereinsatz rueckgaengig macht den Radiostationen zusammen mit dem zu starken Kompressoreinsatz seit etwa 5-10Jahren nutzen damit der Sound selbst aus der Aldimobilette fuer 1.95Euro cool rueberkommt. http://de.wikipedia.org/wiki/Exciter_(Gerät) > Bei was für einer Taktfrequenz eigentlich? Der SH7262 laeuft mit 144Mhz. > Wie wärs wenn wir als Projektsprache Englisch nehmen, wär dann für > andere leichter einzusteigen. Naja, ich spreche aus persoenlichen Gruenden sowieso den ganzen Tag nur English, aber irgendwie komme ich mir doof vor wenn ich mit Leuten English rede die Deutsche sind. Olaf
Patrick Weinberger schrieb: > Wie wärs wenn wir als Projektsprache Englisch nehmen, wär dann für > andere leichter einzusteigen. wir sollten unbedingt den Universal-Übersetzer (StarTrek (tm)) auf die Feature-Liste setzen.....wär doch cool, wenn wir die Nachrichten auf BFBS in Deutsch, und die auf WDR5 auf English auf den USB-Stick bannen könnten .....( ;) Spass muss sein!) Mir ist es ziemlich egal, ob Deutsch oder Englisch, seh das aber genau wie Olaf....obwohl mir ein wenig Training sicher nicht schaden würde! Aber im Augenblick ist das noch kein internationales Projekt, und wir können ohne schlechtes Gewissen zu haben unsere Muttersprache nutzen. Für die Anderssprachigen gibt es immer noch den Google-Translator. Harry
Also, ich hab das Ganze nochmal überdacht, und mich mittlerweile davon verabschiedet, Linux direkt auf dem Gerät laufen zu lassen. Es reicht mir, wenn ich meine Linux-Box "daneben setzen" kann, und auch von dort aus die volle Kontrolle über das Gerät haben kann..... Natürlich benötige ich gut definierte Schnittstellen......insofern: lasst uns weitermachen! Mich interessierst primär, mal ein "wirklich gutes Radio" im Auto zu haben: Ich werd allerdings immer dann intervenieren, wenn mir Schnittstellen fehlen. das Wiki zum Projekt: http://osar.it-livetalk.de Harry
Die Linux oder nicht Linux frage könnte man demokratisch angehen, um sie für ein für alle mal aus der Welt zu schaffen. Wenn jetzt jeder in eine andere Richtung will ist das Frustpotential gigantisch
Demokratisches Abstimmen finde ich bei so einem Projekt eine ganz dumme Idee. Meinst du, einer, der nicht für Linux ist, macht danach gerne mit, weil du ihn überstimmt hast? Nein, man muss schon versuchen, den Kompromiss zu finden, der möglichst allen taugt, die mitmachen wollen. Und da finde ich die Idee, eine "Backplane" zu schaffen, die nicht auf Linux aufsetzt, sich aber durch ein Linuxboard oder halt etwas Alternatives durch Definition entsprechender Schnittstellen steuern lässt, einen wirklich guten Kompromiss. Gerhard
Das beste ist wohl zu allererst den Tuner zu entwickeln und nebenbei einfach das Linux-Board, Gehäuse und den dummen Client. Ich hab jetzt die CPU-Liste aktualisiert. MFG
seennoob schrieb: > Das beste ist wohl zu allererst den Tuner zu entwickeln Das seh ich genauso! Harry
Also Basisplatine schlag ich eine art Buskarte vor. Welche über einen Master und 2 Fullsize und vielleicht noch über 2 kleinere Anschlüsse verfügen soll. Jeder Steckplatz verfügt über SPI, I2S, I2C, 12V vom Boardnetz, Masse und Parallelport die direkt zum Masterport führen. Der Masterport übernimmt dann die ganze Kommunikation mit den einzelnen Modulen. Mit einer kleinen FPGA und FPAA kann man vielleicht noch ein Busmultiplexing hinzufügen. lg, Patrick
seennoob schrieb: > Also Basisplatine schlag ich eine art Buskarte vor. Welche über einen Schau mal hier: http://osar.it-livetalk.de/index.php/Grunds%C3%A4tzliches Harry
Ne in dem Beispiel hat die Buskarte wieder Aufgaben außer die einzelnen Komponenten zu vernetzen. Alles muss ohne Buskarte/Mainboard funktionsfähig sein.
Das Halt ich nicht für so ne gute Idee! Bedenke auch mal den Platzbedarf. Und Kernkomponenten wie Stromversorgung, Ein-/Ausschaltlogik, NF-Verstärker, NF-Distribution wird immer benötigt. Der/die Tuner ebenfalls. Aus meiner Sicht gehören diese Komponenten aufs Mainboard. Harry
Aber der Tuner sollte dann das Signal auch digital liefern. So hat man für alles die Beste Schnittstelle. Alles andere wär fast wieder ein Flaschenhals und erlaubt einen das digitale Mischen und Filtern des Streams usw.
> Mit einer kleinen FPGA und FPAA kann man vielleicht noch ein > Busmultiplexing hinzufügen. Ich vermag momentan keinen grossen Sinn oder Vorteil in der Verwendung eines FPGAs erkennen. Dafuer hat er auf jedenfall den Nachteil eine Menge Leute vor das Problem seiner Programmierung zu stellen. > Aber der Tuner sollte dann das Signal auch digital liefern. Das muss er nicht unbedingt. Ein AD-Wandler ist ja heutzutage keine keine Bueckware mehr. :-) Olaf
> Ich hab jetzt die CPU-Liste aktualisiert.
Ich bin sehr stark gegen die Verwendung von irgendetwas im BGA Gehaeuse.
Ich wuerde mir zwar noch zutrauen das zu loeten auch wenn ich das noch
nie gemacht habe, aber die Platine braucht dann 4Layer minimum und
MicroVIAs.
Mal abgesehen das ich den ersten Prototyp sowieso selber aetzen wollte,
sowas ist auch beim herstellen lassen sofort teuer. Und es wird nochmal
richtig teuer dadurch das die Wahrscheinlichkeit ansteigt das man
zusaetzliche Muster braucht.
Oh und fuer den letztlichen Enduser erhoeht es auch das Risiko. Ich
weiss zwar nicht wie gross die Wahrscheinlichkeit ist einen BGA richtig
aufzuloeten, aber IMHO deutlich kleiner 100%. Wenn also letztlich
10-20Leute das Radio bauen wollen, wieviele davon lassen wir draufgehen?
Ausserdem wird es eine ganze Menge Leute von vornerein abschrecken. Es
werden auch so schon einige seufzen wenn sie Gehaeuse mit 0.5mm
Pinabstand loeten muessen, aber BGA ist doch in jeder Hinsicht nochmal
eine Verschlechterung.
Olaf
Ich halt den Einsatz einer solchen CPU auf dem Motherboard für extrem überzogen. Oder wollt ihr wirklich das (lt. Kai) zeitkritische RDS-geraffel unter Linux abwickeln? Klar geht das, aber ein Spass ist das sicher nicht, und ich glaub dem Kai, daß er das mit konventioneller Programmierung in den Griff bekommt. Sowas gehört auf das Linux-AddOn-Board....aber nicht auf das Motherboard bitte! Harry
Es gäbe auch fertige CPU Module - die ham aber auch fast alle ziemlich feine finepitch Steckverbinder die auch nicht jeder löten kann :-/ Relativ teuer wird das sowieso, billiger als kompletter Selbstbau auf jeden Fall und leichter zu handhaben als selbst BGAs zu löten. Für den OMAP sollte man schon 6 Lagen ansetzen sonst wirds schwierig. Und das wird extrem teuer für Prototypen!
Mein Posting war auf das von Olaf bezogen sorry hab vergessen es dabeizuschreiben.
Cooles Projekt!! Wie wäre es denn mit einer Navi-Funktion auf Basis von OpenStreetMap?
paul schrieb: > Cooles Projekt!! > > Wie wäre es denn mit einer Navi-Funktion auf Basis von OpenStreetMap? hab ich auch im Sinn, ist aber deutlich zu früh, um darüber nachzudenken ;) Harry
Moin moin! wollte nur kurz schreiben das ich heute Abend mal ein größeres Blockschaltbild posten will, dann kann man über Audiosignalrouting und solche Details besser diskutieren. Hab damit schon angefangen, bin aber dieses WE stark familiär eingebunden, daher bin ich "so ruhig"... Viele Grüße, Kai
Kai G. schrieb: > Moin moin! > > wollte nur kurz schreiben das ich heute Abend mal ein größeres > Blockschaltbild posten will, dann kann man über Audiosignalrouting und > solche Details besser diskutieren. Dann passt das ja gut, daß ich gestern den Datei-Upload im Wiki freigeschaltet hab. Harry
Harald L. schrieb: > Dann passt das ja gut, daß ich gestern den Datei-Upload im Wiki > freigeschaltet hab. Leider werden .odg Dateien nicht unterstützt. Hab die Zeichnung extra mit OpenOffice gemacht, aber leider ist der Dateityp nicht zugelassen. Habe aber erstmal eine .png-Version hochgeladen. Hier der Link zum Blockschaltbild: http://osar.it-livetalk.de/index.php/Blockschaltbild Und hier hab ich was zum tuner geschrieben: http://osar.it-livetalk.de/index.php/Tuner @Harald: Nochmal kurz die Frage. Du hast auf einer anderen Seite wieder etwas über TMS geschrieben oder rüberkopiert: Du meinst vermutlich TMC, oder?
Olaf Kaluza schrieb: > Ich bin sehr stark gegen die Verwendung von irgendetwas im BGA Gehaeuse. > Ich wuerde mir zwar noch zutrauen das zu loeten auch wenn ich das noch > nie gemacht habe, aber die Platine braucht dann 4Layer minimum und > MicroVIAs. BGAs selberlöten ist nicht so einfach. Gibt irgendwo im Netz ne Seite von jemandem der das mit Heissluftgebläse + Bügeleisen macht. Sehr nett ;-) Ansonsten würd ich das eher mit einem reflowofen angehen. Aber es ist zu gefährlich das man den teuren Chip + die teure Prototypenplatine kaputt macht. Übrigens hab ich mal eine Platine layouten lassen ohne zu sagen wieviel Layer sie haben soll. Der 180 pin TFBGA mit 0.5mm pitch wurde dann auf 2 Layer geroutet, die Leiterbahnen schlängelten gingen teils noch zwischen den pins durch. Klappte einwandfrei. Ich bin davon heute noch immer sehr beeindruckt ;-) > Mal abgesehen das ich den ersten Prototyp sowieso selber aetzen wollte, > sowas ist auch beim herstellen lassen sofort teuer. Hurra, ein selberätzer! Erfahrungsgemäß: 1. Prototyp = noch einige Hardwarepatches nötig. Find ich also auch gut wenn wir die selber ätzen oder kostenlos fräsen (lassen)... Solange nicht gerade 1000 Durchkontaktierungen nötig sind ;-)
Kai G. schrieb: > @Harald: > Nochmal kurz die Frage. Du hast auf einer anderen Seite wieder etwas > über TMS geschrieben oder rüberkopiert: Du meinst vermutlich TMC, oder? ich hab das nur an eine andere Stelle verschoben, Der Text stammt nicht von mir. Harry
Olaf Kaluza schrieb: >> Mit einer kleinen FPGA und FPAA kann man vielleicht noch ein >> Busmultiplexing hinzufügen. > Ich vermag momentan keinen grossen Sinn oder Vorteil in der Verwendung > eines FPGAs erkennen. Dafuer hat er auf jedenfall den Nachteil eine > Menge Leute vor das Problem seiner Programmierung zu stellen. Mal ganz abgesehen von der Steilheit der Taktflanken, die auch wenn man sowas wie eine "slow IO" option hat noch immer immens ist. >> Aber der Tuner sollte dann das Signal auch digital liefern. Wieso soll der Tuner direkt digital liefern?
seennoob schrieb: > Aber der Tuner sollte dann das Signal auch digital liefern. So hat man > für alles die Beste Schnittstelle. Alles andere wär fast wieder ein > Flaschenhals und erlaubt einen das digitale Mischen und Filtern des > Streams usw. Nochmal kurz zum Thema digitales mischen/filtern. Ich halte das für nicht so trivial wie es auf dem 1. Blick aussieht. In meinem Blockdiagramm hab ich es aber auch erstmal so vorgesehen. So ein Filter, wenn er in fixed point realisiert ist kann wenn er schlecht gemacht ist so einiges an Quantisierungsrauschen hinzufügen und ist in fixed point auch nicht mal so eben wenn man die Filterkoeffizienten hat runtergeschrieben. Ein Mischen an sich ist vermutlich nicht nötig, wenigstens fällt mir kein echter use-case ein.
Harald L. schrieb: > ich hab das nur an eine andere Stelle verschoben, Der Text stammt nicht > von mir. Ah, OK. Danke! Selbe Frage dann an den Ersteller :-) Gibt es eigentlich keine Möglichkeit hier eine Threaddarstellung zu bekommen?
Hab mal etwas mit den Leuten vom Beagleboard geplaudert. Fazit mit einem geringen Budget -> nicht machbar mit den OMAP. Aber sonst einfach das Beagleboard (Mx) nehmen. MFG
Hallo, ein interessantes Projekt habt Ihr da gestartet. Daher auch mal ein paar Anmerkungen von mir. Die Optik wird sicher der entscheidende Punkt sein, wenn es später um den Einbau in ein Familienfahrzeug geht. Singles haben es da einfacher. Ansonsten sollte man evtl. über einen versteckten Einbau unter Nutzung Multifunktionslenkrad/-anzeige oder CD-Wechslerausgang des Originalradios als Option nachdenken. Zum Thema Mainboard: Dieses sollte meiner Meinung nach nur Stromversorgung und (gleichwertige) Modulsteckplätze inkl. ggf. Multiplexer für I2S und analoges Audio beherbergen. Die Endstufe sollte ebenso als Modul ausgeführt werden, wie die Vorverstärkerausgänge. So ist größtmögliche Flexibilität geboten und dennoch Interoperabilität bewahrt. Ob dann jemand ein CPU-Modul mit Linux oder ein Modul mit einem simplen 8-Bitter einsetzt, bleibt egal. Die Hardwareschnittstellen bleiben gleich. Multiplexing ist in der Hinsicht interessant, dass vermutlich nie mehr als 2 verschiedene Streams (z.B. Front Radio über Lautsprecher, Rear MP3 über Kopfhörer) gleichzeitig wiedergegeben werden. Gruß Jan
Ich hab hier noch ein interessantres CPU-Board gefunden: http://osar.it-livetalk.de/index.php/CPU-Wahl#Eddy_2.0_CPU-Board Harry
Jan X. schrieb: > [100%ige Modularität und so] Zu modular halt ich nicht für sinnvoll und ich seh uns hier auch nicht (wenigstens am Anfang) 3 verschiedene Verstärkermodule und 4 verschiedene CPUs benutzen. Zudem sind die Auswirkungen auf den HF-Teil einfach zu unvorhersehbar. Die Stromversorgung ist auch je nach Modulen wieder unterschiedlich. Ein digitales Radio Modul, selbst unterschiedliche Tuner können schon wieder ganz andere Spannungen und Ströme benötigen. Mal ganz abgesehen von den mechanischen Problemen. Module können Anschlüsse haben die nach vorne oder hinten gehen müssen. Für welche Slots sieht man was vor und wie um himmels willen bekommt man da noch ein vernünftiges Frontpanel hin? Modularität an sich find ich prima, aber ich plädiere stark für ein einfaches Radio mit Stromversorgung, Tuner, µC und MP3 Funktion als Grundfunktion. So ein System ist überschaubar und bekommt man HF-mäßig auch noch vernünftig hin ohne 200 ungewünschte Signale im eigentlichen Spektrum des Tuners zu haben. Wie kann ich bei zu großer Modularität dem Schaltnetzteil sagen das es plötzlich mit einer anderen Frequenz arbeiten soll oder dem µC, dass sein (dank Modularität sowieso unbekannter) Haupttakt umgeschaltet werden soll, etc...
Modularität bedeutet ja nicht zwingend das Steckkartenprinzip. Zu der Stromversorgung: Die wichtigsten Spannungen sollten mit ausreichender Strombelastbarkeit bereitgestellt werden. Ich denke hier an 12V, 5V und 3,3V. Braucht ein Modul andere Spannungen, kann es diese aus den vorhandenen ableiten. In Sachen Störfestigkeit für das HF-Teil: Wichtig ist vor allem eine saubere Versorgungsspannung. Andere Störeinflüsse sollten durch entsprechendes Design und notfalls Abschirmung minimiert werden. Daß der Tuner anderen Komponenten Arbeitsparameter (Schalt-/Taktfrequenz) vorgibt, halte ich nicht für sinnvoll. Insbesondere wenn man 2 der Tuner einsetzen möchte, kann es hier schon zu Problemen kommen, wenn beide unterschiedliche Vorgaben machen.
Hi! Ich bin auch der Meinung, dass ich nicht darauf warten möchte, bis ein Linux gebootet hat. Andererseits habe ich keine Erfahrung, wie oft man ein Linux zwischen Standby und Normal hin und her schalten kann, bis erste Instabilitäten auftreten und wie einfach es ist, ein Linux auf ein eigenes Controller-Board anzupassen, bis auch die ganzen Sleep-Modis funktionieren. Die Andere Lösung wäre es, z.B. die Ethernut, speziell das Elektor Internet Radio zu erweitern und für diesen Einsatz zu verwenden. Wenn man es noch mit einem Car-HiFi Laufwerk für CD oder DVD kombiniert, die per I2C gesteuert werden und den Audio-Codec schon on Board haben, so benötigt man nur noch einen Audio-Switch oder einen der NXP Tuner mit Audio-Multiplexer integriert und schon ist man fertig. Die Ethernet-Schnittstelle könnte man sehr gut verwenden. Das Kabel unters Dach gezogen und einen WLAN-Client Dongle dran geklemmt, schon reicht es, das Auto in der Einfahrt zu parken und man kann seine Musik einfach per Explorer rüber kopieren. Im Gegensatz zu einer Linux-Lösung mit weniger Hardware aber mehr Komplikationen bei EMV und Steuerbarkeit, wäre eine EIR Lösung sicherlich mit mehr Chips bestückt, die einzelne Aufgaben spezialisiert abarbeiten. Der SAM7 muss dann nur noch die Datenströme lenken oder Logistische Aufgaben übernehmen. Da dem EIR ein USB-Host Port fehlt, könne man in Radio-Design einen Vinculum einsetzen. Auch hier wird das ganze Komplexe USB und Daten-Handling bereits von diesem Chip erledigt, fast bis auf Dateisystem hinunter. Da reicht ein SAM7 locker aus um die Daten lediglich in einen VLSI Decoder zu schubsen. Gruß, Ulrich
Ulrich P. schrieb: > Hi! > > Ich bin auch der Meinung, dass ich nicht darauf warten möchte, bis ein > Linux gebootet hat. bei einem vernünftig designten System < 3s > Andererseits habe ich keine Erfahrung, wie oft man > ein Linux zwischen Standby und Normal hin und her schalten kann, bis > erste Instabilitäten auftreten und wie einfach es ist, ein Linux auf ein > eigenes Controller-Board anzupassen, bis auch die ganzen Sleep-Modis > funktionieren. > Immer dieses linux-Bashing... Ein Linux auf solch einem System hat ausser dem Quellcode von Kernel und einigen wenigen Tools mit einem Ubuntu, SuSE, debian oder sonstwas gar nichts gemeinsam!!!!! > Die Ethernet-Schnittstelle könnte man sehr gut verwenden. Das Kabel > unters Dach gezogen und einen WLAN-Client Dongle dran geklemmt, schon > reicht es, das Auto in der Einfahrt zu parken und man kann seine Musik > einfach per Explorer rüber kopieren. > wurde weiter oben bereits diskutiert... Harry
Jan X. schrieb: > In Sachen Störfestigkeit für das HF-Teil: Wichtig ist vor allem eine > saubere Versorgungsspannung. Wir reden HF-seitig über µV. Die HF-Optimierungen gehen deutlich über eine sauberen Versorgungsspannung hinaus. > Andere Störeinflüsse sollten durch > entsprechendes Design und notfalls Abschirmung minimiert werden. Abschirmung ist nicht mehr für ganz Zeitgemäß und ist bei einem guten Design auch nicht nötig. > Daß der > Tuner anderen Komponenten Arbeitsparameter (Schalt-/Taktfrequenz) > vorgibt, halte ich nicht für sinnvoll. Nicht, wenn es den Empfang verbessert? > Insbesondere wenn man 2 der Tuner einsetzen möchte, > kann es hier schon zu Problemen kommen, wenn beide > unterschiedliche Vorgaben machen. Die 2 Tuner werden nur bei FM benötigt, bei AM ist frequency diversity aufgrund fehlender Informationen nicht möglich. FM ist aufgrund der hohen Frequenz relativ unkritisch und so viele Verschiedene kombinationen gibt es nicht. Es geht eher in die Richtung: Ist eine der FM Tuner Frequenzen auf einer Harmonischen der Taktfrequenz => Umschalten auf andere Taktfrequenz. Wenn die Wahl der anderen Taktfrequenz keine identischen Harmonisch liefert => kein Problem.
Harald L. schrieb: >> Ich bin auch der Meinung, dass ich nicht darauf warten möchte, bis ein >> Linux gebootet hat. > bei einem vernünftig designten System < 3s Kann auch nerven. Wenn ich da an die ca. 5 sekunden Bootzeit meines Fluke 287 Multimeters denke... Da greif ich SEHR oft lieber zum 50 EURO Billigteil weil es nicht die nervigen Gedenksekunden hat ;-) > Ein Linux auf solch einem System hat ausser dem Quellcode von Kernel und > einigen wenigen Tools mit einem Ubuntu, SuSE, debian oder sonstwas gar > nichts gemeinsam!!!!! Da muss ich zustimmen! Also ich find die Lösung mit dem "optionalen Linux" die wir anstreben echt gut. In die API könnte man übrigens auch noch die Ansteuerung des Frontpanels und abfrage von Tasten integrieren, dann wäre selbst Linux mit dem standard Bedienpanel möglich. Dann wäre Linux auch noch zu einem späteren Zeitpunkt interessant für mich. Den für einige scheinbar überflüssigen µC der auf der dann Radioplatine sitzt ist nicht so abwegig, jedes USB device hat auch einen extra µC...
2 Tuner können auch sinnvoll sein, um z.b. die hinteren Sitzplätze (Kids) mit anderer Musik zu beschallen. Im übrigen halte ich den Müll aus dem KFZ-Bordnetz viel kritischer als ein sauber designtes CPU-Modul an ordentlicher Versorgungsspannung.
Kai G. schrieb: > Den für einige scheinbar überflüssigen µC der auf der dann Radioplatine > sitzt ist nicht so abwegig, jedes USB device hat auch einen extra µC... Ich würde soweit nötig jedes Modul mit eigener Intelligenz ausstatten. Preislich macht dies heutzutage kaum was aus, zumal es ja nicht um Millionenstückzahlen geht.
Kai G. schrieb: > Harald L. schrieb: >> ich hab das nur an eine andere Stelle verschoben, Der Text stammt nicht >> von mir. > > Ah, OK. Danke! > Selbe Frage dann an den Ersteller :-) Antwort: Ja. Es war TMC gemeint ;-)
Kai G. schrieb: > Harald L. schrieb: >>> Ich bin auch der Meinung, dass ich nicht darauf warten möchte, bis ein >>> Linux gebootet hat. >> bei einem vernünftig designten System < 3s > > Kann auch nerven. Wenn ich da an die ca. 5 sekunden Bootzeit meines > Fluke 287 Multimeters denke... > Da greif ich SEHR oft lieber zum 50 EURO Billigteil weil es nicht die > nervigen Gedenksekunden hat ;-) das geht auch schneller. Eine Frage des Softwaredesign. Die "Schallmauer" dürfte so bei knapp 2s. liegen. > Also ich find die Lösung mit dem "optionalen Linux" die wir anstreben > echt gut. In die API könnte man übrigens auch noch die Ansteuerung des > Frontpanels und abfrage von Tasten integrieren, dann wäre selbst Linux > mit dem standard Bedienpanel möglich. > Dann wäre Linux auch noch zu einem späteren Zeitpunkt interessant für > mich. > Den für einige scheinbar überflüssigen µC der auf der dann Radioplatine > sitzt ist nicht so abwegig, jedes USB device hat auch einen extra µC... 100% ACK Wenn auf dem Motherboard ein eigener µC steckt, kann man den/die Tuner via API vernünftig steuern. Das Selbe gilt für Audio. Ausserdem sollte der sich ja schliesslich auch um das ganze RDS-Zeugs kümmern. Harry
Christian H. schrieb: >> Ah, OK. Danke! >> Selbe Frage dann an den Ersteller :-) > Antwort: Ja. Es war TMC gemeint ;-) OK, super. Möchte nur kurz hierauf hinweisen: http://osar.it-livetalk.de/index.php/Diskussion:Basis_Features
kurzer Einwurf bzgl. Bootzeiten: wie schnell "booten" denn Eure bisherigen Radios so? ;-) Also meines ist jedenfalls nicht sofort nach dem Einschalten bereit, es dauert schon einen Moment bis Musik kommt (hab' es nie gestoppt, schätzungsweise 2-3 Sekunden sind es aber bestimmt). Klar wäre es schön wenn das schneller ginge, aber für mich zumindest ist so eine Verzögerung von wenigen Sekunden kein Problem. Ansonsten wäre immer noch die Möglichkeit das ganze mit der ZV zu koppeln, sodass das Radio schon zu booten beginnt sobald man den Wagen aufschließt (mache ich z.B. zur Zeit schon so mit einem GPS-Empfänger; soweit ich gelesen habe machen aktuelle Werksnavis das auch so). Gruß, Mathias
Kai G. schrieb: > Also ich find die Lösung mit dem "optionalen Linux" die wir anstreben > echt gut. In die API könnte man übrigens auch noch die Ansteuerung des > Frontpanels und abfrage von Tasten integrieren, dann wäre selbst Linux > mit dem standard Bedienpanel möglich. ja, so denke ich mir auch dass es am besten wäre. > Den für einige scheinbar überflüssigen µC der auf der dann Radioplatine > sitzt ist nicht so abwegig, jedes USB device hat auch einen extra µC... falls Du da u.a. meinen Beitrag meintest wo ich schrieb dass man den MP3-uC weglassen könnte wenn man das Linuxsystem nutzt: ich war davon ausgegangen, dass für MP3 ein großer Controller nötig ist, für die Grundfunktionen des Radios (also alles außer MP3) aber ein deutlich kleinerer Controller reichen müsste - oder? Falls die Annahme nicht stimmt wäre mein Einwand eh hinfällig. Und ich war irgendwie davon ausgegangen, dass so ein Controller im Bedienteil sitzt und somit auf dem Mainboard keiner mehr sein müsste -- merke aber jetzt erst, dass davon ja noch gar nie die Rede war ;-) Also auch wenn ich ein Linux-System einsetzen möchte, habe ich nichts gegen einen zusätzlichen Controller im Radio. Im Gegenteil, es gibt ja doch ein paar zeitkritische Dinge die auch ich gerne vom Linuxsystem fernhalten würde. Im Idealfall kommt man dann ohne eigene Hardwaretreiber im Linux aus, d.h. dass alles was irgendwie auf Interrupts o.ä. angewiesen ist vom Radio-uC übernommen wird. Auch könnte dieser uC falls nötig die Ein-/Ausschaltlogik übernehmen (dazu sollte es halt einer sein der zumindest im Sleep wirklich wenig Strom aufnimmt da er ja dann immer "am Netz" wäre). Aus meiner Sicht wäre hier ein Kompromiss zu suchen zwischen einem sparsamen, billigen, einfach zu beschaffenden Controller und einem der MP3 kann. Jedenfalls wenn diejenigen die kein Linux einsetzen möchten gerne alles in einem Controller hätten; ansonsten wäre das ja egal. Viele Grüße Mathias
Mathias A. schrieb: >> Den für einige scheinbar überflüssigen µC der auf der dann Radioplatine >> sitzt ist nicht so abwegig, jedes USB device hat auch einen extra µC... > falls Du da u.a. meinen Beitrag meintest wo ich schrieb dass man den > MP3-uC weglassen könnte wenn man das Linuxsystem nutzt: ich war davon > ausgegangen, dass für MP3 ein großer Controller nötig ist, für die > Grundfunktionen des Radios (also alles außer MP3) aber ein deutlich > kleinerer Controller reichen müsste - oder? > Falls die Annahme nicht stimmt wäre mein Einwand eh hinfällig ;-) für mp3 reicht ein normaler arm7 ohne externes ram und flash. Die lpc teile von nxp sind gut beschaffbar. Wenn man von 72 mhz takt und maximaler mp3 bitrate braucht man wenn ich mich recht erinner inklusive sd-karten kommunikation, i2s handling, ... so ca. 70% cpu zeit. bei 128 kbit und co natürlich weniger, aber man muss ja vom worst case ausgehen. Da bleibt noch genug zeit für parallele Aufgaben.
> kurzer Einwurf bzgl. Bootzeiten: wie schnell "booten" denn Eure > bisherigen Radios so? ;-) Wenn ich mit meinem bisherigen Radio in irgendeiner Form zufrieden waere dann muesste ich hier nicht meine Zeit verschwenden sondern koennte meinem Toaster einen SD-Slot verpassen. .-) > Aus meiner Sicht wäre hier ein Kompromiss zu suchen zwischen einem > sparsamen, billigen, einfach zu beschaffenden Controller und einem der > MP3 kann. Ich weiss noch nicht ob der von mir propagierte SuperH beschaffbar ist, werde ich wohl erst naechste Woche rausfinden koennen, aber ich glaube nicht das der teuerer als 10Euro ist. Der Preis ist also ein Witz im Vergleich zum Restdesign. Teuer oder billig wird soetwas erst durch den Aufwand den ein Controller verursacht (oder eben nicht. Also z.B Programmieradapter, Entwicklungssystem, Platinenflaeche/lagen usw. Der SH7262 laeuft mit 133Mhz und hat mit einem MP3 Strom bestimmt keine Probleme. Ich habe letzte Tage die Werbung von einem anderem Typen mit 200Mhz gelesen wo Renesas davon sprach das dort mehrere MP3stroeme und mehrere VIdeostroeme gleichzeitig verarbeitet werden koennten! BTW: Der SH7262 koennte nicht nur MP3 dekodieren sondern zeitgleich Videodaten einlesen und auf einem LCD darstellen. Das brauchen wir zwar nicht, aber das war wohl gedacht um damit eine Rueckfahrkamera oder aehnliches benutzen zu koennen. Aber zeigt wohl das da noch Reserven drin sind. :-) > für mp3 reicht ein normaler arm7 ohne externes ram und flash. Wie laeuft da eigentlich die Sampleratenwandlung wenn das MP3 nicht 44.1 ist? Ist sowas nicht sehr aufwendig? Ich meine die fertigen WandlerICs von AD suchen da irgendwo das kleinste gemeinsame VIelfache im Ghz-Bereich. Deshalb war ich ueberrascht das der SH-2A das bereits eingebaut hat. > so ca. 70% cpu zeit. Ich gebe zu ich kann das schwer abschaetzen da mir da jetzt die Erfahrung fehlt, aber ist das nicht knapp wenn da noch digitale Filter laufen sollen? Olaf
Kai G. schrieb: > Christian H. schrieb: >>> Ah, OK. Danke! >>> Selbe Frage dann an den Ersteller :-) >> Antwort: Ja. Es war TMC gemeint ;-) > > OK, super. > > Möchte nur kurz hierauf hinweisen: > http://osar.it-livetalk.de/index.php/Diskussion:Basis_Features Ok, habe ich gelesen und nochmal ergänzt. freeTMC sollte aber möglich sein: http://de.wikipedia.org/wiki/Transport_Protocol_Experts_Group TMCpro natürlich nicht, da verschlüsselt und kostenpflichtig. Aber zumindest die Möglichkeit zum Empfang sollte gegeben sein. Zitat Wikipedia "Zur Nutzung von TMC ist ein TMC-fähiger Radio-Empfänger notwendig".
Olaf Kaluza schrieb: > Wenn ich mit meinem bisherigen Radio in irgendeiner Form zufrieden waere > dann muesste ich hier nicht meine Zeit verschwenden sondern koennte > meinem > Toaster einen SD-Slot verpassen. .-) Oh ja, ein programmierbarer Motivtoaster. Wer Videos haben will kann eine eingebaute Daumenkinofunktion nutzen ;-) > Der SH7262 laeuft mit 133Mhz Sehr gut, da ausserhalb des FM bandes ;-) > BTW: Der SH7262 koennte nicht nur MP3 dekodieren sondern zeitgleich > Videodaten einlesen und auf einem LCD darstellen. Das brauchen wir zwar > nicht, aber das war wohl gedacht um damit eine Rueckfahrkamera oder > aehnliches benutzen zu koennen. Aber zeigt wohl das da noch Reserven > drin sind. :-) Klingt gut! Da es hobby ist und Spaß machen soll fühl ich mich wohler damit als mit so einem begrenzten Arm7 design. Wäre schön wenn man an das Teil gut drankäme. >> für mp3 reicht ein normaler arm7 ohne externes ram und flash. > Wie laeuft da eigentlich die Sampleratenwandlung wenn das MP3 nicht 44.1 > ist? Ist sowas nicht sehr aufwendig? Codecs mit denen ich gearbeitet haben machen selbst keine Ratenkonvertierung. Solange man nicht mischt (use-case??) kann man die Samplerate von Ausgangs-DAC umschalten. >> so ca. 70% cpu zeit. > Ich gebe zu ich kann das schwer abschaetzen da mir da jetzt die > Erfahrung fehlt, aber ist das nicht knapp wenn da noch digitale Filter > laufen sollen? Ja, sollte gehen, wird aber wohl ein sattes schmatzendes Geräusch von sich geben wenn man es noch dazubaut ;-)
Christian H. schrieb: > Ok, habe ich gelesen und nochmal ergänzt. > freeTMC sollte aber möglich sein: > http://de.wikipedia.org/wiki/Transport_Protocol_Experts_Group Wie kommen wir an die Übersetzungstabellen? An die "Zahleninformationen"/Rohdaten zu kommen ist mit RDS kein Problem, aber das in etwas verständliches umzusetzen schon. > Aber zumindest die Möglichkeit zum Empfang sollte gegeben sein. > Zitat Wikipedia "Zur Nutzung von TMC ist ein TMC-fähiger Radio-Empfänger > notwendig". Klar, Empfang und loging ist kein Problem!
Kai G. schrieb: > Wie kommen wir an die Übersetzungstabellen? An die > "Zahleninformationen"/Rohdaten zu kommen ist mit RDS kein Problem, aber > das in etwas verständliches umzusetzen schon. Ok, ich verstehe das Problem jetzt auch. Ich wusste nicht, das hier Informationsmangel besteht, sondern dachte, dass das Protokoll offen wäre. Schade eigentlich :-(
Christian H. schrieb: > Ok, ich verstehe das Problem jetzt auch. > Ich wusste nicht, das hier Informationsmangel besteht, sondern dachte, > dass das Protokoll offen wäre. > Schade eigentlich :-( Find ich auch, aber ohne die Bunten Scheine finanziert sich so eine Infrastruktur leider nicht ;-(
Hallo, hab das ganze mal überflogen und würde gerne dabei mitwirken. Wenn ihr Platz für Homepage und FTP oder auch SVN Server braucht, da kann ich euch gerne unterstützen.
Reinhard S. schrieb: > Kann es sein, das das Wiki grad offline ist? normalerweise nicht. Aber der Schnellste ist der Server nicht, und das Wiki ist da eher ein "Trittbrettfahrer". Harry
Harald L. schrieb: > Reinhard S. schrieb: >> Kann es sein, das das Wiki grad offline ist? > > normalerweise nicht. > Aber der Schnellste ist der Server nicht, und das Wiki ist da eher ein > "Trittbrettfahrer". > > Harry Bei mir kommt aber zur Zeit, und das ziemlich direkt nach der Anfrage, "Server nicht erreichbar". www.it-livetalk.de geht aber ohne Probleme.
Reinhard S. schrieb: > Harald L. schrieb: >> Reinhard S. schrieb: >>> Kann es sein, das das Wiki grad offline ist? >> >> normalerweise nicht. >> Aber der Schnellste ist der Server nicht, und das Wiki ist da eher ein >> "Trittbrettfahrer". >> >> Harry > > Bei mir kommt aber zur Zeit, und das ziemlich direkt nach der Anfrage, > "Server nicht erreichbar". > > www.it-livetalk.de geht aber ohne Probleme. Das ist aber auf der selben Maschine. Du bist nicht zufällig bei Versatel?....Aus der Richtung sind einige Beschwerden in den letzten Tagen gekommen. Harry
...bei mir kommt das wiki ohne Fehlermeldung, habe es gerade nochmal probiert: http://osar.it-livetalk.de/index.php/Hauptseite Olaf Kaluza schrieb: >> kurzer Einwurf bzgl. Bootzeiten: wie schnell "booten" denn Eure >> bisherigen Radios so? ;-) > > Wenn ich mit meinem bisherigen Radio in irgendeiner Form zufrieden waere > dann muesste ich hier nicht meine Zeit verschwenden sondern koennte > meinem > Toaster einen SD-Slot verpassen. .-) ok, stimmt auch wieder :D Am Rande, ich finde es irgendwie schon interessant wie unterschiedlich die Ansprüche an das Radio so im Detail sind obwohl ja auf den ersten Blick alle das selbe wollen, eben ein Radio mit Tuner und MP3 und evtl noch ein paar Spielereien. Ist ja nicht schlimm, ich denke da wird sich schon ein Kompromiss finden lassen der für viele passt.. Gruß Mathias
Harald L. schrieb: >> Bei mir kommt aber zur Zeit, und das ziemlich direkt nach der Anfrage, >> "Server nicht erreichbar". >> >> www.it-livetalk.de geht aber ohne Probleme. > Das ist aber auf der selben Maschine. > > Du bist nicht zufällig bei Versatel?....Aus der Richtung sind einige > Beschwerden in den letzten Tagen gekommen. Nein, ecotel. Scheint aber ein DNS-Problem zu sein, bei osar.it-livetalk.de bekomme ich keine IP zurück, bei www... schon
Reinhard S. schrieb: > Harald L. schrieb: > >>> Bei mir kommt aber zur Zeit, und das ziemlich direkt nach der Anfrage, >>> "Server nicht erreichbar". >>> >>> www.it-livetalk.de geht aber ohne Probleme. >> Das ist aber auf der selben Maschine. >> >> Du bist nicht zufällig bei Versatel?....Aus der Richtung sind einige >> Beschwerden in den letzten Tagen gekommen. > > Nein, ecotel. Scheint aber ein DNS-Problem zu sein, bei > osar.it-livetalk.de bekomme ich keine IP zurück, bei www... schon Genau das Selbe haben mir in den letzten Tagen 2 Versatel-Kunden berichtet. Bei allen anderen scheint es keine Probleme zu geben. Interessant ist, daß das Problem scheinbar nur sporadisch auftritt. Harry
Kai G. schrieb: ... > Was haltet Ihr davon? Die Liste ist nur als Vorschlagliste zu verstehen > und natürlich nicht 100% fest. > Als CPU schwebt mir etwas in der Richtung Arm9E, evtl. auch etwas > Cortex-mäßiges vor (NXP hat hier unter den LPCs z.B. einige Kandidaten). > 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. Ich denke dass hier ein SoC (system on chip) besser geeignet wäre. Als Betriebssystem Linux! Durch die flexibilität und schlankheit von kleinen embedded Linux Distributionen lässt sich hier nahezu alles möglich damit anstellen. Als gutes Beispiel die Dbox oder Dreambox ;-) gruss Michael
So ich habe mir diesen Thread nun auch mal durchgelesen. Ansich sehr interessantes Projekt. Im Rahmen meiner Möglichkeiten würde ich auch versuchen etwas beizusteuern. Wie sieht das eigentlich mit einer Integration/Modul für ipod/iphone aus? Fänd ich persönlich recht praktisch aber das könnte man ja gegebenfalls auch als Modul ausführen.
Harald L. schrieb: > Reinhard S. schrieb: >> Kann es sein, das das Wiki grad offline ist? > > normalerweise nicht. > Aber der Schnellste ist der Server nicht, und das Wiki ist da eher ein > "Trittbrettfahrer". > > Harry dann nehmt doch die Wiki hier... meine Güte wenn ihr schon das SVN hier nutzen wollt...
... ... schrieb: > Harald L. schrieb: >> Reinhard S. schrieb: >>> Kann es sein, das das Wiki grad offline ist? >> >> normalerweise nicht. >> Aber der Schnellste ist der Server nicht, und das Wiki ist da eher ein >> "Trittbrettfahrer". >> >> Harry > > dann nehmt doch die Wiki hier... meine Güte wenn ihr schon das SVN hier > nutzen wollt... Mal ne blöde Frage: WO verlinkt man denn die Seite hier im Wiki. Ich sehe links nirgendwo ein "Projekte" link oder so...
Michael Wulz schrieb: > Ich denke dass hier ein SoC (system on chip) besser geeignet wäre. > Als Betriebssystem Linux! Och nö, nicht schon wieder... ;-) > Durch die flexibilität und schlankheit von kleinen embedded Linux > Distributionen lässt sich hier nahezu alles möglich damit anstellen. > Als gutes Beispiel die Dbox oder Dreambox ;-) Und wenn man den Schraubendreher nimmt und die Dreambox aufschraubt findet man nur eine einzige CPU? Versucht das Radio doch mehr als Peripherie von dem Linuxrechner zu sehen.
@Harald:
Die Startseite sieht ja ganz nett aus ("Marketingmässig"), aber so muss
man immer an 2 Stellen editieren um alles konsistent zu halten. Siehe
z.B. "CPU".
Kai G. schrieb: > @Harald: > > Die Startseite sieht ja ganz nett aus ("Marketingmässig"), aber so muss > man immer an 2 Stellen editieren um alles konsistent zu halten. Siehe > z.B. "CPU". @Kai ich hab das eben ein wenig umstrukturiert. Mit der bisherigen Lösung war ich auch nicht glücklich. Harry
ARM 7 ? sind die nicht schon etwas in die Jahre gekommen ? Da wär doch ein moderner ARM Cortex M3 besser ?
Patrick Weinberger schrieb: > ARM 7 ? sind die nicht schon etwas in die Jahre gekommen ? Da wär doch > ein moderner ARM Cortex M3 besser ? schau mal in den 1. post :-)
Ich gebe zu, dass das Design mit einem ARM7 sicherlich kleiner erscheint, muss aber aus eigener Erfahrung feststellen, dass es das nicht ist. Man sollte halt nicht Windows-Like programmieren, sondern etwas Ahnung von der Hardware, die man nutzt, haben. Trotzdem ist es verführerisch, einfach Linux zu nutzen ( ich würde einen der größeren AVR32 vorziehen, aber egal) und dann mit anderen Tricks die Bootzeit verkürzen. Hat man eine ordentliche Stromversorgung designt, kann das Radio schon mal booten, wenn das Netz aktiviert wird, also z.B. beim Türe öffnen oder Schlüssel in Stellung 1. Es muss ich ja dann nicht gleich mit allem Melden, was es hat. Endstufe und Display können ebenso im Power-Down bleiben, wie Festplatte oder CD/DVD Drive. Das spart genug Energie, um auch über den Einbruch durch den Startvorgang hinweg zu kommen. Erst, wenn man es einschaltet, werden die nötigen anderen Baugruppen aktiviert. Da es ein Open-Source/-Hardware Projekt werden soll, sollte man über das oben schon genannte Topic verteilte Controller mal genauer nachdenken. Gerade wenn unterschiedliche Displays, Frontplatten, Laufwerke und Tuner in der Vorstellung der Mitmacher existieren, kann man mit klar definierten Protokollen auf klar definierten Schnittstellen der Vielfalt freien Lauf lassen. Außerdem kann das Projekt so in klare Aufgabenbereich getrennt werden. Doppeltuner haben i.d.R. zwei Aufgaben: Einer gibt das eingestellte Programm wieder, der Andere sucht a) nach TMC Daten und b) nach dem gleichen Sender anhand der RDS-Frequenz-Tabelle mit möglicherweise besserem Empfang. Ergibt b) einen Treffer, wird Tuner 1 ganz schnell umgeschaltet. Dafür muss Tuner 2 Audio-Seitig überhaupt nicht verbunden sein. Das Verfahren ist bei den Guten in dieser Branche durchaus üblich. Der Vorteil zweimal den gleichen Tuner zu nehmen, liegt darin, dass man die Library nur einmal schreiben muss, um ihn zu bedienen. @Harald L. Von wegen Linux bashing. Ich nutze es selbst auch auf kleinen Plattformen wie AT91SAM9XE, AVR32, iMX25... Es kam mir nur nicht gleich die Idee das System vor zu starten, so dass der Fahrer trotz ein paar Sekunden Boot-Zeit das Gefühl hat, dass gleich nach dem Start des Motors auch Musik da ist. Es gibt noch mehr Möglichkeiten da zu tricksen. So könnte der Treiber für die Tuner deren vorheriges Preset einfach direkt beim Modul Init schon wieder aktivieren. Ein Scheiben-Medium HDD, CD, DVD braucht eh einige SpinUp Zeit, auch hier kann schon sehr früh ein Trigger erfolgen. Und es gibt ja auch noch die Sache mit den Sleep-Modis. Eventuell ist ein Neustart ja garnicht nötig, aber damit habe ich bislang keine Erfahrung. Gruß, Ulrich
@Ulrich P. In weiten Bereichen stimm ich dir zu! Ob wir auf dem Mainboard tatsächlich Linux brauchen, wage ich zu bezweifeln, da es sich dabei aus logischer Sicht "nur" um ein Peripheriegerät handelt. du kennst unser Wiki dazu? http://osar.it-livetalk.de Gruss Harry
> Da es ein Open-Source/-Hardware Projekt werden soll, sollte man über das > oben schon genannte Topic verteilte Controller mal genauer nachdenken. > Gerade wenn unterschiedliche Displays, Frontplatten, Laufwerke und Tuner > in der Vorstellung der Mitmacher existieren, kann man mit klar > definierten Protokollen auf klar definierten Schnittstellen der Vielfalt > freien Lauf lassen. Außerdem kann das Projekt so in klare > Aufgabenbereich getrennt werden. Aufgeben trennen geht doch mit getrennten Controllern fast noch besser?!? > Doppeltuner haben i.d.R. zwei Aufgaben: Einer gibt das eingestellte > Programm wieder, der Andere sucht a) nach TMC Daten und b) nach dem > gleichen Sender anhand der RDS-Frequenz-Tabelle mit möglicherweise > besserem Empfang. Ergibt b) einen Treffer, wird Tuner 1 ganz schnell > umgeschaltet. Dafür muss Tuner 2 Audio-Seitig überhaupt nicht verbunden > sein. Das Verfahren ist bei den Guten in dieser Branche durchaus üblich. > Der Vorteil zweimal den gleichen Tuner zu nehmen, liegt darin, dass man > die Library nur einmal schreiben muss, um ihn zu bedienen. Also wer sich ein "teuren" 2. Tuner ins Radio baut wird ihn nicht nur als einfachen RDS-Backgroundtuner einsetzen. In fast allen Radios mit mehr als einem Tuner sind verschiedene Empfangsverbesserungskonzepte zu finden: space diversity (2 Antennen) oder Frequency diversity (1 Antenne). Um RDS Alternativfrequenzen auf Qualität zu checken braucht es übrigens überhaupt keinen 2. Tuner. Das geht mit einem Tuner und ist unhörbar solange man nicht gerade einem unmoduliertem Trägersignal zuhört und das RDS AF Processing mit Sinn und Verstand implementiert wurde. Der 2. Audioteil ist als optional gekennzeichnet und hat seine Daseinsberechtigung für freq. diversity. Hinweis: Sender habe unterschiedliche Positionen und unterschiedliche Delays.
> Hat man eine ordentliche Stromversorgung designt, > kann das Radio schon mal booten, wenn das Netz aktiviert wird, also z.B. > beim Türe öffnen oder Schlüssel in Stellung 1. Es muss ich ja dann nicht > gleich mit allem Melden, was es hat. Endstufe und Display können ebenso > im Power-Down bleiben, wie Festplatte oder CD/DVD Drive. Wie willst Du Tür offen oder Schlüssel in Stellung 1 detektieren? Über CAN bus messages? Tür offen gibt es nicht als Signal am standard DIN stecker (und das Licht-signal reagiert nicht immer). Bei Schlüssel in Stellung 1 ist wenn ich mich nicht ganz täusche die Zündspannung am DIN stecker noch nicht an, bzw. man erwartet schon das das Radio an ist. 3-4 Sekunden bootzeit wären aber denk ich noch akzeptabel sein.
Kai G. schrieb: > 3-4 Sekunden bootzeit wären aber denk ich noch akzeptabel sein. <nicht_ganz_ernst_gemeint> Dann sollte man das Radio vor fremden Blicken hinter einer automatisch aufklappenden Dummy-Front verstecken. Sobald die Blende komplett offen ist, ist auch Linux komplett hochgefahren. ;-) </nicht_ganz_ernst_gemeint>
Christian H. schrieb: > Kai G. schrieb: >> 3-4 Sekunden bootzeit wären aber denk ich noch akzeptabel sein. > > <nicht_ganz_ernst_gemeint> > Dann sollte man das Radio vor fremden Blicken hinter einer automatisch > aufklappenden Dummy-Front verstecken. Sobald die Blende komplett offen > ist, ist auch Linux komplett hochgefahren. ;-) > </nicht_ganz_ernst_gemeint> <auch_nicht_ganz_ernst_gemeint> Hmmm... Eigentlich hatte ich doch geschrieben "keine Transformer/UFO optik" :-) Hey, der Vorteil eines extra linux-losen µCs wäre das man das frontausfahren an sich schon mit einem extrem *coolen* Sound unterlegen kann (dididididididi oder so) :-) </auch_nicht_ganz_ernst_gemeint>
<auch_nicht_ganz_ernst> wie wärs mit Dual-Touchscreen, der motorisch nach oben UND unten ausfährt :-D </auch_nicht_ganz_ernst> Harry p.s. für die Auslandsaufenthalte wäre ich nach wie vor für die Integration (oder zumindest Schnittstelle) eines Universal-Translator(tm StarTrek)
Hmm, hab mir mal den AT32UC3A3256 (AVR32) angeschaut. Sieht auch nicht schlecht aus: * 128 KB Ram * 256 KB Flash * Stereo Sigma-delta Audio DAC * I2S, I2Cs, Uarts, ... Mit AVR32 hab ich noch keine Erfahrung. Kann jemand mal was dazu schreiben? Was braucht man zum programmieren/Debuggen? Gibts GCC support? Wie "gut" sind die Teile? Lässt sich damit MP3 mit genügend reserven für andere Dinge dekodieren? Gibts eine gute Bezugsquelle? Kündigt Atmel die AVR32's auch so gerne & oft ab wie seine 8 bit AVRs??
Patrick Weinberger schrieb: > Wie lang braucht eigentlich das Laden einer MP3 Datei von einer SD-Karte > ? > (kaltstart) Wenn Du die Latenz von "Playknopf drücken" bis Audiosignal meinst: Nicht merkbar => millisekunden Die Datei wird nie komplett in den Speicher geladen. Es wird lediglich einmal kurz am ende nach ID3V1 geschaut, dann am Anfang nach ID3V2 und dann gestartet.
Kai G. schrieb: > Die Datei wird nie komplett in den Speicher geladen. Es wird lediglich > einmal kurz am ende nach ID3V1 geschaut, dann am Anfang nach ID3V2 und > dann gestartet. Falsche Reihenfolge! * IDv2 lesen ** falls nicht vorhanden -> IDv1 PLAY oder Mutithreaded....erst Play....parallel ID einlesen Harry
Das laden des Dateisystem dauert ja etwas usw also sicher 100ms delay. Für einen einfachen Radio macht das Booten kein problem. Der Renesas wär ganz geil wegen den 4 I2S. Das haben die ARM leider ned :-( Mit dem Renesas könnte man 2 I2S für Erweiterungen zur verfügung stellen und die anderen beiden für Radio und Endstufe. MFG
Christian H. schrieb: > <nicht_ganz_ernst_gemeint> > Dann sollte man das Radio vor fremden Blicken hinter einer automatisch > aufklappenden Dummy-Front verstecken. Sobald die Blende komplett offen > ist, ist auch Linux komplett hochgefahren. ;-) > </nicht_ganz_ernst_gemeint> Geht doch: http://www.cartft.com/catalog/il/1228 Und nebenbei hätte man sogar das Problem des Gehäuses gelöst. ;-) :-D :-D
Harald L. schrieb: >> Die Datei wird nie komplett in den Speicher geladen. Es wird lediglich >> einmal kurz am ende nach ID3V1 geschaut, dann am Anfang nach ID3V2 und >> dann gestartet. > Falsche Reihenfolge! Nö, da hab ich schon länger drüber nachgedacht. Es heisst ja auch nicht das die Anzeige der ID3V2 tags Vorrang vor ID3V1 hat. Um nicht auf dem Medion-Niveau zu liegen muss man auch ein Mindestmass an Fehler handeln und wenn man schnell sein will auch drüber nachdenken was intern im Filesystem passiert wenn man filepointer umsetzt, wie man durch eine gute Reihenfolge vermeidet die selben Sachen mehrmals zu machen, ... ID3V1 und ID3V2 immer beide zu lesen hat volgende Vorteile: - Warum sollte man den ID3V1 tag durch den MP3 decoder jagen? OK, mehr eine glaubensfrage weil der ID3 tag dank fehlendem synchronization pattern nicht dekodiert wird... solange wie: - Wenn der letzte MP3Frame offen ist, was auch in der Realität dank komischer mp3 Trimtools vorkommt hört man am Ende seiner Songs kein "Blurp". - In ID3V2 ist es nicht verpflichtend album, titel, ... abzulegen. Es gibt Leute die nur Ihr MP3 cover mit einem automatischen Tool als ID3V2 ins MP3 kloppen. Wenn man ID3V1 liesst hat man die fallback option - Wenn man erst ID3V1 liesst muss das Filesystem sich einmal durch die FAT hangeln, das geht schnell. Den echten Anfang der MP3 frames bei ID3V2 zu finden ist nicht so easy weil in ID3V2 nicht direkt im Header steht wie lang der Tag ist (komisch) und man sich erstmal durch die header der einzelnen tags hangeln muss. Der Vorteil der ID3V1/ID3V2 Reihenfolge: Wenn man also den ID3V2 als letzten Schritt vor dem MP3 abspielen liesst, steht der Filepointer schon direkt an der richtigen Position. Sich durch die ID3V2 zu arbeiten heisst übrigens echt Daten von dem Datenträger zu lesen und nicht wie z.B. beim springen zum ID3V1 tag einfach nur den filepointer umzusetzen wobei sich fast nur einmal durch die FAT gearbeitet wird. > oder Mutithreaded....erst Play....parallel ID einlesen Gerade das will man nicht weil dann muss sich der Controller zweimal durch die ID3V2 hangeln. Erklärung siehe oben.
Hallo zusammen, spät aber hoffentlich noch nicht zu spät der Vorschlag eine "Vorrangschaltung" zum Anschluss eines Navigationsgerätes vorzusehen. Mini-Buchse 3,5mm Stereo dürfte reichen. Für alle die nicht wissen was gemeint ist oder es schon wieder vergessen haben hier noch folgende Erklärung. Eine Vorrangschaltung senkt das Tonsignal der Hauptquelle ab und hebt das Tonsignal des vorrangig zu behandelden Einganges an. Gab's früher auch mal als DJ-Schaltung usw. Gruss Roman
Roman schrieb: > spät aber hoffentlich noch nicht zu spät der Vorschlag eine > "Vorrangschaltung" zum Anschluss eines Navigationsgerätes vorzusehen. > Mini-Buchse 3,5mm Stereo dürfte reichen. Für alle die nicht wissen was > gemeint ist oder es schon wieder vergessen haben hier noch folgende > Erklärung. Eine Vorrangschaltung senkt das Tonsignal der Hauptquelle ab > und hebt das Tonsignal des vorrangig zu behandelden Einganges an. Gab's > früher auch mal als DJ-Schaltung usw. Ja, ist vorgesehen (Basis-features), allerdings noch nicht im Blockschaltbild erfasst, schau mal im Wiki.
oh nein, ich mutiere zum Analphabeten! Wenn ich sowas hier in meinen eigenen posts lese: "volgende" ...dann wird mir ganz übel. Kurze Erklärung: Ich schreib ab und zu mal auf Niederländisch und da wird halt viel mit v statt f geschrieben.
Roman schrieb: > Hallo zusammen, > > spät aber hoffentlich noch nicht zu spät der Vorschlag eine > "Vorrangschaltung" zum Anschluss eines Navigationsgerätes vorzusehen. > Mini-Buchse 3,5mm Stereo dürfte reichen. Für alle die nicht wissen was > gemeint ist oder es schon wieder vergessen haben hier noch folgende > Erklärung. Eine Vorrangschaltung senkt das Tonsignal der Hauptquelle ab > und hebt das Tonsignal des vorrangig zu behandelden Einganges an. Gab's > früher auch mal als DJ-Schaltung usw. Die Idee an sich okay, aber welches Navi hat einen Ausgang für evtl. Ansagen? Für Handy/Freisprecheinrichtung kann ich mir das ganz gut vorstellen, aber dafür gibts inzwischen ja eher Bluetooth :)
Reinhard S. schrieb: > Die Idee an sich okay, aber welches Navi hat einen Ausgang für evtl. > Ansagen? Hmm, hat das nicht jedes Navi? Die 3 in meinem Umfeld haben eine (Iphone/altes Typhoon PDS navi/relativ aktuelles Medion navi).
Kai G. schrieb: > Reinhard S. schrieb: >> Die Idee an sich okay, aber welches Navi hat einen Ausgang für evtl. >> Ansagen? > > Hmm, hat das nicht jedes Navi? Die 3 in meinem Umfeld haben eine > (Iphone/altes Typhoon PDS navi/relativ aktuelles Medion navi). ja ich denke auch, mein TomTom Navi hat das auch
Ich habe heute mal mit Glyn wegen dem Prozessor gesprochen. Der genaue Preis haengt vom genauen Typ und auch der Menge ab. Das Teil ist auch beschaffbar und auf Lager! Wuerden wir 80000Stk kaufen wuerden wir ihn wohl im Bereich von 10Euro bekommen, kaufen wir nur 10Stk liegt er so bei knapp 20Euro maximal. Realistisch ist also wohl irgendwas zwischen 15 und 20Euro. Ich denke mal kein Problem. Ehrlich gesagt finde ich das sogar fast geschenkt wenn man den Preis eines anderen Prozessors+externesRam+Aufwand bedenkt! Netterweise war Glyn sehr angetan und entgegenkommend und schenkt mir ein Entwicklungskit mit einem E10 drin. Das ist ein Debugger und der kostet sonst richtig Kohle! Normalerweise werden wir den Debugger zwar nicht brauchen, aber bei ernsten Problemen oder wenn man etwas im Bereich der USB-Schnittstelle programmiert koennte er ganz praktisch sein. Ich moechte daher vorschlagen den SH-2A offiziell als Prozessor fuer dieses Project zu verwenden und bitte um reichhaltige Zustimmung. .-) Olaf
olaf schrieb: > Ich moechte daher vorschlagen den SH-2A offiziell als Prozessor fuer > dieses > Project zu verwenden und bitte um reichhaltige Zustimmung. .-) Ich bin stark dafür. Er hat einfach alles was wir brauchen. Du kannst nicht zufällig noch mehr... ;-)
Kai G. schrieb: > olaf schrieb: >> Ich moechte daher vorschlagen den SH-2A offiziell als Prozessor fuer >> dieses >> Project zu verwenden und bitte um reichhaltige Zustimmung. .-) > > Ich bin stark dafür. Er hat einfach alles was wir brauchen. > Du kannst nicht zufällig noch mehr... ;-) Ich bin auch dafür. Renesas ist eine gute Lösung, da Renesas speziell im Automotive Bereich entwickelt und daher dieser Prozessor für solche Anwendungen optimal ist.
> Du kannst nicht zufällig noch mehr... ;-)
Du kannst ja mal auf die Traenendruese druecken. :-)
Ich habe Glyn mal den Link auf diese Diskussion und
auf die Wikiseite geschickt....
Aber was solls. Wer sich keine 20Kroeten fuer den Prozessor leisten
kann ist bei dem Projekt sowieso falsch.
Was den E10 angeht, das sind immerhin etwa 1kEuro!
Wie gesagt, wir werden den meistens nicht brauchen. Sollte den doch mal
einer unbedingt brauchen dann dachte ich das wir den einfach mal
rumschicken. Aber die USB-Schnittstelle erlaubt wirklich alles was man
so braucht, ausser natuerlich Entwicklung von USB-Anwendungen selber.
Da ich heute morgen natuerlich mit ernsten Schlafstoerungen wegen der
Zeitumstellung <seufz> um vier aus dem Bett gefallen bin, habe ich die
Yeit genutzt und die Umgebung bei mir auf dem Hauptrechner installiert
und dabei genau dokumentiert was man da macht. Sobald klar ist das wir
den Proyessor nehmen, werde ich das mal im Wiki eintragen.
Olaf
BTW: Mir erzaehlte Burkhard (b.kainka) gerade das es demnaechst auch DRM
auf UKW geben soll. Falls mal einer Langweile hat und sich zu hoeherem
berufen fuehlt kann er das dann ja auch gleich implementieren. :-D
Olaf schrieb: > Wie gesagt, wir werden den meistens nicht brauchen. Sollte den doch mal > einer unbedingt brauchen dann dachte ich das wir den einfach mal > rumschicken. Aber die USB-Schnittstelle erlaubt wirklich alles was man > so braucht, ausser natuerlich Entwicklung von USB-Anwendungen selber. OK, klar. > Yeit genutzt und die Umgebung bei mir auf dem Hauptrechner installiert ^ unerwartetes Tastaturlayout? <bg> ;-) > BTW: Mir erzaehlte Burkhard (b.kainka) gerade das es demnaechst auch DRM > auf UKW geben soll. Falls mal einer Langweile hat und sich zu hoeherem > berufen fuehlt kann er das dann ja auch gleich implementieren. :-D Jo, das nennt sich DRM plus. Wir müssen "nur" die Möglichkeit schaffen das FM-Multiplexsignal digitalisieren zu können. Das gibt der TEF6616 her, allerdings nur analog. Dann haben wir alle Möglichkeiten... Und sei es nur als Experimentierplattform, das man das MPX Signal auf eine SD Karte schreiben um sich das ganze nachher in Ruhe mit matlab, scilabl, ... oder so anzuschauen. Edit: MPX ist natürlich Blödsinn da nicht mit FM Modulation gearbeitet wird, sondern OFDM, man müsste das ZF-Signal digitalisieren.
Zum Anfang wär vielleicht ein Evalboard für den SH7262 nicht schlecht, dass mal alle damit zum arbeiten anfangen können. Für dem die 15€ zuviel, der muss ja nicht unbedingt Mitarbeiten. MFG Patrick
Olaf schrieb: > BTW: Mir erzaehlte Burkhard (b.kainka) gerade das es demnaechst auch DRM > auf UKW geben soll. Ich vermute mal nicht in den nächsten 10 Jahren.
> Zum Anfang wär vielleicht ein Evalboard für den SH7262 nicht schlecht, > dass mal alle damit zum arbeiten anfangen können. Hm..daran habe ich schonmal gedacht. Ich habe mir und Kai aber schon das hier mitgebracht: http://www.youtube.com/watch?v=aj4oTCqEeks&feature=related Vielleicht kann man das ja auch fernbestellen: http://www.amazon.co.jp/Interface-インターフェース-2010年-06月号-雑誌/dp/B003D7CGYA Allerdings wenn ich das richtig sehe will Amazon dafuer 3200Yen. In Japan hat das Heft aber nur 22xxYen gekostet. Ratten! Ich werde heute abend mal 1-2Photos davon auf meine Seite werfen damit man mal einen Eindruck bekommt. Und wenn man es selber macht, was genau? Das Board oben aus dem Film hat alle(viele?) Leiterbahnen auf Pfostenstecker rausgefuehrt. Das sind wirklich SEHR duenne Leiterbahnen. Ich weiss nicht genau ob man das noch selber hinbekommt. Jetzt koennte man natuerlich einfach nur das dranhaengen was einem wichtig ist. Also z.B I2S, I2C, SPI-Flash usw. Aber dann sind wir gleich wieder bei der Radioplatine. Oder man macht die Platine groesser und fuehrt erstmal alle Beine gerade auf Pfostenstecker raus und macht nur SPI-Flash, Spannungregler und Kondensatoren drauf. Also im Prinzip das was ich vor einiger Zeit mal mit einem FPGA gemacht habe. Grundsaetzlich wuerde ich die Idee eines Testboards aber begruessen. Vorschlaege? BTW: Glyn hat nicht nur den SH7262, sondern auch den SH7264. Wenn ich das richtig gelesen habe (hab das Datenblatt auf dem Rueckflug gelesen und hatte nur 2.5h Akkulaufzeit :-) so sind die wohl identisch. Der 64er hat wohl nur ein groesseres Gehaeuse und dafuer ein paar Ports mehr und noch mehr Schnittstellen. BTW2: Was mich echt beindruckt hat, der Prozessor hat 1MB Ram das im Prinzip das macht was man davon erwartet. Und er hat nochmal 64k Fastram. Dieses Ram kann von zwei Devices GLEICHZEITIG ohne Waits genutzt werden. Also sozusagen Dualportram. Olaf
> Vorschlaege? Also ich wäre für ein Board wo alle pins rausgeführt sind (im quadrat auf 4 Steckleisten). Bei 0.5mm Pinabstand sollte man das noch hinbekommen. Alles was nah am µC sein sollte, sollte auf dem Board sein: Quarz(e), decoupling Kondensatoren, ... Die Frage bleibt: Wieviel wollen so ein board haben und ob sich der Aufwand lohnt und 3200 Yen sind nicht die Welt (knapp 30 EURO). Für den Preis bekommt man ein Board nicht selbst gemacht. > BTW2: Was mich echt beindruckt hat, der Prozessor hat 1MB Ram das im > Prinzip das macht was man davon erwartet. Und er hat nochmal 64k > Fastram. Dieses Ram kann von zwei Devices GLEICHZEITIG ohne Waits > genutzt werden. Also sozusagen Dualportram. Was mich am meisten freut ist die Floating point unit! D.h. Signal processing ohne Schmerzen :-)
Es müsst noch mindeszens 10 Stück von den Boards Besorgt werden oder ein eigenes entwickeln, bei einer Kleinserie (20+) würde sich auch das ätzen lassen der Platine auszahlen. Vielleicht gleich auch einen Audio Coedc drauf ...
Patrick Weinberger schrieb: > Es müsst noch mindeszens 10 Stück von den Boards Besorgt werden oder ein > eigenes entwickeln, bei einer Kleinserie (20+) würde sich auch das ätzen > lassen der Platine auszahlen. > Vielleicht gleich auch einen Audio Coedc drauf ... Bei 20+ kannst du sogar schon fast Kostenneutral die schlimmsten Bauteile maschinell mit bestücken lassen.
Kai G. schrieb: > Patrick Weinberger schrieb: >> Es müsst noch mindeszens 10 Stück von den Boards Besorgt werden oder ein >> eigenes entwickeln, bei einer Kleinserie (20+) würde sich auch das ätzen >> lassen der Platine auszahlen. >> Vielleicht gleich auch einen Audio Coedc drauf ... > > Bei 20+ kannst du sogar schon fast Kostenneutral die schlimmsten > Bauteile maschinell mit bestücken lassen. Das würd ich erst so ab 50 oder gar 100 Stück anraten. Aber das Ätzen von 15-20 Platinen von Hand mit TQFP 208 zu fertigen ist nimmer grad einfach. Deswegen kommt man mit extern Fertigen lassen besser davon.
Interessantes Board! Gibts da nähere Info's dazu? Wenn ich mir das hier so durchlese, bin ich gespannt wie lange ich als Hobby-Löter noch mithalten kann. :( Einerseits sind wir schon bei Bauteil-"größen" angekommen die mich erschaudern lassen und zum Anderen bin ich mir nicht sicher ob für sowas meine Programmierkenntnise ausreichen.
Pezi schrieb: > erschaudern lassen und zum Anderen bin ich mir nicht sicher ob für sowas > meine Programmierkenntnise ausreichen. Das ist der Vorteil eines Comunity-Projekt: Man muss gar nicht alles selber können ;) Harry
Patrick Weinberger schrieb: > Wer hat erfahrung mit dem Layout von soetwas ? Ich hab schon Layouts für chips in der Größenordnung gemacht. Hab schon Kleinserien von 15 Stück maschinell bestücken lassen. So teuer ist es nicht, vor allen dingen nicht wenn man über nur einen chip redet. Naja so 5 Boards würd ich noch von Hand bestücken falls es sich jmd. nicht selber zutrauen würde die µCs zu löten.
Ok also zu anfang ein Board mit sh7264, Audio CODEC, SPI Flash, CAN Treiber und vielleicht ein kleines S(D)RAM. Ich werd glaub dann mal nen Thread hier aufmachen wer so ein Board will. MFG
Patrick Weinberger schrieb: > Ok also zu anfang ein Board mit sh7264, Audio CODEC, SPI Flash, CAN > Treiber und vielleicht ein kleines S(D)RAM. Sollen wir nicht erstmal die abchecken ob man das Japan-Board nicht irgendwo kaufen kann und uns um ein Mainboard kümmern? Bei dem RAM vertrete ich natürlich die Meinung das wir intern schon mehr als genug haben :-) > Ich werd glaub dann mal nen Thread hier aufmachen wer so ein Board will. Ich hoffe dann kommen nicht 50 Leute zusammen die nichts von dem Radio wissen wollen und am Ende alles anders haben wollen :-)
Kai ich würd mal so sagen jeder kann das CPU Board haben solang bezahlt wird. Aber man kann ja mal paralell fragen wer so ein board will, falls das board aus japan vrfügbar ist so kann man ja das verschicken stat dem eigenentwickelten. Bei dem RAM bin ich anderer Meinung 1 MB klingt nach viel aber wenn man etwas spielen will mit dem board oder zB sachen zum analysieren eines RF-Signals braucht man schon etwas RAM um die daten dort zu Puffern ... mfg Patrick
Patrick Weinberger schrieb: > Kai ich würd mal so sagen jeder kann das CPU Board haben solang bezahlt > wird. Klar, das meinte ich auch nicht, von mir aus kann es jeder haben, je mehr deste besser. Ich hab nur die Befürchtung das jetzt jeder andere Peripherie auf dem Board haben will. > Bei dem RAM bin ich anderer Meinung 1 MB klingt nach viel aber wenn man > etwas spielen will mit dem board oder zB sachen zum analysieren eines > RF-Signals braucht man schon etwas RAM um die daten dort zu Puffern ... OK, man muss es ja nicht unbedingt nutzen oder bestücken.
Kai das Board wird für das Projekt entwickelt und ned für jeden der irgendeine Idee hat ! Max kommt noch ein Display connector drauf und das wars dann ! Es kommen nur OSCAR relevante sachen auf das Board!
Patrick Weinberger schrieb: > Kai das Board wird für das Projekt entwickelt und ned für jeden der > irgendeine Idee hat ! > Max kommt noch ein Display connector drauf und das wars dann ! > Es kommen nur OSCAR relevante sachen auf das Board! OK, das ist ein Wort :-)
Außer bei spenden fürs projekt würd ich mir das überlegen mit erweiterungen. Machst du oder soll ich einen neuen Thread auf machen wegen interesse an so einem Board? Patrick
Patrick Weinberger schrieb: > Kai das Board wird für das Projekt entwickelt und ned für jeden der > irgendeine Idee hat ! > Max kommt noch ein Display connector drauf und das wars dann ! > Es kommen nur OSCAR relevante sachen auf das Board! FULL ACK! aber, es heißt OSAR....OSCARs gibts schon genug im Netz ;)
Patrick Weinberger schrieb: > Machst du oder soll ich einen neuen Thread auf machen wegen interesse an > so einem Board? Wenn Du willst mach Du ruhig. Ich kann das ganze dann nachher gerne Layouten wenn es nicht gerade jmd. anders gerne machen will.
Ich würde vorschlagen, erst fertig zu layouten und dann zu fragen, wer eins haben will.
Schon zuspät rezz ggg Außerdem wenn noch jemand eine Idee hat was noch abgeht kann mans noch immer anpassen.
Kai G. schrieb: > Aufgeben trennen geht doch mit getrennten Controllern fast noch > besser?!? Das war ja der Sinn meiner Aussage. Das Mainboard ist lediglich Busverbinder und zentraler Koordinator. Den Rest erledigen die peripheren Module selbst. Beispiel: Alter Opel -> Kleiner ATmega8 wertet das Tacho-Signal aus und übersetzt die Widerstandskette der Lenkradfernbedienung. Er sendet dem Zentral-Controller: [TACHO][50kmh]...[LFB][LEFT][PRESS]... Damit kann ich nix anfangen, da meiner für beides CAN einsetzt. Also schnappe ich mir einen Controller mit 2xCAN und filtere passiv die Nachrichten für Tacho aus dem BodyControl und für die LFB aus dem MediaBus. Zum Zentral-Controller sende ich aber exakt das selbe wie oben. > Also wer sich ein "teuren" 2. Tuner ins Radio baut wird ihn nicht nur > als einfachen RDS-Backgroundtuner einsetzen. In fast allen Radios mit > mehr als einem Tuner sind verschiedene Empfangsverbesserungskonzepte zu > finden: > space diversity (2 Antennen) oder Frequency diversity (1 Antenne). Teuer ist relativ, wenn es dafür einfach und zuverlässig bleibt. An Fq Diversity hatte ich nicht gedacht, der 2. Tuner war mir nur als Backgrouund RDS und unabhängiger TMC Empfänger bekannt. Letzteres macht ja auch Sinn, wenn man gerne lokale Radios ohne TMC hört. Volle TMC Unterstützung macht aber wieder nur Sinn, wenn man auch ein Navi mit einbaut. Das wiederum wird mit kommerziellem Material nicht einfach, auch wenn die Navi-Rechner als Modul zu haben sind und nur per Serieller mit den Daten von einem Speichermedium gefüttert werden müssten. > Wie willst Du Tür offen oder Schlüssel in Stellung 1 detektieren? Über > CAN bus messages? Definitiv ja. Ohne CAN kann man kein vorhandenes Display übernehmen und keine vorhandene Lenkradfernbedienung mit benutzen. Dieses Unterfangen wäre, da Mediabus, sogar noch Bastlerisch hin zu bekommen. Für Navi wären aber auch Beschleunigung, Lenkradstellung und Geschwindigkeitsdaten interessant, die oft aber auf dem BodyControl und nicht dem MediaBus liegen. Den BodyControl sollte aber nur jemand anfassen, der sehr genau weiß, was er da tut. Die Garantie wäre in jedem Falle weg. Neuere Autos haben aber nicht nur eine geschaltete 12V, sondern mehrere. Eine davon schaltet erst nach einigen Minuten ab, wenn das Fahrzeug abgestellt und abgeschlossen wurde. Sie ist aber schon beim Aufschließen wieder da. Harald L. schrieb: > In weiten Bereichen stimm ich dir zu! > Ob wir auf dem Mainboard tatsächlich Linux brauchen, wage ich zu > bezweifeln, da es sich dabei aus logischer Sicht "nur" um ein > Peripheriegerät handelt. Dann wäre ein SAM7 sicherlich stark genug, denn er müsste nur die Nachrichten zwischen den Modulen vermitteln. Aber kleine schlanke Systeme wir Nut/OS laufen auch auf ARM9 und AVR32, STM32 ist in Vorbereitung ebenso einige LPCxxx. > du kennst unser Wiki dazu? > http://osar.it-livetalk.de Sicherlich. Bin für meine Entwicklung in diesem Bereich noch nicht mit allem Einverstanden, aber ich habe auch andere Optionen. So habe ich ein paar echte PKW DVD-Videolaufwerke, die Video/WMA/WMV/MP3... selbst abfertigen und nur noch einen Audio-DAC benötigen und für die LCDs in den Kopfstützen ein paar Video-Signal-Booster. Ich denke dass man solche Laufwerke nicht einfach kaufen kann, aber es bestünde eventuell die Option einer Sammelbestellung. Und schon wieder das Problem: Das DVD ist ein I2C Master und im Flash ist noch genug Platz um auch ein paar Tuner und andere Peripherie zu steuern. Aber der Code ist eben nicht open Source, noch nicht einmal die CPU-Spezifikationen sind es. Aber wenn jemand für einen ESS Vibratto-S Video-CoDec eine komplette OpenSource Toolchain hat, dann frage ich nach, was die fertigen Drives kosten. Oder, wenn Interesse besteht, es gibt die DVDs auch ohne Video-CoDec als reine IDE Laufwerke. Sicherlich mach das Brennen von MP3s keinen Sinn, wenn man SD-Card oder USB-Stick vorsieht, aber wer will schon immer seine DVDs auf einen Stick kopieren? Kai G. schrieb: > Mit AVR32 hab ich noch keine Erfahrung. Kann jemand mal was dazu > schreiben? Was braucht man zum programmieren/Debuggen? Gibts GCC > support? Vollständige Toolchains und Build-Support-Packages. Wer will kann darauf Linux fahren, das System basiert auf Buildroot. Wer es lieber klein haben will, also ohne zusätzliches Flash, der nutzt Nut/OS. > Wie "gut" sind die Teile? > Lässt sich damit MP3 mit genügend reserven für andere Dinge dekodieren? > Gibts eine gute Bezugsquelle? Bei mir läuft ein solches System perfekt. Allerdings unter Linux. Vorteil wäre, dass man für weit unter 100€ auch Plugins bekommt, also kleinste Boards, die bereits alles Nötige wie Flash, RAM, Schnittstellen drauf haben und per fisseliger kleiner Stecker auf ein anderes Board gesteckt werden. Das hat den Vorteil, dass man nicht selber solche Sachen auflöten muss. Die Audio/Video-Peripherie ist ja in der Regel deutlich gröber vom Gehäuse und Pinning her. Als Beispiel kann man sich das IC-Nova ADB1000 Board hier im Shop mal ansehen. > Kündigt Atmel die AVR32's auch so gerne & oft ab wie seine 8 bit AVRs?? Nein, sie fahren diese Chips als harte und wettbewerbsfähige Konkurrenz zu ARM. Bislang sind sie da gefühlt vorne, aber das kann sich heut zu Tage ständig ändern. iMX ist schließlich auch nicht zu verachten. Das IC-Nova Board spielt hier jedenfalls alles gängige an Audio/Video von einer SD-Card auf seinem 1/4VGA LCD ab. Harald L. schrieb #1732615 > Falsche Reihenfolge! > * IDv2 lesen > ** falls nicht vorhanden -> IDv1 > PLAY > oder Mutithreaded....erst Play....parallel ID einlesen Auch falsch, man muss zuerst mal den Header vom ID3V2 einlesen, wenn er existiert und heraus finden, wo man dessen Ende findet. Zwar sollte ein guter MP3-Decoder den header ohne Störgeräusche schlucken, bis er auf Audio-Daten trifft, aber wenn der Header wegen Songtexten und Covern groß ist, dann können die Sekunden ins Land gehen, bis er an spielbares Material heran gekommen ist. Ach, und macht Euch keine falschen Vorstellung von ich werte mal ein paar Bytes aus und habe dann ID3Vx Infos. Nehmt 3 Programme zu Encoden oder Taggen und schon habt Ihr 18 verschiedene Möglichkeiten, wie was wo steht. Abgesehen davon sind einige ID3V1 Daten nie wirklich fest geschrieben worden, bzw. ihr reger Missbrauch ist Quasi-Standard. Kai G. hat dazu in Beitrag "Re: Open source Autoradio" Schon was geschrieben, ich setze nur noch einen drauf. Es ist noch schlimmer :) > Geht doch: > http://www.cartft.com/catalog/il/1228 > Und nebenbei hätte man sogar das Problem des Gehäuses gelöst. ;-) Autsch, das ist wohl ein billig Clone von dem Billig-Teil, das hier auf meinem Schreibtisch als Zweit-TV her hält. Meines hat aber besagtes DVD drin. Ich kann nur sagen, dass das Quitschen des Monitor-Schlittens, egal, ob ausgefahren oder ein geklappt, irgendwann echt nervig ist. Gruß, Ulrich
Ich zitier jetzt mal ned. 1.) Mainboard kann nur einfache Audio-sachen und übernimmt das Multiplexing der Audiostreams und bei der Grundversion die MP3 Wiedergabe. Dazu wird ein Renesas SH7264 verwendet. 2.) wer nutzt heut noch DVDs ? Ich kann unter dem Autofahren sowieso ned DVD-Schauen und das Videocodier erfordert schon sowas wie das neue Beagleboard Mx. Wenn man will kann man ja so ein Beagleboard als erweiterung zu einem Kompletten PC verwenden. 3.) Auslesen von Daten aus dem Auto ist immer so eine Sache und einfach mal optional. Der nächste will dann noch ne Plutonium Batterie ? Patrick
@Patrick ich hab deinem Entwickerboard eine Seite im Wiki gewidmet. Wär gut, wenn du was schreiben würdest. http://osar.it-livetalk.de/index.php/SH7264_Entwicklungsboard Harry
> Auch falsch, man muss zuerst mal den Header vom ID3V2 einlesen, wenn er > existiert und heraus finden, wo man dessen Ende findet. Zwar sollte ein > guter MP3-Decoder den header ohne Störgeräusche schlucken, bis er auf Oh ja und wer das einmal praxistauglich programmiert hat hat graue Haare oder lichte stellen am Kopf. Unsynchronization byte, verschiedene Zeichenkodierungen, ...
Ich habe hier mal zwei groessere Photos gemacht die zeigen wie das Board aus Japan so aussieht: http://www.criseis.ruhr.de/SuperH/Japan_oben.jpg http://www.criseis.ruhr.de/SuperH/Japan_unten.jpg Und hier der Schaltplan: http://www.criseis.ruhr.de/SuperH/SH2A_Schaltplan.pdf Wie man sieht enthaelt das Board selbst auch nur das noetigste. Klar, sollte ja auch eine moeglichst guenstige Beigabe sein. Ich habe aber auch leichte Zweifel ob man so ein Board selber zuhause herstellen koennte. Ich schrecke normalerweise auch vor wenig zurueck, aber die Leiterbahnen sind doch schon sehr duenn. Da man bei FPGAs vor einer sehr aehnlichen Problematik steht habe ich mir dort vor einiger Zeit mal dies hier gemacht: http://www.criseis.ruhr.de/SuperH/fpga_oben.jpg http://www.criseis.ruhr.de/SuperH/fpga_unten.jpg Das ist noch sehr gut beherschbar. Allerdings hat der FPGA auch nur 100Pins. Der SH7262 hat dagegen 176! Mit anderen Worten das Board wuerde vermutlich so in der Gegend von 160x160mm landen. Das ist fuer ein Testboard schon recht heftig! Die schoenste Alternative waere natuerlich das Japanboard zu testzwecken auf ein anderes Board aufzustecken wo man erstmal nur ein paar Sachen zum spielen hat, also AD-DA-Wandler, I2C-Anschluss, SD-Karte. Das waer natuerlich keine grosse Sache. Problem dabei ist bloss wo wollen ihr so ein Board bei uns herbekommen. Ich weiss nicht ob man von uns aus in Japan bei Amazon bestellen kann. Vielleicht will das mal einer ausprobieren? Und die letzte Moeglichkeit waere wohl ein Board zu machen das viele Pins unbenutzt laesst und sozusagen Prozessor, AD-DA-Wandler, I2C-anschluss und SD-Karte enthaelt. Nachteilig daran, der Uebergang von so einem Board zum entgueltigen Radioboard waere irgendwie fliessend. Jeder wird mit nochetwas ankommen das auch noch unbedingt drauf sollte und ploetzlich ist es wieder ein ganzes Radio. :-) Ich wuerde z.B noch einen Anschluss fuer das GrafikLCD und eine RS232-Schnittstelle ganz nett finden. Als jemand der schon ein Board aus Japan rumliegen hat waere ich nauerlich geneigt Ansatz zwei zu bevorzugen, andererseits koennte ich auch einiges an Loesung drei gut finden. Es ist naemlich schon nett wenn man so eine komplexe sach erstmal im kleinen ausprobieren kann. Wie man sieht sind auf dem Board z.B eine ganze Menge Kondensatoren drauf, die sind da nicht weil Renesas davon zuviele hat. :-) Externes Ram auf so einem Board halte ich fuer Quatsch. Einer der entscheidenden Punkte welche die Eleganz und Schoenheit dieser CPU ausmacht ist ja gerade das man extern so wenig braucht. Man kauft sich auch keinen Porsche und verlaengert den falls man mal sechs Kinder haben sollte. > Einerseits sind wir schon bei Bauteil-"größen" angekommen > die mich erschaudern lassen und zum Anderen bin ich mir nicht > sicher ob für sowas meine Programmierkenntnise ausreichen. Der Pinabstand von 0.5mm ist sich nichts fuer den ersten Loetversuch im Leben. Anderseits loete ich auch gelegentlich Prototypen mit solchen ICs. Es ist also durchaus zu schaffen und notfalls wird sich schon jemand finden der das uebernimmt. Zum programmieren. Es gibt kein Bascom und Assembler ist auch bis auf paar Sonderfaelle sicher nicht die beste Loesung. .-) Wer aber C kann, fuer der wird sich schnell zuhause fuehlen. Die Oberflaeche von Renesas (HEW) ist relativ maechtig. Aber mit etwas hilfe und nachfragen sollte das zu schaffen sein. Aufgrund der Leistungsfaehigkeit stehen viele Sachen einfach so zur Verfuegung wo man sich bei kleinen Controllern immer strecken muss. (z.B printf wird einfach so gehen) Ich werde sobald der Bedarf da ist, auch eine ausfuehrliche Anleitung fuer die Installation des Compilers schreiben. Die in der CPU integrierte Hardware ist sicher Leistungsfaehig und auch das Datenblatt hat nicht ohne Grund mehr als 2000Seiten. Soweit ich das aber nach nur lesen sagen kann ist es weniger komplex als eine R32 oder M16. Es gibt auch von Renesas eine ganze Menge an Applikationen mit Beispielsource. Man kann die sie alle bei Renesas runterladen. Eventuell koennte man es auch irgendwo alles am Stueck zur Verfuegung stellen. Das ganze hat derzeit eine Groesse von 250MB. (Also Compiler und einfach alles) Falls ich nicht andauernd einschlafe (Jetlag, gaehn) werde ich am Wochenende mal 1-2 Testsachen programmieren um mit der CPU warm zu werden. Eine Sache wo wir sicher alle noch dazulernen werden ist die Zusammenarbeit bei so einem grossen Project wo im laufenden Betrieb ja staendig Daten durch das System rauschen muessen. Das ist kein Mega8 wo es keiner merkt wenn das LCD mal kurz nicht aktualisiert wird weil der DS1820 mal wieder primitiv gepollt wird. :-D Wenn es irgendwo knallt dann da! Aber zumindest fuer mich macht das auch irgendwo den Reiz aus. Olaf
> Unsynchronization byte, verschiedene > Zeichenkodierungen, ... Eine japanische Freundin die einmal ihre MP3s auf euren Player kopiert und ihr werdet sehen wo die Faehigkeiten der Programmierer lagen oder eben auch nicht. ;-D
Olaf Kaluza schrieb: > Die Oberflaeche von Renesas (HEW) ist relativ maechtig. Aber mit etwas > hilfe und nachfragen sollte das zu schaffen sein. Aufgrund der > Leistungsfaehigkeit stehen viele Sachen einfach so zur Verfuegung wo man > sich bei kleinen Controllern immer strecken muss. (z.B printf wird > einfach so gehen) > > Ich werde sobald der Bedarf da ist, auch eine ausfuehrliche Anleitung > fuer die Installation des Compilers schreiben. wie siehts mit GCC & Co aus? ..falls nicht - gibt es Compiler die unter Linux laufen? 1.: ich habe gar keinen Windoof-Rechner 2.: ich möchte ungern auf mein geliebtes Eclipse verzichten. Harry
Olaf Kaluza schrieb: > Eine japanische Freundin die einmal ihre MP3s auf euren Player kopiert > und ihr werdet sehen wo die Faehigkeiten der Programmierer lagen oder > eben auch nicht. ;-D hat sich da gerade freiwillig gemeldet? :-))))
Harald L. schrieb: > wie siehts mit GCC & Co aus? > ..falls nicht - gibt es Compiler die unter Linux laufen? Frage hat sich erledigt...ist ja alles vorhanden... Harry
Wie du vermutlich gerade gesehen hast gibt es grundsaetzlich einen gcc fuer die SuperH. Er soll sich wohl auch in die Oberflaeche von Renesas integrieren lassen. Wie das geht, keine Ahnung. Habe ich auch noch nie gemacht. Das scheint mir unter Windows normalweise auch wenig sinnvoll weil die Begrenzungen von Renesas 64k bei R8C/M16C und 256k fuer SuperH releativ grosszuegig gewaehlt sind. Was ich schonmal gemacht habe ist einen gcc unter Linux fuer R8C/M16C uebersetzt und genutzt. Das ist eigentlich nicht so problematich. Wenn die CPU vom gcc bereits unterstuetzt wird dann sollte das zu schaffen sein. Eine Frage die du aber noch klaeren solltest. Wie bekommst du deinen Code in den SuperH! Die Windowsumgebung verwendet dafuer den im HEW integrierten Debugger. Das Board benoetig keinen speziellen Treiber sondern nur eine inf-Datei und wird danach unter Windows als RS232-Port erkannt. Ich hab mein Board gerade mal kurz angesteckt: usb 2-1.4: new high speed USB device using ehci_hcd and address 6 usb 2-1.4: New USB device found, idVendor=045b, idProduct=0020 usb 2-1.4: New USB device strings: Mfr=0, Product=0, SerialNumber=3 usb 2-1.4: SerialNumber: 000000000000 usb 2-1.4: configuration #1 chosen from 1 choice klogd: cdc_acm 2-1.4:1.0: ttyACM0: USB ACM device klogd: usbcore: registered new interface driver cdc_acm klogd: cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters In wieweit Linux dann damit reden kann? Keine Ahnung. Die wirklich interessante Frage ist aber, gibt es fuer den SuperH unter Linux eine gdb-anbindung? Eine der Sachen welche die Entwicklungsumgebung von Renesas so interessant machen ist der leistungsfaehige Debugger. Olaf
Olaf Kaluza schrieb: > Wie du vermutlich gerade gesehen hast gibt es grundsaetzlich > einen gcc fuer die SuperH. Er soll sich wohl auch in die > Oberflaeche von Renesas integrieren lassen. > jepp...habs gesehn..Ver. 3.04 > > Was ich schonmal gemacht habe ist einen gcc unter Linux fuer R8C/M16C > uebersetzt und genutzt. Das ist eigentlich nicht so problematich. Wenn > die CPU vom gcc bereits unterstuetzt wird dann sollte das zu schaffen > sein. > Toolchain compilieren ist kein Problem...hab ich auch schon mehrfach gemacht. > Eine Frage die du aber noch klaeren solltest. Wie bekommst du deinen > Code in den SuperH! Die Windowsumgebung verwendet dafuer den im HEW > integrierten Debugger. Das Board benoetig keinen speziellen Treiber > sondern nur eine inf-Datei und wird danach unter Windows als RS232-Port > erkannt. > Also der RS232-Port taucht dann auch unter Linux auf (ganz ohne .inf-File) Ich werd mal recherchieren, ob es da schon etwas für Linux gibt. Im schlimmsten Fall könnte man mal nachschauen, ob es unter Win ein Kommandozeilen-Tool gibt, um den Code in den Chip zu schreiben...der könnte dann per Wine laufen....sollte auch das misslingen geht es sicher mit einem VirtualBox. > Ich hab mein Board gerade mal kurz angesteckt: > > usb 2-1.4: new high speed USB device using ehci_hcd and address 6 > usb 2-1.4: New USB device found, idVendor=045b, idProduct=0020 > usb 2-1.4: New USB device strings: Mfr=0, Product=0, SerialNumber=3 > usb 2-1.4: SerialNumber: 000000000000 > usb 2-1.4: configuration #1 chosen from 1 choice > klogd: cdc_acm 2-1.4:1.0: ttyACM0: USB ACM device > klogd: usbcore: registered new interface driver cdc_acm > klogd: cdc_acm: v0.26:USB Abstract Control Model driver for USB modems > and ISDN adapters > > In wieweit Linux dann damit reden kann? Keine Ahnung. > Wie gesagt: die Schnittstelle ist das geringste Problem. Diese devices tauchen einfach als /dev/ttyUSBx auf. > Die wirklich interessante Frage ist aber, gibt es fuer den SuperH unter > Linux eine gdb-anbindung? Eine der Sachen welche die > Entwicklungsumgebung von Renesas so interessant machen ist der > leistungsfaehige Debugger. Ok...das muss ich recherchieren....notfalls eben doch im VirtualBox Harry
Olaf Kaluza schrieb: > klogd: cdc_acm 2-1.4:1.0: ttyACM0: USB ACM device > klogd: usbcore: registered new interface driver cdc_acm > klogd: cdc_acm: v0.26:USB Abstract Control Model driver for USB modems > and ISDN adapters > > In wieweit Linux dann damit reden kann? Keine Ahnung. Du hast gerade eine weitere 'virtuelle' COM Schnittstelle gewonnen, sprich Du kannst jetzt per Terminal mit diesem USB-Port reden. Das Stichwort ist CDC_ACM. Schau mal nach, es sollte sich unter den vorhandenen ttysX ein weiterer ansprechbarer finden. Gruß, Ulrich
Aber mein Kommentar von oben ist missverstanden worden. Die Auslegung, dass das Mainboard den kompletten Audio-Teil abfrühstückt wiederspricht meinem Vorschlag für die Unterstützung von (m)einem DVD ja nicht. Das DVD läuft mit allen Features autark, das Mainboard muss es nur per I2C mit ein paar Kommandos versorgen. Ein Beagleboard ist absolut nicht notwendig. Und Du denkst anders über DVD im Auto, wenn Du mit Kindern längere Fahrten machen möchtest. Aber wie gesagt, der sich abzeichnende Ansatz für das System lässt diese Erweiterung ja immer noch zu. Bin mal gespannt, wie sich das hier entwickelt, auch wenn meine Ideen ursprünglich etwas anders aussahen. Die Mischung wird es bringen. Da ich meine Mittelkonsole nicht zerlegen oder unnötig auffällig gestalten möchte, habe ich beim Gehäuse eh einen anderen Ansatz vor. Ich hoffe nämlich für wenig Geld an ein defektes Radio/CD oder Radio/Navi zu kommen, dieses komplett von seiner Elektronik zu befreien und meine eigene dort einzusetzen. Über Geschmack kann man nicht streiten, aber ich finde es eben schicker, wenn man die Extras nicht gleich sieht. Gruß, Ulrich
Ulrich vielleicht an einem Prototypen Board für den Renesas SH 7264 interessiert ?
Bin mir nicht ganz sicher... 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. Andererseits kann man für CortexM3, ARM7/9/11 und AVR32 den OpenOCD, Eclipse und (AVR)GCC verwenden, die Windowser nutzen eben Yagarto. Der OpenOCD-USB Adapter kostet nur ein paar Kröten hier im Shop. Ich weiß auch noch nicht, ob ich direkt mit einsteigen kann, da ich noch einige andere Projekte hier liegen habe. Es wäre dann unfair ein noch freies DevKit einem anderen weg zu nehmen, der gerne sofort mit machen möchte. Wenn der Preis aber so niedrig ist, wie angedeutet, dann nehme ich wahrscheinlich eines, wenn genug da sind. Außerdem habe ich für das oben angesprochene DVD den kompletten Quellcode und das DevKit... Ich hatte nur bislang keine Lust mich wieder in die 1,5Mio Zeilen Quellcode rein zu arbeiten. Aber ich stehe gerne für den ein oder anderen Rat zur Verfügung. Außerdem scheint der Tuner eine echte Idee zu sein, so dass ich dafür möglicherweise mal in den nächsten Wochen ein Layout mache. Das kommt dann an das EIR und die Treiber ins Nut/OS, so dass Ihr Euch da gleich wieder bedienen könnt. Der Tuner soll zusammen mit dem EIR und einem DVD in das Gehäuse eines Cambridge Soundworks Radio. Die Projekte überschneiden sich also und wir haben alle was davon. Hmm... Muss noch Nut/OS auf LPC und STM32 portieren, warum nicht auch auf den Renesas... Gruß, Ulrich
Jungs hat wer von euch erfahrung mit LineIn und Out. Besonders welche beschaltung man zwischen CODEC und verstärker braucht usw ? MFG
Olaf Kaluza schrieb: > Ich habe hier mal zwei groessere Photos gemacht die zeigen > wie das Board aus Japan so aussieht: > http://www.criseis.ruhr.de/SuperH/Japan_oben.jpg > http://www.criseis.ruhr.de/SuperH/Japan_unten.jpg Sieht gut aus!! Würd es am liebsten sofort ausprobieren ;-) > http://www.criseis.ruhr.de/SuperH/SH2A_Schaltplan.pdf Auch sehr übersichtlich. 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? > Ich habe aber auch leichte Zweifel ob man so ein Board selber zuhause > herstellen koennte. Ich schrecke normalerweise auch vor wenig zurueck, > aber die Leiterbahnen sind doch schon sehr duenn. Wir können sie auch ätzen lassen. Wenn es ein Board mit 1 Steckerleiste an jeder seite wird, ist das Layout recht übersichtlich und man braucht auch keine 75µ Leiterbahnen, Microvias und so :-) > Das ist noch sehr gut beherschbar. Allerdings hat der FPGA auch nur > 100Pins. Der SH7262 hat dagegen 176! Mit anderen Worten das Board wuerde > vermutlich so in der Gegend von 160x160mm landen. Das ist fuer ein > Testboard schon recht heftig! Ich dachte eher an jeder Seite doppelreihige Steckerleisten zu machen. Dann wird es klein und kompakt und ist trotzdem noch auf Lochrasterplatinen benutzbar. Das Layout an sich ist einfach und fast komplett einseitig zu machen. Auf der Bottom-Seite kann man den anderen Kram wie C's und so setzen. > Problem dabei ist bloss wo wollen ihr so > ein Board bei uns herbekommen. Ich weiss nicht ob man von uns aus in > Japan bei Amazon bestellen kann. Vielleicht will das mal einer > ausprobieren? Ich würd es ja gerne probieren, aber bei Deinem link versteh ich nur ähh... Japanisch. Man kann zwar auf Englisch schalten aber einen klick weiter springt er wieder um auf Japanisch. Sieht für mich aber so aus, als würde es nicht direkt von Amazon angeboten, sondern von anderen Händlern bei Amazon. > Nachteilig daran, der Uebergang von > so einem Board zum entgueltigen Radioboard waere irgendwie fliessend. > Jeder wird mit nochetwas ankommen das auch noch unbedingt drauf sollte > und ploetzlich ist es wieder ein ganzes Radio. :-) Lustig, genau diesen Satz wollte ich vorhin auch schreiben. > Als jemand der schon ein Board aus Japan rumliegen hat waere ich > nauerlich geneigt Ansatz zwei zu bevorzugen, andererseits koennte ich > auch einiges an Loesung drei gut finden. Es ist naemlich schon nett wenn > man so eine komplexe sach erstmal im kleinen ausprobieren kann. Wie man > sieht sind auf dem Board z.B eine ganze Menge Kondensatoren drauf, die > sind da nicht weil Renesas davon zuviele hat. :-) Ü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?
Ulrich P. schrieb: > 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. naja, 1MB Ram, davon sagen wir mal 512KB fürs Programm, macht 512KB RAM der überbleibt. Der Unterschied zu 64-128K ist doch immens!!
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.