Hallo! Ich wollte mal vorsichtig fragen ob es Leute gäbe die prinzipiell Interesse daran hätten an einem noch nicht existierenden Open source Projekt teilzunehmen bei dem es darum geht ein komplettes Autoradio zu entwickeln. Ich habe soetwas schonmal auf professioneller Ebene gemacht (Komplette Software und Teile der Hardware) und es hatte mir verdammt viel Spaß gemacht. Allerdings hatte ich nicht die Möglichkeiten das Radio genau so zu implementieren wie ich es gerne gehabt hätte. Was mir vorschwebt: - Optik: Das Radio sollte nicht wie ein "Ufo" aussehen - Größe: Single DIN - Evtl. eine Gehäusevariante für ein Stand alone radio (AKA Küchen/Kofferradio) - Es soll möglich sein eine komplette MP3 Sammlung inkl. Cover zu speichern - Farbdisplay (soll auch MP3 cover anzeigen können) - 2*Rotary button bedienung (Ähnlich Becker Grandprix) + ein paar feste Funktionstasten - Radio features: * FM only (Mittelwelle/Langewelle und co ist denk ich heutzutage nicht mehr echt interessant) * Frequency diversity zur Empfangsverbesserung mit einer Antenne wäre schön * evtl. DRM (?) * RDS, inkl. Follow me, Radio text (+), TA, EON * Evtl. TIM (Aufzeichnung von Verkehrsnachrichten wenn das Radio eigentlich aus ist und wiedergabe wenn das Auto das nächste mal gestartet wird). * search tuning up/down * automatische Suche nach den aktuell stärksten Sendern (inkl. Aussortierung von dubletten auf Basis von RDS Infos) * Der Empfang sollte wirklich sehr gut sein. Gutes Groß- und Kleinsignalverhalten. * Abschaltbare Phantomspeisung (wichtig für "moderne" Autos, sonst ist der Empfang sehr besch§$%) * nur wenn Platz im Display ist: Senderlogogs sollten angezeigt werden - "MP3"-funktion: * MP3 Wiedergabe (alle Bitraten/VBR/ID3V1 und ID3V2 support) * MP3s, evtl. andere codecs (OGG, FLAC, ... ?) * Einfache und schnelle (!) Navigation durch große MP3 Sammlungen (Evtl. Hierachie Artist/Album/Track) * Datenspeicher: z.B. SDHC Karten. Es wäre auch denkbar mehrere Karten gleichzeitig zu unterstützen um den Speicher zu erweitern. Alternativ: Ein USB OTG Host mit Mass storage support. - Audio Optionen: * 4 Kanal Verstärker (Evtl. Class-D) * Fade / Balance * Einfacher Equalizer - Evtl. Bluetooth Hands free option - Design Grundsätze: * Funktionen sollten leicht erreichbar sein (keine 3 fach Shiftfunktionen auf Buttons, etc...) * Die Reaktion auf Benutzerfunktionen sollten schnell erfolgen. Wenn eine Funktion länger dauert sollte sie vor Beendigung schon eine Reaktion auf dem Display zeigen. - Sehr schön wäre auch die Möglichkeit um den CAN Bus von Autos mit einzubinden um Sonderfunktionen wie z.B. PDC auf dem Radio anzuzeigen. Sowas ist Herstellerspezifisch, man kann es jedoch in der Hardware vorsehen und in Software auswählbar gestalten. - Evtl. Optionen um andere selbst entwickelte Boards einfach in die Hard- und Softwareumgebung einzubinden, z.B. Amateurfunk transceiver, Datenlogger, ... - OBD2 Diagnose Option / Anzeigen oder Loggen von Sensordaten? 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. Da ich sowas ähnliches schon gemacht habe weiß ich sicher das solch ein Projekt definitiv auch mit wenig Leuten (2) machbar ist, allerdings würde ich sowas gerne mit mehreren Leuten zusammen machen. So kommt man sicher auch noch auf andere gute Ideen und Sachen sind einfacher zu realisieren weil man einfach nicht auf allen Gebieten ein Experte ist. Ich würde übrigens auch gerne wirklich alles Quelloffen machen, inkl. der Hardware. Viele Grüße, Kai
Ein Kopfhörerausgang fehlt noch und ein Eingang für Kassettenrekorder! Den Tuner willst Du auch bauen oder hast Du ein fertiges Modul?
Tropenhitze schrieb: > Ein Kopfhörerausgang fehlt noch und ein Eingang für Kassettenrekorder! > > Den Tuner willst Du auch bauen oder hast Du ein fertiges Modul? Kopfhörer im Auto ist verboten - jedenfalls für den Fahrer. Klar, Anschluss für Kasettenrecorder, Plattenspieler mit RIAA Entzerrung und ein Laufwerk für Original Edison-Wachswalzen. ;) Mal im Ernst, weiss jemand wie lang es analoges FM-Radio noch gibt ?
Tropenhitze schrieb: > Ein Kopfhörerausgang fehlt noch und ein Eingang für Kassettenrekorder! Dual MP3 playback wäre wirklich interessant. Einer zum Hörbuch hören über Kopfhörer für den Nachwuchs und einer zum Musik hören über Lautsprecher. Line-in fehlt auch noch auf der Liste. > Den Tuner willst Du auch bauen oder hast Du ein fertiges Modul? Fertige Chipsets nehmen und an Herstellervorbild halten was Layout und Bauteile betrifft. Da kenn ich mich zufällig mit aus :-)
Ohforf Sake schrieb: > Mal im Ernst, weiss jemand wie lang es analoges FM-Radio noch gibt ? Warum nicht Modulbauweise? Kommunikation per I²C und Sound per I²S. Was m.M. schön wäre: Doppeltuner Einer ist fürs aktive Hören zuständig, der andere scannt das Band um aktuell empfangbare Sender zu ermitteln. Sendertasten sind IMO obsolet. Ähnlich wie bei BMW: Im Display sind nur Sendernamen zu lesen, evtl. als "Cloud" (je besser der Empfang, desto größer) Was m.M. auch wichtig wäre: kontrastreiches Display und Lichtsensor. Was hilft einem das farbenfrohste Display, wenn man es bei Tag nicht lesen und man bei Nacht davon geblendet wird.
> Kopfhörer im Auto ist verboten - jedenfalls für den Fahrer. > Klar, Anschluss für Kasettenrecorder, Plattenspieler mit RIAA Entzerrung > und ein Laufwerk für Original Edison-Wachswalzen. ;) :-) Es gab mal fürs Auto Abspielgeräte für Singles die nicht unähnlich der CD Player von heute waren. > Mal im Ernst, weiss jemand wie lang es analoges FM-Radio noch gibt ? Da in Deutschland kaum jemand die einzige momentan valide Alternative (DAB[+]) "behört", wird es wohl ähnlich laufen wie bei DVB-T. DRM ist noch immer eher im Testbetrieb und qualitativ kein echter ersatz für FM, DAB(+) hat ein recht schlechtes Angebot (sowohl content als auch Empfänger) und viel anderes neueres zu FM gibt es hier nicht. Ich prophezeie FM noch ein langes leben.
Wirklich ne coole Idee! Man könnte ja ein Display wie im ipod touch verwenden. Ähm aber hey ich will ja nix miesmachen hier aber wie issn des mitti ABE bei so selbstbastelkram? :-/
Chris R. schrieb: > Ohforf Sake schrieb: >> Mal im Ernst, weiss jemand wie lang es analoges FM-Radio noch gibt ? > > Warum nicht Modulbauweise? > > Kommunikation per I²C und Sound per I²S. Ich wäre für FM fest einbauen und sonst eine Möglichkeit für Alternative analoge und digitale (I²S) Eingänge. > Was m.M. schön wäre: Doppeltuner > Einer ist fürs aktive Hören zuständig, der andere scannt das Band um > aktuell empfangbare Sender zu ermitteln. Sowas hat z.B. Becker (Living band oder so ähnlich heißt das). Keine schlechte Funktion. Um nur zu schauen wie gut Sender auf anderen Frequenzen empfangbar sind (RDS-AF) braucht man übrigens keinen 2. Tuner. > Sendertasten sind IMO obsolet. Ähnlich wie bei BMW: Im Display sind nur > Sendernamen zu lesen, evtl. als "Cloud" (je besser der Empfang, desto > größer) Stimmt, man kann durch Sender auch wie durch eine MP3 Sammlung navigieren. Man muss auch darauf achten das man keine Patente verletzt. > Was m.M. auch wichtig wäre: kontrastreiches Display und Lichtsensor. Was > hilft einem das farbenfrohste Display, wenn man es bei Tag nicht lesen > und man bei Nacht davon geblendet wird. Ja, auf jeden fall. Zur not würde ich auch ein S/W Display vorziehen. Aber bitte kein Oled. Die sind sehr schön und Kontraststark aber brennen ein und sind nach ein paar wochen Dauerbetrieb nur noch halb so hell.
> Ähm aber hey ich will ja nix miesmachen hier aber wie issn des mitti ABE > bei so selbstbastelkram? > :-/ Kann mir nicht vorstellen das ein Autoradio eine ABE braucht, lass mich aber gerne eines besseren belehren. Werde mich mal schlau machen.
Kai G. schrieb: > Was mir vorschwebt: > - Größe: Single DIN Heutzutage ist doch Doppel-DIN angesagt > - Farbdisplay (soll auch MP3 cover anzeigen können) mit Touchfunktion
G. L. schrieb: >> Was mir vorschwebt: >> - Größe: Single DIN > Heutzutage ist doch Doppel-DIN angesagt Bei Doppel din ist die Blende meist Herstellerspezifisch. Single DIN passt überall. Für Single DIN gibt es von fast jedem Hersteller Blendensätze. >> - Farbdisplay (soll auch MP3 cover anzeigen können) > mit Touchfunktion Ist Touch im Auto nicht unpraktisch weil man kein taktiles Feedback hat? Außerdem wäre das Display ständig mit Fettfingern begrabbelt und dann gerade bei Sonne schlecht ablesbar (wenn ich so an mein Telefon/Navi denke). Das Radio wird kein Navi oder ähnliches beinhalten für die man ein großes Display mit vielen Menüpunkten bräuchte.
Integrierter Speicher (SSD so ab 30GB) und WLAN zur automatischen Synchronisierung mit der heimischen Musiksammlung, sobald sich das Auto in Reichweite (m)eines Access-Points befindet.
Tobi schrieb: > Integrierter Speicher (SSD so ab 30GB) Ich verstehe unter SSD eine Pseudo-Festplatte mit IDE/SATA oder PCIe Anschluss (letzteres ist irrsinnig schnell und teuer). All das lässt sicht so einfach anschliessen. SD/SDHC, am besten mehrere, ist preiswert, klein und leicht machbar.
Tobi schrieb: > Integrierter Speicher (SSD so ab 30GB) und WLAN zur automatischen > Synchronisierung mit der heimischen Musiksammlung, sobald sich das Auto > in Reichweite (m)eines Access-Points befindet. Ja, wäre sehr interessant. Ich hab noch keine Erfahrung mit WiFi in selbstbauprojekten, sprich was und ob es da was bezahlbares gibt. Ich stelle mir das Handling von den ganzen Sicherheitsprotokollen und so kompliziert vor und evtl. wäre es am einfachsten für solch einen fall ein (uC)Linux zu benutzen, was ich für ein reines Autoradio allerdings wieder für Overkill halten würde. TCP/IP an sich (direkt im uC, ohne großes Betriebssystem) wäre ja heutzutage kein Problem mehr.
Ohforf Sake schrieb: > Ich verstehe unter SSD eine Pseudo-Festplatte mit IDE/SATA oder PCIe > Anschluss (letzteres ist irrsinnig schnell und teuer). > All das lässt sicht so einfach anschliessen. > SD/SDHC, am besten mehrere, ist preiswert, klein und leicht machbar. Ja, deswegen wäre ich auch für SD(HC). Viele Controller bringen auch schon eine echte SD Schnittstelle mit sich, sodass man nicht mal das langsamere SPI bemühen müßte. Das Feature mehrere Slots zu unterstützen ist denk ich besonders interessant.
Sehr interessantes Projekt! Das Display sollte im Dunkeln wirklich dunkel sein! Ich hatte nun schon 3 Autoradios die wunderschön blau leuchteten aber im Dunkeln unerträglich sind. Bluetooth als Freisprecheinrichtung ist ein Muß, aber das wird qualitativ wirklich schwierig. Mit Fahrgeräuschunterdrückung für den Gesprächspartner und dann noch Fahrgeräuschminderung per Gegenschall im Fahrzeug. Sollte doch per DSP zu machen sein. ODB2-Bordanzeigen und und und :-) Und das alles in einem einzigen DIN-Schacht ohne das es vor Hitze zerfliesst.
Beagleboard mit Android + Touch-TFT + USB-Tuner + Amp, fertig ist der erste Prototyp.
> Beagleboard mit Android + Touch-TFT + USB-Tuner + Amp, fertig ist der > erste Prototyp. Dürfte nen Grottenempfang haben und nicht gerade sehr stabil laufen. Aber für einen Quick & Dirty Demonstrator sicher nicht schlecht ;-)
Oliver Stellebaum schrieb: > Sehr interessantes Projekt! > Das Display sollte im Dunkeln wirklich dunkel sein! Ich hatte nun schon > 3 Autoradios die wunderschön blau leuchteten aber im Dunkeln > unerträglich sind. Mit einem Lichtsensor sollte das einfach machbar sein. > Bluetooth als Freisprecheinrichtung ist ein Muß, aber das wird > qualitativ wirklich schwierig. Mit Fahrgeräuschunterdrückung für den > Gesprächspartner und dann noch Fahrgeräuschminderung per Gegenschall im > Fahrzeug. Ja, ich würde auch ungern auf eine Freisprecheinrichtung verzichten. Gegenschall ist denk ich nicht nötig, aber man kann mit ein paar einfachen Maßnahmen die viel Experimente benötigen sowas realisieren. Der große Vorteil gegenüber anderen Systemen ist, das man Signalpausen (=Sprechpausen) hat mit denen man Störgeräuche abschätzen kann und zusätzlich noch ein Referenzsignal hat das bekannt ist und mit überlagertem Störsignal über das Mikro "zurückgehört" wird. > Sollte doch per DSP zu machen sein. Ja, und ein paar Monate Entwicklung und Tests für die Software für den DSP. Ein Arm9E ist zwar kein DSP, sollte aber genug Leistung für sowas mitbringen (Arm9E hat ein paar DSP instructionen wie MAC, ...). Man kann es ja so bauen, das man Software für sowas schreiben könnte, aber prinzipiell wäre es wahrscheinlich einfacher etwas fertiges zu benutzen. > ODB2-Bordanzeigen und und und :-) > Und das alles in einem einzigen DIN-Schacht ohne das es vor Hitze > zerfliesst. Da zerfliesst nix, OBD2 und Co machen keine Hitze (ausser beim Programmierer während er die Software schreibt) ;-) Die meiste Wärme macht die Sonne.
Kai G. schrieb: > Ist Touch im Auto nicht unpraktisch weil man kein taktiles Feedback hat? Wenn das System entsprechen flott reagiert denke ich nicht - zumal für die wichtigsten Bedienpunkte ja HW-Knöpfchen vorgesehen wären. > Außerdem wäre das Display ständig mit Fettfingern begrabbelt und dann > gerade bei Sonne schlecht ablesbar (wenn ich so an mein Telefon/Navi > denke). Würde aber von Display u. Einbauposition abhängen. > Das Radio wird kein Navi oder ähnliches beinhalten für die man ein > großes Display mit vielen Menüpunkten bräuchte. Die Anpassbar-/Erweiterbarkeitkeit würde sich aber drastisch erhöhen - erst dadurch würde ein solches Gerät breiteres Interesse wecken. http://www.car-pc.info/ kennst Du?
Jop das mit dem Beagleboard is find ich ein guter Ansatz. Damit haette man eine Leistungsstarke und bereits Standardisierte Plattform an die man nurnoch einzelne Stuecke anbauen muss. Eventuell waehre aber ein igepv2 besser geeignet da das noch mehr Schnittstellen onboard hat und das gleiche kostet.
G. L. schrieb: > Wenn das System entsprechen flott reagiert denke ich nicht - zumal für > die wichtigsten Bedienpunkte ja HW-Knöpfchen vorgesehen wären. > Würde aber von Display u. Einbauposition abhängen. > Die Anpassbar-/Erweiterbarkeitkeit würde sich aber drastisch erhöhen - > erst dadurch würde ein solches Gerät breiteres Interesse wecken. > > http://www.car-pc.info/ > kennst Du? Ich finde auch das touch panel cool aussehen, so ist es ja nicht... Ich stehe solchen Touchgeschichten immer negativ gegenüber weil ich finde das sie zu schlecht durchdachten Bedienkonzepten führen. Man macht mal hier, mal da einen Button hin statt sich vernünftig Gedanken über eine einfache und intuitive Bedienung zu machen. Wir hatten mal ein Demoradio mit einem Bildschirm der Ausfuhr, ähnlich dieser DVD Player für Autos. Das hatte sogar ein taktiles Feedback, vermutlich ein Elektromagnet oder ähnliches der auf die Displayscheibe wirkte (sicher mit 20 Patenten abgesichert). Es sah unheimlich toll aus und es machte spaß auf dem Display rumzudrücken, allerdings war es während der Fahrt praktisch nicht zu bedienen, mal abgesehen von ziemlich vielen anderen qualitativen Mängeln wie schlechte RDS Implementierung, schlechter Empfang, ... Wenn die Mehrheit ein Touch panel haben wollte würde ich mich evtl. umstimmen lassen, ist halt nur meine bescheidene persönliche Meinung ;-)
Ein Autoradio sollte man bedienen können, ohne hinzugucken. Vor langer, langer Zeit war links Lautstärke, rechts Sender und unten vielleicht paar Stationstasten. Das war idiotensicher und der Fahrer guckte, wo er hinfährt. Ich stelle mir ein Radio mit 4 Encodern vor (die sind billig und einknopfbedienung ist ein Irrweg). Etwa so : links unten drücken: Ein/Aus, drehen : Lautstärke links oben drücken : Menü für diversen Schnickschnack den man nie braucht, drehen : MP3 Ordner (Album) rechts unten drücken : Radio, drehen : Senderwahl rechts oben drücken : MP3, drehen : Titelwahl so kommt man schnell an die wichtigsten Funktionen und wird nicht abgelenkt... aber es geht sicher noch besser
Die Dicke wäre für mich wichtig. Wenn es nur 1-2cm tiefgang hat, könnte man es auch ohne Loch irgendwo anpappen. (oder über das bestehende drüberkleben... ;-) Wenn man eine größere Leistung haben will nimmt (baut) man sowiso noch einen extra Versärker.
ohforf schrieb: > Ein Autoradio sollte man bedienen können, ohne hinzugucken. > Vor langer, langer Zeit war links Lautstärke, rechts Sender und unten > vielleicht paar Stationstasten. Das war idiotensicher und der Fahrer > guckte, wo er hinfährt. Genau meine Rede :-) Ich denke man kann die Anzahl der Knöpfe noch auf 2 reduzieren ohne echt Komfort zu verlieren, allerdings müßte man dann einige Funktionen als normalen Druckknopf realisieren (z.B. Taste "Radio", "MP3", "AN/AUS"). Das 4-Knopf Konzept find ich aber echt nicht schlecht, wenn man das Designmäßig einigermassen hübsch hinbekommt, die Knöpfe nicht zu klein und noch gut bedienbar wären.
Hallo Ihr, die Idee finde ich super. Daher gleich mal eine Frage zum Empfangsteil: Das soll ja sicherlich nicht selbst neu entwicket werden? Hat Du da schon was im Auge? habe mal gegoogled und bin auf ein Modul namens RS500 von der Fa. Radioscape gestossen. Technisat verwendet das wohl auch in einem ihrer Empfänger. Auch die Elektor hat mal auf das Teil hingewiesen. Aber der Fa. Radioscape ging es wohl mal nicht so gut. Auf deren Homepage findet man keinen Hinweis auf das Modul. Aber unter http://www.ok1mjo.com/all/ostatni/t-dab_dvb-t_drm/Radioscape/RS500_Overview_High_Res.pdf habe ich eine Beschreibung gefunden. Das Modul kann alles, was wir brauchen. Walter.
Hallo! Das hört sich ja schon mal sehr interessant an. Hier mal ein paar Kriterien die ich an solch ein Gerät hätte (ein paar davon wurden ja schon angesprochen): - Einfache Bedienung (also extra Tasten für Lied vor/zurück sowie Ordner vor/zurück und vielleicht Pause) - Gut ablesbares Display, sowohl bei direktem Sonnenlicht als auch in der Nacht, nicht zuviel Grafik-Schnickschnack wie Videos etc. - USB-Anschluss für Stick oder externes CD-Laufwerk - Bluetooth-Freisprecheinrichtung - Remote-Ausgang für externe Endstufen So, und jetzt kommts ;) - 3x Preout mit hohem Ausgangspegel (ca. 4V) - Laufzeitkorrektur für die einzelnen Kanäle - Aktivweichen (Hochpass, Tiefpass, Bandpass) mit 6, 12, 18 und 24dB Flankensteilheit pro Kanalpaar - Kanalgetrennte Pegelregelung - parametrischer Equalizer - hohe Klangqualität (Wie man sehen kann bin ich Car-Hifi Fan...) Die Geräte von Alpine find ich vom Bedienkonzept her klasse, daran könnte man sich evtl. orientieren... MfG Stefan
Also das mit der Helligkeit, kann man echt schön mit einem Sensor machen, bei unserem letztem Leasing Wagen (Mercedes E Klasse) war vorne einer, wenn es hell war, hatte die Anzeige eine Weiß bis Besche Grundfarbe, sonst ehr dunkel Grau bis schwarz...
Laufzeitkorrektur? bei 2m Lautpsrecher-Abstand? und dann solche steilen Filter? Meinst du nicht, mit dem Phasendreck, der da kommt macht man mehr kaputt als man mit der Laufzeitkorrektur ausgleichen kann? :D Naja ich denke, man muss immer Aufwand und Nutzen abwägen. Wann man für so etwas eine Community aufbaut, findet sich später sicher jemand, der diese Spielereien umsetzt. Im ersten Anlauf wärs wohl geschickt, sich auf das Wesentliche zu beschränken und nur die Möglichkeiten im Hinterkopf zu behalten. Konkret: Schnittstellen in Hard- und Software vorsehen. Vielleicht ist es ja tatsächlich der richtige Weg, dafür ein Website-Portal aufzumachen mit Forum, Artkeln, Kommentargedöns,... So wie das bei manchen anderen DIY-Projekten auch der Fall ist. Ich will hier keine Werbung machen ;) Die Resonanz ist auf jeden Fall da und das Projekt ist umfangreich. Wenn's nur schon fertig wär, mein Radio is kabutt!
Armin schrieb: > Laufzeitkorrektur? bei 2m Lautpsrecher-Abstand? > und dann solche steilen Filter? Meinst du nicht, mit dem Phasendreck, > der da kommt macht man mehr kaputt als man mit der Laufzeitkorrektur > ausgleichen kann? :D Ok, ich versuch das mal etwas zu erklären: Normale Musik ist in Stereo aufgenommen. Um die Musik also genau so zu hören wie sie aufgenommen wurde, werden die Lautsprecher in einem gleichseitigen Dreieck auf den Hörplatz ausgerichtet, das nennt man Stereodreieck. In meinem Auto befinden sich die Hochtöner an den A-Säulen, die Tiefmitteltöner in den Vordertüren und der Subwoofer im Kofferraum. Das ist der Grundaufbau einer "richtigen" Car-Hifi Anlage, dazu kommt natürlich noch eine Dämmung der Türen, um den Tiefmitteltönern ein richtiges Gehäuse zu bieten und peinliche Klappergeräusche zu vermeiden. ;) Da nun jeder Lautsprecher unterschiedlich weit weg ist, ergeben sich am Fahrersitz logischerweise sowohl Laufzeit- als auch Pegelunterschiede. Und diese führen dann zu Auslöschungen und Überhöhungen im Gesamtfrequenzgang am Fahrersitz. Um die Lautsprecher also dazu zu bringen, so zu spielen als wären sie alle gleich weit weg, benötigt man sowohl Laufzeitkorrektur als auch Pegelanpassungen. Und natürlich auch die Möglichkeit, jeden Lautsprecher nur die Frequenzen spielen zu lassen, für die er gedacht ist. Da ein Auto aber auch je nach Modell einen typischen "Fahrzeugfrequenzgang" hat, benötigt man noch einen Equalizer um solche Buckel und Täler auszugleichen. Wenn das alles richtig eingestellt ist, hat man eine richtige "Bühne" im Auto, so als ob die Band schön verteilt auf der Motorhaube sitzt wie im Studio auch. Hast du schon mal eine gut eingestellte Car-Hifi Anlage gehört? Damit meine ich nicht diese Proleten-Kisten, bei denen nur möglichst viel Bumm-Bumm in den Kofferraum geschmissen wurde... Dann weißt du was ich meine, denn das ist als ob die Sonne aufgeht. ;) Wenn man allerdings nur ein bisschen Hintergrund-Gedudel an den Werkslautsprechern haben will, ist der Aufwand natürlich zu hoch...
Stefan B. schrieb: > Da nun jeder Lautsprecher unterschiedlich weit weg ist die LS schallen von unterschiedlichen Winkeln an dein Ohr, mit LZ-Korrektur kann man das nicht ändern. Der Abstand zum Ohr ist hingegen fast identisch, da kommt man höchstens mal auf 10cm Unterschied. Die Schallgeschwindigkeit beträgt 343m/s, oder anders 2,9ms/m. Für 10cm würde die Differenz also 0,3ms Zeitdifferenz betragen. Ob den Unterschied auch von geschulten Ohren erkennbar ist, mag ich zu bezweifeln. Wie Armin bereits sagte, denk ich auch dass man beim Versuch so kleine Differenzen ausgleichen zu wollen mehr Schaden anrichtet als korrigiert...
Ich bin keiner dieser Voodoo-Anhänger die 5000 Euro nur für ein Super-Hyper-Netzkabel ausgeben, keine Angst. Und auch niemand, der irgendwelche zusammengeschusterten pseudo-physikalischen Beweise für die haarsträubendsten Produkte für bare Münze nimmt. ;) Ich bin ein technisch und physikalisch veranlagter Mensch. Also bitte spart euch die herablassende Art. Die Hochtöner sind direkt auf mich ausgerichtet, die sind das wichtigste. Denn die Hochtöner haben eine gewisse Richtcharakteristik. Diese Charakteristik ist von Membranfläche und Frequenz abhängig, aber das wisst ihr ja sowieso :P Bei den Tiefmitteltönern ist das nicht mehr ganz so wichtig, die Abstrahlung vom Subwoofer ist sowieso kugelförmig, und er gibt auch nur den Frequenzbereich wieder, den man nicht mehr orten kann. Die Differenz der Abstände der beiden Hochtöner beträgt bei mir übrigens ca. 50cm, und diesen Unterschied hört man. Auch ein nicht "geschultes" Ohr merkt das einwandfrei. Nimm ein Radio mit Laufzeitkorrektur, lass nur die vorderen Lautsprecher spielen und leg eine CD mit einer guten Aufnahme ein. Dann geh in das Menü der Laufzeitkorrektur, schließe die Augen und drehe nach Gefühl am Regler. Irgendwann wirst du merken, dass auf einmal der Klang räumlich abgebildet wirkt. Die Instrumente rücken aus dem diffusen Brei voneinander weg und stehen einzeln gestaffelt vor dir auf der Motorhaube. Und wenn du dir dann den Verzögerungswert ansiehst merkst du, dass der Wert ziemlich genau mit dem berechneten übereinstimmt. Ich behaupte nicht, dass meine Anlage perfekt abgestimmt ist, denn um das alles perfekt einzustellen benötigt man viel Erfahrung. Aber trotzdem haben auch Leute mit normaler Werksanlage eindeutig einen Unterschied festgestellt. Aber wahrscheinlich kann ich hier erzählen was ich will, bei so vielen Vorurteilen hat es einfach keinen Sinn...
Also, Hardwaretechnisch die Möglichkeit der Laufzeitkorrektur vorsehen, wenn die Kiste dann man läuft, kann das ein Profi einproggen...
GGast schrieb: > Also, Hardwaretechnisch die Möglichkeit der Laufzeitkorrektur vorsehen, > wenn die Kiste dann man läuft, kann das ein Profi einproggen... Ich denke auch das sollte machbar sein, zumindest als option der man sich "nachher" widmen kann. Da man in diesem Fall (jumperoption oder so) das Audio-signal vom radio durch den uC schleusen muss sollte man aufpassen das man snr und co. nicht zu sehr negativ beeinflusst. Oder man nimmt direkt einen digitalen Empfänger mit integriertem audio dsp. Von einem der 2 Marktführer weiss ich sicher das er eine Laufzeitkorrektur mitbringt, die man aber AFAIR mittels zu kaufenden code freischalten musste...
>(jumperoption oder so)
Oder so einen 4051 Analog-Multiplexer oder so... (Die modernen Typen
haben nur 6Ohm Innenwiderstand, wie geeignet diese für Audiosignale sind
weiß ich nicht)
Eine Laufzeitkorrektur für MP3 Playback wäre übrigens sehr einfach zu realisieren, auch ohne zusätzliche Hardwareoption. Was die Filter betrifft, da bin ich sehr skeptisch. Der Hardwareaufwand wäre immens und die Phasengänge der Filter machen sicher mehr kaputt als das sie helfen, gerade wenn man über Filter 4. Ordnung spricht.
Einen DSP kann man sinnvollerweise als Option (Aufsteckplatine auf Pfostenleisten) vorsehen, wenn es denn mehr als einen Nutzer gibt, der das braucht. Gast
Hallo
ich habe mir hier alles durchgelesen und muss sagen es hört sich alles
sehr interessant an.
An DAB scheint aber keiner mehr interessiert zu sein, zur Zeit werden
noch Programme in diesen Mode ausgesendet und wer zur der (kleinen ?)
Minderheit gehört die DAB nutzen wissen das es sich deutlich besser
anhört als FM, mann muß es nur mal vergleichen, aber leider will sich ja
die Masse darauf nicht einlassen.
Gegen einen Punkt möchte ich aber energisch Wiedersprechen
" * FM only (Mittelwelle/Langewelle und co ist denk ich heutzutage nicht
mehr echt interessant)"
Wer schon mal im weiter entfernten Ausland mit den Auto unterwegs war
und sich nicht nur durch Musik berieseln lassen wollte wird erkannt
haben wie wichtig LW und MW heute noch sein kann. Gerade auf LW werden
noch die Programme ausgestrahlt die "Radio zum Hinhören" sind, ich denke
dabei an den DLF, Deutschland Radio Kultur und BBC 4, alles bei
Internetzugang ohne Probleme zu "Empfangen" aber bei Mobilbetrieb im
Auto ?
Ich hoffe das ich nicht zu weit vom Thema abgedriftet bin.
Mit freundlichen Grüßen
"Radio Freund"
Kai G. schrieb: > Gegenschall ist denk ich nicht nötig, aber man kann mit ein paar Du kennst mein Auto nicht ;-) Vielleicht geht es ja den Gegenschall zu berechnen indem man einige Kalibrierungsfahrten macht, bei 50, 100, 130km/h oder so. Sicher, damit bekommt man nur gleichmäßige Motorgeräusche weg und Fahrtwind, würde vielleicht schon was nützen. > Da zerfliesst nix, OBD2 und Co machen keine Hitze (ausser beim Momentan habe ich so ein billiges Chinaradio, da ist hinten ein kleiner Lüfter drin und der rappelt nun auch noch. Während der Fahrt hört man das nichtmal selber, aber wenn man per Bluetooth telefoniert kann es das andere Ende sehr gut hören. > Programmierer während er die Software schreibt) ;-) > Die meiste Wärme macht die Sonne.
Ich hab jetzt nicht alles durchgelesen, aber wo wohnst du denn? Ich frage, weil ich glaube, dass man sich schon ab und zu treffen sollte um das weitere Vorgehen zu planen oder Prototypen zu testen oder so. Prinzipiell bin ich auf jeden Fall interessiert.
Hallo zusammen, erstmal find ich die Idee prinzipiell richtig gut! Wie man an den bisherigen Beiträgen erkennen kann, gibt es hier scheinbar 2 Fraktionen: Die HiFi-Freaks, und die Radio-Höhrer (zu letzteren zähl ich mich). Die Hifi-Freaks bauen Zusatzverstärker und -Lautsprecher ein, und legen im allgemeinen keinen Wert auf einen integrierten Verstärker. Hier ist dann Platz für einen DSP oder was auch immer. Als Radio-Höhrer hab ich hingegen absolut keine Lust, an meinem Auto rumzuschrauben, und Lautsprecher und/oder Verstärker einzubauen. Ich würde also grossen Wert darauf legen, mein bisheriges Radio ohne grosse Umbauten ersetzen zu können. Da wo bei den HiFi-Freaks der DSP sitzt, brauch ich also einen simplen (4-Kanal) Verstärker. Vielleicht kann man das modular gestalten, für den Fall, daß es mal einem dieser Hifi-Verrückten gelingen sollte, mich von der Sinnhaftigkeit einer solchen "Klangverschlimmbesserung" zu überzeugen. Zum Betriebssystem: ich würde klar für Linux plädieren! Wenn ohnehin ein Beagleboard o.Ä. verwendet wird, bietet sich das geradezu an! Auch die bereits weiter oben angesprochene WLAN-Anbindung ist damit direkt erschlagen. Diese Anbindung betrachte ich im Übrigen als extrem wichtig. Bis so ein Projekt wirklich rund läuft, und keine täglichen Updates mehr erfordert dürfte erstmal eine ganze Zeit vergehn....und wer hat schon Lust, für jede Kleinigkeit zum Auto zu rennen? Harry
Sven schrieb: > Ich hab jetzt nicht alles durchgelesen, aber wo wohnst du denn? Ich > frage, weil ich glaube, dass man sich schon ab und zu treffen sollte um > das weitere Vorgehen zu planen oder Prototypen zu testen oder so. Meine PLZ ist 47506. Klar, wenn das ganze konkreter wird wäre es sicher interessant sich auch mal zu treffen! > Prinzipiell bin ich auf jeden Fall interessiert. Klasse, das hört man gerne!
Harald L. schrieb: > Vielleicht kann man das modular gestalten, für den Fall, daß es mal > einem dieser Hifi-Verrückten gelingen sollte, mich von der > Sinnhaftigkeit einer solchen "Klangverschlimmbesserung" zu überzeugen. Ja, in gewissen Grenzen ist eine Modularität sicher nicht schlecht! > Zum Betriebssystem: > ich würde klar für Linux plädieren! Ich bin absolute überzeugt davon das man sowas komplexes wie Linux besser nicht auf einem Autoradio hat. Wenn man vorhätte ein Multimediasystem mit DVD, etc. zu implementieren wäre das sicher von Vorteil aber durch die Komplexität des ganzen schleichen sich unheimlich viel Fehlerquellen ein die man durch eine schlanke firmware die man komplett selbst geschrieben hat und man die komplette Übersicht hat vermeiden kann. Ich hab mit beidem Erfahrung und weiss wie einfach es ist ein deterministisisches und stabiles System mit einer von 0 auf selbst geschriebenen Firmware ist und wie kompliziert mit uCLinux/Busybox und Konsorten. > Auch die bereits weiter oben angesprochene WLAN-Anbindung ist damit > direkt erschlagen. Hat das Beagleboard Wlan on board? Wie ist es angebunden? Über einen internen USB-Bus? > Diese Anbindung betrachte ich im Übrigen als extrem wichtig. Bis so ein > Projekt wirklich rund läuft, und keine täglichen Updates mehr erfordert > dürfte erstmal eine ganze Zeit vergehn....und wer hat schon Lust, für > jede Kleinigkeit zum Auto zu rennen? Wie wäre ein Update über SD Karte über einen Bootloader. Beim einschalten checkt das Radio ob eine neue Firmware auf der Karte ist und programmiert sie "nebenbei" neu. Naja, Wlan wäre wirklich schon nicht uninteressant...
>Wie wäre ein Update über SD Karte über einen Bootloader. Beim >einschalten checkt das Radio ob eine neue Firmware auf der Karte ist und s/einschalten/einschalten mit gedrueckter Tastenkombination/ Gast
Kai G. schrieb: >> Zum Betriebssystem: >> ich würde klar für Linux plädieren! > > Ich bin absolute überzeugt davon das man sowas komplexes wie Linux > besser nicht auf einem Autoradio hat. Wenn man vorhätte ein > Multimediasystem mit DVD, etc. zu implementieren wäre das sicher von > Vorteil aber durch die Komplexität des ganzen schleichen sich unheimlich > viel Fehlerquellen ein die man durch eine schlanke firmware die man > komplett selbst geschrieben hat und man die komplette Übersicht hat > vermeiden kann. > Ich hab mit beidem Erfahrung und weiss wie einfach es ist ein > deterministisisches und stabiles System mit einer von 0 auf selbst > geschriebenen Firmware ist und wie kompliziert mit uCLinux/Busybox und > Konsorten. > bin ich völlig anderer Meinung! Ich hab auch mit beiden Varianten Erfahrung. Aber spätestens, wenn du einen TCP/IP-Stack implementierst, ist es mit dem Determinismus ohnehin vorbei. Wenn man Linux auf das wirklich Notwendige zurechtstutzt, ist das ein excellentes und stabiles Framework für so ein Vorhaben. OpenWrt ist z.B. eine ausgezeichnete Ausgangsbasis! > > Hat das Beagleboard Wlan on board? Wie ist es angebunden? Über einen > internen USB-Bus? > Stick per USB...der kann dann ggf auch an empfangsgünstiger Stelle installiert werden. > > Wie wäre ein Update über SD Karte über einen Bootloader. Beim > einschalten checkt das Radio ob eine neue Firmware auf der Karte ist und > programmiert sie "nebenbei" neu. > Naja, Wlan wäre wirklich schon nicht uninteressant... Genau! Wenn das Auto im Carport steht, kann ich per WLAN & SSH drauf zugreifen, und an dem System arbeiten. (Auch hier hilft uns Linux, weil auch SSH hier nicht neu geschrieben werden muss) Ach ja....und unterwegs kann darüber in Verbindung mit dem Mobiltelefon der Stick als AP arbeiten, und man kann per Laptop ins Netz. Harry
Als Teilzeit-Hifiverstärker-Hobbybastler kenne ich von da vor allem ein Problem: Es gibt keine Zigarrenkisten mehr ;-) Und vor allem niemanden, der noch Zigarrenkisten als wohnzimmergeeignetes Gehäuse akzeptiert. Software lässt sich beliebig komplex und in professioneller Qualtät gestalten, Platinen ebenso, aber bei den popeligen Dingen wie Gehäusen, Steckverbindern, Schalter, Blenden und Knöpfen hat man als Hobbyist keine Chance. Entweder man findet ein fertiges Gerät als Basis für die Entwicklung, oder es finden sich so viele Mitstreiter, daß man mal eben ein paar Spriztgußwerkzeuge in Auftrag geben kann, oder es sieht am Ende immer aus wie selbstgebastelt. Oliver
> bin ich völlig anderer Meinung! > Ich hab auch mit beiden Varianten Erfahrung. Aber spätestens, wenn du > einen TCP/IP-Stack implementierst, ist es mit dem Determinismus ohnehin > vorbei. > Wenn man Linux auf das wirklich Notwendige zurechtstutzt, ist das ein > excellentes und stabiles Framework für so ein Vorhaben. Ja, allerdings arbeitet man an 5 verschiedenen Baustellen (Scripts, deamons, Treiber, ...) statt an einer einzigen Firmware. Alles was ich so kenne mit Linux arbeitet auch nicht stabil. z.B. mein Chumby oder auch alle Fritz!boxen die ich so hatte (7050, 7270), Belkin router, etc... Ich nicht das jetzt ein Linux flamewar entsteht, aber wenn Wlan das einzige ist was einen zu Linux drängt, dann gibt es doch sicher noch andere Alternativen, oder?
> Software lässt sich beliebig komplex und in professioneller Qualtät > gestalten, Platinen ebenso, aber bei den popeligen Dingen wie Gehäusen, > Steckverbindern, Schalter, Blenden und Knöpfen hat man als Hobbyist > keine Chance. Entweder man findet ein fertiges Gerät als Basis für die > Entwicklung, oder es finden sich so viele Mitstreiter, daß man mal eben > ein paar Spriztgußwerkzeuge in Auftrag geben kann, oder es sieht am Ende > immer aus wie selbstgebastelt. Man könnte ein Front aus Kunststoff fräsen lassen (http://www.schaeffer-ag.de???). So ein Radio Chassis an sich ist wiederum nur ein Stück gestanztes Blech das an einigen Stellen gebogen ist. Irgendwo hatte ich vor ein paar Tagen eine Webseite gesehen mit einer Firmwa die genau sowas (blech biegen/ausbrüche machen/...) preisgünstig anbot. Ich denke auch das ein schönes Frontpanel die größte Herausforderung ist. Aus einem Schwarzem Stück Plastik sollte sich da eigentlich was fräsen lassen, vor allen dingen wenn es eben nicht wie alle anderen Autoradios aussehen soll (Transformer/Ufo mässig) und sich dezent in ein bisheriges Fahrzeug integrieren lassen soll. Ich weiß nicht wie utopisch es ist evtl. sogar einen Sponsor zu finden, oder eine Firma die kostenlos die mechanischen Teile erstellen würde wenn man etwas vorzuweisen hat und es wirklich so aussieht als ob man in der Lage ist ein echtes "Produkt" zu machen. Ein anderes Problem wäre noch das Platinenlayout an sich. Ich nutze für Hobbysachen eigentlich immer Eagle, allerdings ist das wie bekannt ist auf eine halbe Eurokarte begrenzt und ein Autoradio doch ein bißchen größer...
WLan in einem Auto? Wozu das denn? Abgesehen davon, das man die Antenne dann auch noch rausführen müsste, finde ich die "Synchronisation" per USB-Stick um Welten praktikabler und schneller. Meine Wunschliste - DAB+ - UKW - MP3 - Audio-CD (ergo: CD-Laufwerk) - USB-Anschluss für Stick - alternativ SD-Slot? - Bluetooth/Freisprecheinrichtung - 4-6 Stationstasten, im CD/Mp3-Modus gerne auch mit anderen Funktionen - Lautstärke & Titel/Ordnerwahl als echte Tasten. - direkter Anschluss für Lautsprecher. Also eigentlich gar nicht soo viel ;)
Kai G. schrieb: > Ja, allerdings arbeitet man an 5 verschiedenen Baustellen (Scripts, > deamons, Treiber, ...) statt an einer einzigen Firmware. > Bei so einem Projekt ändert das auch nix, wenn man das in einer Software macht...wird auf deine Art eher unübersichtlicher. > Alles was ich so kenne mit Linux arbeitet auch nicht stabil. z.B. mein > Chumby oder auch alle Fritz!boxen die ich so hatte (7050, 7270), Belkin > router, etc... Wenn die Hardware in Ordnung ist, laufen meine Router absolut stabil. Bes. Fritz-Boxen sind nicht gerade eben für ihre Stabilität bekannt. Und die Teile, wo die Probleme auftreten sind auch nicht Open-Source, sondern was propiätäres von AVM. Abstürze in embedded linux-Geräten würde ich zu >50% auf Hardwareprobleme zurückführen (Überhitzung etc..) Ich selbst betreibe einen Linksys WRT54g in einem wetterfesten Gehäuse auf der Spitze meines Antennenmast hier auf dem Haus. Das läuft mittlerweile seit >4j und ich kann mich an keinen einzigen Absturz erinnern. > > Ich nicht das jetzt ein Linux flamewar entsteht, aber wenn Wlan das > einzige ist was einen zu Linux drängt, dann gibt es doch sicher noch > andere Alternativen, oder? die da währen???? WLAN erfordert zwingend ein Netzwerkprotokoll. Was ausser TCP/Ip würdest du vorschlagen? Ich versteh vollkommen, wenn im kommerziellen Bereich für solche Projekte "selbstgestrickte" Software zum Einsatz kommt. Wenn das Gerät auf den Markt kommt, wird da i.d.R. auch nichts mehr verändert. Das Ziel hier ist allerdings nicht ein Produkt, sondern ein höchst exclusives und individuelles Gerät. Das heist aber auch, daß die Softwareentwicklung niemals einen wirklichen Endpunkt erreichen wird. Aus diesem Grund wünsche ich mir bei der Software (noch mehr als bei der Hardware) Modularität! Linux bringt die von Haus aus mit. Von den vielen Rädern, die man damit eben NICHT neu erfinden muss, will ich hier gar nicht reden. Harry
Ich finde die Idee echt klasse! Mein Wunschliste: - UKW - MP3 - USB-Anschluss für Stick - SD-Slot - Bluetooth/Freisprecheinrichtung - Lautstärke & Titel/Ordnerwahl als echte Tasten - Farbdisplay - Touchscreen mit Forcefeedback (nicht zwingend) Wlan halte ich nicht für sinnvoll und könnte deshalb auch gerne auf ein emb. Linux im Autoradio verzichten. Ein CD-Fach brauche ich auch nicht, wenn ein interner Speicher vorhanden ist. Die CDs würden nur mein Handschuhfach zumüllen. Ein schönes Frontpanel finde ich sehr wichtig
Ich hab das hier mal überflogen, baut ihr hier grade eine Eierlegende Wollmilchsau oder ein Autoradio?
Hallo zusammen, ich finde das auch interessant! Vor allem dieses: Kai G. schrieb: > Was mir vorschwebt: > - Optik: Das Radio sollte nicht wie ein "Ufo" aussehen > - Größe: Single DIN > - 2*Rotary button bedienung (Ähnlich Becker Grandprix) + ein paar feste > Funktionstasten ja, also von der Optik und Bedienung her würde mir auch sowas wie die Becker-Radios vorschweben. Wobei mir da die aktuellen Traffic-Pro eigentlich schon zu "bunt" wären, also von mir aus dürfte es auch gerne ein Monochromdisplay sein (nett wäre eines mit heller Schrift auf schwarzem Grund wie es früher bei Becker mal gab). Aber gegen ein Farbdisplay hätte ich auch nichts wenn die Software offen ist, könnte es ja dann bei Bedarf auch einfarbig ansteuern ;-) > * Einfache und schnelle (!) Navigation durch große MP3 Sammlungen > (Evtl. Hierachie Artist/Album/Track) > * Datenspeicher: z.B. SDHC Karten. Es wäre auch denkbar mehrere Karten > gleichzeitig zu unterstützen um den Speicher zu erweitern. Alternativ: > Ein USB OTG Host mit Mass storage support. SDHC fände ich auch sehr gut geeignet. Vor einigen Jahren (ca. 2002) habe ich mir einen MP3-Player fürs Auto gebaut, mit Festplatte allerdings, da ich >=30GB speichern wollte und damals selbst Notebook-HDs gerade mal diese Größe hatten; an Flashspeicher war daher nicht zu denken. Aber heute ist das ja zum Glück anders. Ein optisches Laufwerk bräuchte ich dabei nicht. > - Design Grundsätze: > * Funktionen sollten leicht erreichbar sein (keine 3 fach > Shiftfunktionen auf Buttons, etc...) > * Die Reaktion auf Benutzerfunktionen sollten schnell erfolgen. Wenn > eine Funktion länger dauert sollte sie vor Beendigung schon eine > Reaktion auf dem Display zeigen. > - Sehr schön wäre auch die Möglichkeit um den CAN Bus von Autos mit > einzubinden um Sonderfunktionen wie z.B. PDC auf dem Radio anzuzeigen. > Sowas ist Herstellerspezifisch, man kann es jedoch in der Hardware > vorsehen und in Software auswählbar gestalten. > - Evtl. Optionen um andere selbst entwickelte Boards einfach in die > Hard- und Softwareumgebung einzubinden, z.B. Amateurfunk transceiver, > Datenlogger, ... > - OBD2 Diagnose Option / Anzeigen oder Loggen von Sensordaten? und auch das wäre mir letztendlich wichtig: > Ich würde übrigens auch gerne wirklich alles Quelloffen machen, inkl. > der Hardware. Zu der Linuxfrage noch etwas (ich hoffe es kommt zu keinem Flamewar...): also nach den Erfahrungen mit der Entwicklung meines Players hatte ich mir eigentlich schon länger gedacht, dass ich wenn ich ihn nochmal aufbauen würde auch lieber Linux als Basis verwenden würde. Ich habe damals einen IPC@CHIP von Beck verwendet (kennt wahrscheinlich keiner, ist ein kleiner x86-Rechner auf dem ein DOS-kompatibles RT-OS läuft). Das Gerät läuft zwar nach wie vor ohne (oder fast ohne, wie das eben so ist findet man immer noch was zu verbessern daran ;-) ) Probleme, aber softwaretechnisch musste man doch einiges selbst machen was bei Linux eben schon mit dabei wäre (fing z.B. schon bei FAT32 und FTP an; rsync und SSH hätte ich mir noch gewünscht, usw...). Wobei mir aber Stabilität letztendlich wichtiger ist als Features. Und da Linux sicherlich komplexer ist als ein komplett eigenes System und somit auch potenziell mehr Fehler hat. Andererseits dürfte es aber gerade in den Basisfunktionen (Dateisystem, Netzwerk, Scheduler etc.) wieder besser durchgetestet sein... Gruß, Mathias
Mathias A. schrieb: > aufbauen würde auch lieber Linux als Basis verwenden würde. Ich habe > damals einen IPC@CHIP von Beck verwendet (kennt wahrscheinlich keiner, > ist ein kleiner x86-Rechner auf dem ein DOS-kompatibles RT-OS läuft). son IPC liegt bei mir auch noch rum...war mir aber für weitere Projekte zu teuer. > Wobei mir aber Stabilität letztendlich wichtiger ist als Features. Und > da Linux sicherlich komplexer ist als ein komplett eigenes System und > somit auch potenziell mehr Fehler hat. Andererseits dürfte es aber > gerade in den Basisfunktionen (Dateisystem, Netzwerk, Scheduler etc.) > wieder besser durchgetestet sein... > Ich möchte wetten, daß die Anzahl der Bugs / Zeile Quellcode deutlich niedriger ist, als dieser Wert bei den allermeisten Selbstbau-Projekten in diesem Forum! Die Kernfunktionen bei Linux sind tausendfach getestet, und zum Teil sogar in kritischen Bereichen im Einsatz. (Bsp.: SE-Linux-Erweiterung: wurden von den freundlichen Schlapphutträgern vom NSA beigesteuert...würden die sicher nicht tun, wenn Linux nicht ohnehin die beste Basis für so ein Projekt gewesen wäre) Ausserdem wiederstrebt es mir, Code, der bereits existiert UND getestet ist neu zu schreiben. Wovor die meisten Schiss haben: "das Schreiben von Devive-Treibern" ...auch das ist keine Kunst, wenn man bereit ist, sich da ein kleinwenig einzuarbeiten. Beispielcodes für "einache" Device-Treiber gibts ja genug im Kernel. (I²C Bitbanging-Treiber z.b.) Ich glaube nicht, daß es gelingt, die vollständige Software für so ein Projekt "from scratch" aus dem Boden zu stampfen, und das ganze dann auch noch so fehlerfrei, daß es mit einem Linux-System konkurrieren kann. Und jetzt möchte ich mal noch ein weiteres Argument ins Spiel bringen: Alle Welt redet über heim/haus/hof/auto-vernetzung.....als (einheitliches) Protokoll kristallisiert sich immer mehr TCP/IP heraus...über welches Medium auch immer. Jedoch wird es sich dabei in Zukunft sicher nicht mehr um IP v4, sondern um IP v6 handeln. Einen IPv4-Stack hab ich zu DOS-Zeiten gemeinsam mit einem Freund programmiert....bei einem v6-stack hätte ich grosse Bedenken, das zu stemmen... Wozu das Ganze? Wie ich bereits oben geschrieben hab, interessiert mich der eigentliche HiFi-Aspekt weniger. Was ich mir allerdings vorstellen könnte, wäre, eine Netzwerkleitung in den Kofferraum zu legen, und dort einen weiteren Car-PC anzubinden. Die Ideen gehen da in Richtung Navigation (Ja1!...auch da tut sich was in der Open-Source-Scene) Ich denke, daß man sich (zumindest hinsichtlichtlich der Software) nicht am Heute, sondern am Morgen orientieren sollte. Mobile Breitbandzugänge sind zukünftig auch für jedermann bezahlbar. Um diese Dienste sinnvoll nutzen zu können, bedarf es genormter Protokolle und eine zuverlässige Implementierung derselben. Linux leistet das, und ist extrem skallierbar. Harry
Die Idee eines Open Source Autoradios ist schon mal super. Meine Meinung im Einzelnen: - HiFi Qualitäten brauche ich nicht. Hab genug Störgeräusche im Auto. - WLan finde ich extrem sinnvoll. Ich möchte eben nicht eine Synchronisation mit meinem MP3 Bestand per Hand (resp. USB-Stick) vornehmen müssen. Das kann ich jetzt schon (ja, es gibt schon Autoradios, die MP3s vom USB-Stick lesen). Der Mehrwert dieses Projektes wäre für mich, dass man die interne Speicherkapazität so auslegen kann, dass meine komplette Sammlung in das Auto passt und dann auch automatisch bein Stehen im Carport mit dem MP3-Server im Haus synchronisiert wird. So ca. 50 Gbyte würden übrigens für mich reichen. Und der zweite große Vorteil wäre der Einfluss auf die Front-Gestaltung. Ich bin auch für so wenig Interface-Elemente wie möglich (gab oben schon gute Vorschläge) und keine Farbe oder so was. Dezent und schlicht und bedienbar ohne hinzukucken! Normalerweise schreibe ich mir auch für alles Selbstgebastelte ein eigens Mini- (eher Mikro-) Betriebssystem, dann weiß ich was es macht. Aber das WLan ==> Linux Argument is absolut überzeugend. Und stabil ist Linux auf der richtigen Hardware allemal (Linksys WRTG, Buffalo NAS etc pp). Beitragen könnte ich wohl (in kleinem Umfang) bei der Software (in C). Bei Hardware stümpere ich nur so rum.
Hifi im Auto ? Das Auto ist einfach ein scheiß Resonanzkörper also hifi nein danke. Elektronische Frequenzweiche usw ist da schon interessanter. Naja linux wär ned schlecht aber 300MHz und linux + noch ein paar Spielereien ? Geht ned. Wie schon erwähnt wär der OMAP (L)xxx eine gute Basis. Die Bedeinung ist so eine Sache morgens zur arbeit will ich nur meinen Ö3 hören sonst nix und beim heimfahren auch. Dann am Wochenende steigen die Ansprüche die Freundin will die MP3 Sammlung durchhören :-( da ist dann ein Touch praktisch. Aber warum macht man die bedienung nicht gleich freiprogrammierbar. SQLite DB rein um Favoritenliste usw anzulegen. Also als HW basis: TI OMAP als MPU einen fertigen Audio IC von TI, AD usw dran platinen intern wird Sound via I2S und Daten über SPI übertragen. Extern CAN + I2C Wo kann ich helfen ? Mich nerven die ganzen Wunschlisten, wünsche hat jeder ! Dies Projekt ist auch ned in ein bis zwei Monaten fertig ! Ich kann dich unterstützen bei der Firmware und (Kernelprogrammierung bin noch beim einarbeiten), minimal HW, Testen und Projektmanagment. Was wird gebraucht ? 1. Kleine Website mal. 2. Ein Kern-Entwicklerteam welche dauerhaft an dem Projekt arbeiten und nich wie andere einfach abspringen. 3. Obwohl es Opensource ist werden auch Geld und andere Ressourcen benötigt. (gründung Verein oder so in die Richtung) 4. Viel Kaffee und eine Mailingliste
> Ich wollte mal vorsichtig fragen ob es Leute gäbe die prinzipiell > Interesse daran hätten an einem noch nicht existierenden Open source > Projekt teilzunehmen bei dem es darum geht ein komplettes Autoradio zu > entwickeln. Ich halte das grundsatzlich fuer eine gute Idee, sogar so gut das sie mir selber bereits vor 5-6Jahren gekommen ist. (Leider bin ich aber nie dazu gekommen das fertigzustellen) Und grundsatzlich ist es ja auch mal eine nette Idee ein groesseres Project mit ein paar Leute durchzuziehen. Allerdings sehe ich etwas Konfliktpotential. :-) So halte ich z.b TouchLCD fuer den groessten Unsinn seit der Erfindung des Fuchschwanzes an Autoantennen. Und auch deine Idee mit den Encodern mag ich nicht so weil sie keine direkte Rueckmeldung erlauben. Man muss zur Bedienung auf ein LCD schauen um zu wissen was man da macht. Ich wuerde eher moeglichst viele Tasten gut finden weil deren Position und Bedeutung nach kurzer Zeit auswendig weiss und man sie dann einfach druecken kann ohne zu schauen. > - Größe: Single DIN Halte ich fuer sehr vernuenftig. Zumal das ja eine Menge Platz ist wenn man keine Mechanik fuer Kasette oder CD unterbringen muss. > * evtl. DRM (?) Halte ich fuer Unsinn. Wird sich eh nicht Durchsetzen und der Empfangsteil fuer Kurzwelle/Mittelwelle wo ja gesendet wird, wuerde dir in der mit Stoerungen verseuchten Umgebung im Auto graue Haare bereiten. Und die implementierung der Decodierung ist ja auch nicht ohne. Also ein riesen Aufwand ohne grossen Nutzen. > * RDS, inkl. Follow me, Radio text (+), TA, EON > * Evtl. TIM (Aufzeichnung von Verkehrsnachrichten wenn das Radio > eigentlich aus ist und wiedergabe wenn das Auto das nächste mal > gestartet wird). Halte ich alles fuer Unsinn. Aber das schoene an solchen Projekten ist ja das jeder seine eigene Firmware haben kann. :-) Ich wuerde es aber fuer wichtig halten das ein Radio keinen Strom verbraucht wenn das Auto aus ist. Es gibt ja Leute die benutzen ein Auto auch mal laengere Zeit nicht. > * Der Empfang sollte wirklich sehr gut sein. Gutes Groß- und > Kleinsignalverhalten. Dir ist klar das dies dann ein hoellischer Aufwand wird wenn du den Tuner nicht zukaufen willst? Es hat ja Gruende warum auch gestandene Hersteller von Audio/Videokram Tuner lieber kaufen. > * 4 Kanal Verstärker (Evtl. Class-D) Halte ich nichts von. Gelegenheitshoerer brauchen nur eine Endstufe fuer zwei Lautsprecher. Wer Ansprueche stellt will sowieso mehr Leistung haben und schliesst dann immer eine externe Endstufe an. Was du aber unbedingt vermeiden musst sind so miess designte Rotzkisten die einen eigenen Luefter brauchen und wo schon beim Einbau klar ist das sie 2-3Jahre spaeter kaputt sind weil dann der Luefter tot ist und die ELektronik kurz darauf folgt. Man sollte also nicht viele Waermequellen haben. Oh..und Class-D wiederum passt nicht sorecht in deine Wunschliste mit einem moeglichst guten Tuner. > * Funktionen sollten leicht erreichbar sein (keine 3 fach > Shiftfunktionen auf Buttons, etc...) Da haette ich kein Problem mit. Es ist einfacher sich drei Belegungen zu merken, mein Taschenrechner hat IMHO sogar sechs Belegungen, als jedesmal zu gruebeln in welchem Untermenue irgendeine Funktion jetzt ist. * Die Reaktion auf Benutzerfunktionen sollten schnell erfolgen. Ist das keine Selbstverstaendlichkeit? Nein, im Zeitalter von Pfusch und Billig wohl nicht mehr, seufz. > Was haltet Ihr davon? Die Liste ist nur als Vorschlagliste zu > verstehen und natürlich nicht 100% fest. Du musst die Hardware modularisieren. Also im Prinzip eine Art kleines Mainboard mit der CPU. Darauf dann Slots wo man Zusatzkarten reinsteckt. Denkbare Karten waren dann: 1. Tunermodul. 2. Bluetoothmodul 3. Spezialmodule fuer Tasten am Lenkrad bestimmter Autos 4. Spezialmodul um die Fehlercodes meiner ECU auszulesen und anzuzeigen. usw.... Auch die Rueckseite sollte modular sein. Das haette den Vorteil das du relativ leicht etwas aendern koenntest ohne jedesmal gleich die gesamte Platine neu machen zu muessen. Oder glaubst du das dein PCB des Tuners beim ersten Versuch laufen wird? Ausserdem kann man so den Entwicklungsaufwand auf mehrere Leute aufteilen. Dann wollen wir mal nicht vergessen das so ein Project fett ist und lange dauern wird. Man muss moeglichst schnell zu einer Hardware kommen mit dem jeder erstmal was rumspielen kann. > 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). Ich will dich da nicht missionieren, aber ich hab mir gerade in Japan mal wieder eine Elektronikzeitung gekauft wo Renesas eine Platine mitliefert. Da ist eine SuperH-2A CPU drauf SH7262. Datenblatt ueber 2000Seiten. Speziell fuer Audiodevices gedacht, SPDIF integriert, I2S integrierst, I2C integriert, CAN, SD-Karte mit 1Bit und 4Bit integriert, 1MByte internes Ram in der CPU. AUsserdem Fliesskomma-DSP der sicher genug Power fuer MP3 hat ohne auch nur einen Muskel anzuspannen. :-) USB2.0 integriert, DMA, usw usw. Wirf mal einen Blick drauf. > Ich würde übrigens auch gerne wirklich alles Quelloffen machen, inkl. > der Hardware. Das ehrt dich natuerlich. Ich haette damit eigentlich auch kein Problem, auch wenn mich die ganzen Mitlaeufer die immer nur haben wollen ohne jemals selber etwas zu leisten, langsam nerven. Soll heissen Wunschlisten darf nur einreichen wer auch etwas zu dessen verwirklichung beitragen kann! Allerdings frage ich mich ob das etwas bringt. In so einem Design waeren sicherlich einige spezielle Bauteile drin. (CPU, TunerIC, LCD, Bedienungselemente, Mechanik, ISO-Steckverbinder) Die kann man sich nicht alle bei Maxim zusammenschnorren. Und die wird man auch nicht alle problemlos in Einzelstueckzahlen bekommen, jedenfalls nicht ueber einen laengeren Zeitraum. Jetzt aber zu meinem Hauptproblem. Wie willst du die Mechanik machen so das es auch nur halbwegs brauchbar aussieht. Du kannst schliesslich keine Plastikteile spritzen lassen. Und alles was du selber machen kannst sieht selbst bei groesster Muehe immer mehr oder weniger Hingebastelt aus. Als ich deshalb mein Autoradio angefangen habe, da habe ich mir ein altes Autoradio bei Ebay gekauft (SOny oberklasse Baujahr 1989) das meinen Wuenschen am naechsten kam und es entkernt. So haette ich Tasten und LCD, also die ganze Front weiterverwenden koennen. Der Kassettenschacht wird zugemacht und bietet die Moeglichkeit eine SD-Karte einzuschieben oder aehnliches, ist ja noch Platz. Dieser Ansatz sieht vernuenftig aus! Ist aber nur schwer zu realisieren wenn sich viele Leute ein Radio bauen wollen. Oder die Preise bei Ebay werden explodieren. Dann mal zu den Kosten. Ich glaube nicht das soetwas unter 500Euro an Kosten pro Radio machbar ist. Wieviele Leute sind jetzt noch dabei und nicht in Ohnmacht gefallen? :-) Es ist aus finanziellen Gruenden eigentlich Unsinn sowas zu machen, kaufen ist immer billiger. Die Sache ist nur die, ich habe eines der teuersten Autoradios die es gibt und aerger mich jeden Tag aufs neue ueber die hirntote Firmware. Daher kommt meine Motivation fuer die Sache. Oh..und du kannst und willst anderen sicher nicht die Arbeit abnehmen indem du ihnen Bausaetze verkaufst. Gerade in Autobastlerkreisen gibt es viele Leute deren Ambitionen groesser als ihre Faehigkeiten sind. Wenn da einer sein Auto abfackelt oder gegen seinen finalen Baum faehrt dann koennte es sonst Erklaerungbedarf geben. Zusammengefasst wuerde ich sagen, man ueberzeuge mich davon das die Optik des Radios hinterher stimmt und ich bin dabei. Ich moechte aber nicht das es in meinem Auto so aussieht wie auf meinem Etechnik-Schreibtisch oder wie etwas das man mit 15 in eine Zigarrenkiste eingebaut hat. Es bringt nichts hier ellenlang ueber Wunschtraeume zu debatieren die sich letztlich alle mit ein paar ICs und etwas Programmierung erfuellen lassen, wenn das Konzept der Mechanik nicht stimmt. Wie willst du z.b das Gehaeuse mit den Nasen zum reinschieben ins Auto realisieren? Im Prinzip waere es wohl am einfachsten wenn man ein neues Autoradio der Luxusklasse kauft, und die Firmware darin durch etwas eigenes ersetzt. Also so aehnlich wie Rockbox bei den MP3-Playern. > Wer schon mal im weiter entfernten Ausland mit den Auto unterwegs war > und sich nicht nur durch Musik berieseln lassen wollte wird erkannt > haben wie wichtig LW und MW heute noch sein kann. Ich bin oefter im entfernten Ausland unterwegs und habe keinerlei Bedarf an deutschen Radiosendern und schon garnicht auf Langwelle oder Mittelwelle. Pfui Deibel. Die paar Leute die es da noch gibt sind den Entwicklungsaufwand nicht wert. Gerade in dem Frequenzbereich hast du doch am ehesten Stoerungen. Selbst die arevierten Hersteller von Autoradios tun sich damit extrem schwer! Aber wer das wirklich will kann es sich ja selber nachruesten. Das ist einer der Gruende warum ich ein Steckkartenprinzip fuer wichtig halte. > Alles was ich so kenne mit Linux arbeitet auch nicht stabil. Das stimmt so allgemein nicht. Solche Projecte auf Linuxbasis sind nicht stabil weil dort Linux verwendet wird um sich Arbeit zu sparen. Die klauen sich also ueberrall rumliegende Source zusammen und modeln da in moeglichst kurzer Zeit was draus zusammen. Das ist einer der Gruende warum Linux nicht geeignet ist! Diejenigen die das hier propagieren, wollen sich damit Arbeit sparen und glauben sich so jeden Firlevanz in das Projekt holen zu koennen. Da kommt dann am Ende wackeliger Murks raus. Deshalb bin auch ich gegen Linux! > z.B. mein Chumby Du hast auch einen? Man muss nur die Flashscheisse komplett loeschen und alles mit Qt programmieren, dann macht das Dingen Spass. .-) > So ein Radio Chassis an sich ist > wiederum nur ein Stück gestanztes Blech das an einigen Stellen gebogen > ist. Irgendwo hatte ich vor ein paar Tagen eine Webseite gesehen mit > einer Firmwa die genau sowas (blech biegen/ausbrüche machen/...) > preisgünstig anbot. Mach das doch mal oder erkundige dich was sowas kostet. :-) Es waere dann sicher billiger im naechsten Geizladen ein Billigradio zu kaufen und das Blech von dort weiterzuverwenden. Wie ich schon sagte, so ein Projekt haengt zu 100% an der Mechanik, der Etechnikkram ist dagegen relativ einfach zu schaffen und vor allem zu finanzieren. > ja, also von der Optik und Bedienung her würde mir auch sowas > wie die Becker-Radios vorschweben. Und da kommen wir an die Stelle wo die Probleme anfangen. Ich finde das minimalistische Design von Becker und Blaupunkt einfach nur schlim und wuerde es niemals akzeptieren. Wobei ich natuerlich Verstaendnis dafuer habe das es da andere Meinungen gibt, aber wie will man das unter einen Hut bringen. Ich will Tasten. Je mehr desto besser! > Naja linux wär ned schlecht aber 300MHz und linux + noch ein paar > Spielereien ? Geht ned. Das ist eine Meinung die ich zu 100% Teile. Und auf meinen Rechner laeuft zu 99% der Zeit Linux seit 0.95a. .-) Jedes Betriebsystem wuerde zuviel Rechenzeit brauche und das Zeitverhalten komplizieren. Ich weiss man kann das mit viel Aufwand hinbekommen, aber das was einem Linux schenkt, einfacher Zugriff auf viele treiber ist unnoetig. Ich brauche auch gewiss kein WLAN im Auto. Sonst verlange ich als naechstes einen Newserver damit ich usenet unterwegs lesen kann. BTW: Wer sowas sucht soll sich einen Chumby aufs Armaturenbrett schrauben. Da ist schon alles drin. :-D Mir wuerde als System eher soetwas wie bei den alten Palmpiloten vorschweben. Jetzt nicht die Optik, aber ein Eventbasiertes System wo kein Programmteil dauerhaft Rechenzeit an sich ziehen darf. Einfach durchschaubar und schnell. > Mich nerven die ganzen Wunschlisten, wünsche hat jeder ! Dies Projekt > ist auch ned in ein bis zwei Monaten fertig ! Das habe ich auch so gedacht. Viele hier machen sich garnicht die Vorstellung was da fuer ein Aufwand drin steckt! Wenn ich z.B DAB lese! Nicht nur das diese Pferd bereits tod ist und anfaengt zu riechen. Diskret aufgebaute DAB-Tuner waren Zusatzgeraete fuer den Kofferraum und die Chipsaetze die es vielleicht dafuer gibt kann man garantiert nicht einfach so kaufen und mit Opensource wird es dann auch vorbei sein da ich nicht glaube das man da ohne NDA ran kommt. > 3. Obwohl es Opensource ist werden auch Geld und andere Ressourcen > benötigt. (gründung Verein oder so in die Richtung) Oh Gott, sobald sich mehr als drei Deutsche zusammenfinden muessen sie einen Verein gruenden, einen Kassenwart waehlen und auf die anderen herabsehen oder sie ausschliessen? Ich denke man kann sich entweder so zusammenraufen oder man laesst es. Olaf p.s: Mist, jetzt musste ich doch von meinen ewigen Grundsaetzen abweichen und mich hier anmelden weil ich sonst nicht posten darf. Seufz. ps2: Dieser Text wurde in einem externem Editor geschrieben und hier reinkopiert weil es in dieser Grafikusenetkopie keinen Emacsmode zu geben scheint. Ich hoffe es kommt daher alles vernuenftig rueber. .-)
Das Frontpanel könnte man evtl. per Rapid-Prototyping erstellen lassen. Ich denk dabei nicht an das Lasersinterverfahren, sondern an die thermoplastische Schichtung. Was die Kosten sind, weiß ich allerdings nicht. /Offtopic: @Olaf: Warum musst du dich anmelden? Wenn ich im Studentenwohnheim bin, kann ich auch nur angemeldet schreiben. Im Institut geht's unangemeldet...
Hallo zusammen! Auch ich bin von der Idee gnadenlos begeistert! Vielleicht sollten wir, um die Ideen zu sammeln, eine Wiki-Seite in Anspruch nehmen, das ist übersichtlicher als der Thread (den man ja für Diskussionen verwenden kann). VG
Florian Th. schrieb: > Auch ich bin von der Idee gnadenlos begeistert! Vielleicht sollten wir, > um die Ideen zu sammeln, eine Wiki-Seite in Anspruch nehmen, das ist > übersichtlicher als der Thread (den man ja für Diskussionen verwenden > kann). Ich denke auch. Ich werde ein Wiki / Mailingliste oder Forum auf die Beine zu stellen!
Du kannst auch einfach einen Artikel hier im (Foren)Wiki erstellen.
Olaf Kaluza schrieb: > Ich haette damit eigentlich auch kein > Problem, auch wenn mich die ganzen Mitlaeufer die immer nur haben > wollen ohne jemals selber etwas zu leisten, langsam nerven. > Soll heissen Wunschlisten darf nur einreichen wer auch etwas zu > dessen verwirklichung beitragen kann! open source ist opden source. Nutzen darf jeder, wünschen sowieso jeder, aber solange keiner was macht, passiert sowieso nichts. open source funktioniert nicht mit Wunschlisten. open source funktioniert nur dann, wenn sich da einer oder einige hinsetzen, und was machen, nicht wünschen. Und das speziellen (Noch-Nicht)-Projekt hier hat dazu das Problem, daß es noch zu schaffende Hardware benötigt, ohne die alle Softwareträume Träume bleiben. Oliver
Oliver schrieb: > open source ist opden source. Nutzen darf jeder, wünschen sowieso jeder, > aber solange keiner was macht, passiert sowieso nichts. > open source funktioniert nicht mit Wunschlisten. open source > funktioniert nur dann, wenn sich da einer oder einige hinsetzen, und was > machen, nicht wünschen. Und das speziellen (Noch-Nicht)-Projekt hier hat > dazu das Problem, daß es noch zu schaffende Hardware benötigt, ohne die > alle Softwareträume Träume bleiben. ja, allerdings muss man erstmal mit einer Basis anfangen und dementsprechend die Hardware designed. Wenn man vorher nicht wenigstens ein paar der Wünsche berücksichtigt dann fehlen von Anfang an viele Features und keiner hat noch wirklich interesse an der Sache.
Virus 744 schrieb: > Kai G. aus B. bei H. ???? > Falls ja, dann meld dich mal wieder. Ne, eher Kai G. aus N.-V. bei D :-)
Ich finde die Idee eines OS Radios cool. Meine Frage wäre aber: warum muss es eine Eierlegendewollmilchsau Lösung sein? Ich fände eine modulare Bauweise besser (also eine Trennung Empfangsteil -> Verstärker), da in den Einbauschächten bedingt durch die Nähe zur Heizung oft hohe Temperaturen herrschen und ein Verstärker ja nun mal Abwärme produziert... Zudem kann Derjenige, der eine Laufzeitanpassung der Boxen u.a. braucht, die in welcher Form auch immer bereitgestellte "NF" entsprechend aufbereiten und wer das nicht braucht ebend nicht. Der eine braucht Krach mit mindestens 8*1000W und extra "Bumsbox" ( ;-)), dem Anderen reichen 2*9 Watt auch. Es soll ja nicht so unüblich im Kfz-Bau sein, Vorne nur noch das Bedienteil zu haben... Zudem fände ich es praktisch, zusätzliche Funktionen anzudenken, wie z.B. einen Timer, der meine (Stand-)Heizung steuert. Ist bei Webasto ja nur ein High-Side Switch erforderlich und da an einem Radio ja immer 12v anliegen (Kl. 30) auch nicht schwer zu implementieren. LG Elux
Oliver Stellebaum schrieb: > Kai G. schrieb: > >> Gegenschall ist denk ich nicht nötig, aber man kann mit ein paar > > Du kennst mein Auto nicht ;-) > Vielleicht geht es ja den Gegenschall zu berechnen indem man einige > Kalibrierungsfahrten macht, bei 50, 100, 130km/h oder so. > Sicher, damit bekommt man nur gleichmäßige Motorgeräusche weg und > Fahrtwind, würde vielleicht schon was nützen. Was ich mich immer gefragt habe: Würde das funktionieren, wenn man ein 2tes Mikro irgendwo verbaut, das beim Sprechen nicht direkt beschallt wird und dessen Signal man vom Sprachmikro abzieht? Man könnte ja auch dem 2ten Mikro ein paar Filter spendieren, die die typischen Sprachfrequenzen durchlassen. Schon klar dass man die Phasenlage der Signal aneinander anpassen müsste. Aber würde das prinzipiell funktionieren? Ansonsten bin ich auch ein Verfechter von schlichtem Design. Lieber weniger, aber das durchdacht. Für mich wichtig: Freisprech über Bluetooth. Nach Möglichkeit sollte die auch mit 3 oder 4 Handys gleichzeitig klarkommen. (Meiner kann nur eines. Ist immer lustig, wenn die Holde mit im Auto ist. Welches Handy krallt sich die Freisprech) HiFi ist für mich nicht so die Priorität. Mein Auto muss nicht zum Konzertsaal werden. Touch-Panel: Bitte nicht.
> @Olaf: Warum musst du dich anmelden? Weil ich gerade Auslaender bin. Nur Inlaender duerfen als Gast schreiben. > Und das speziellen (Noch-Nicht)-Projekt hier hat > dazu das Problem, daß es noch zu schaffende Hardware benötigt, ohne die > alle Softwareträume Träume bleiben. Das ist natuerlich richtig. Was ich meinte das es nervt wenn Leute mit Forderungen kommen die sich nicht vorstellen koennen was fuer ein Aufwand in der Realisierung steckt. Nimm z.B mal den Empfang von Lang und Mittelwelle. Jeder hier der schonmal ein Radio fuer diese Frequenzen in die naehe seines ersten Mega8 gehalten hat wird wissen das dies nicht so einfach ist. Ich meine ein Hobbyproject ist was anderes als die Entwicklungsabteilung von Blaupunkt. Letzere hat naemlich den Vorteil bei jedem neuen Radio 100Mannjahre Erfahrung und 50% der Schaltungstechnik vom letzten Project verwenden zu koennen. Aber wie schon gesagt, deshalb halte ich es fuer sehr wichtig so ein Project zu modularisieren. Man muss erstmal ein Mainboard habe wo im Prinzip nur Display, Tastatur, zwei SD-Slots (intern, extern) und ein Audioausgang dran ist. Das hat zum einen den Vorteil das einige Leute schonmal programmieren koennen, waerend andere an der Hardware basteln. Und vor allem hat es den Vorteil das die schwierigste Arbeit, naemlich Design und Mechanik da bereits weitestgehend erledigt sind. Jede Aenderung an letzerem ist naemlich teuer. > Ich fände eine modulare Bauweise besser (also eine Trennung Empfangsteil > -> Verstärker), da in den Einbauschächten bedingt durch die Nähe zur > Heizung oft hohe Temperaturen herrschen und ein Verstärker ja nun mal > Abwärme produziert... Das ist absolut richtig. Es braucht nur einen kleinen Verstaerker im Radio selber. Sagen wir mal die ueblichen 2x12W. Es gibt viele Leute denen reicht soetwas. Diejenigen die mehr wollen werden immer einen externen Verstaerker verwenden. Ich habe z.b immer die 2x12W fuer die Frontspeaker verwendet und dann meist 2x50 oder 2x100 fuer die hinteren Lautsprecher. BTW:Ein Subwoofer ist immer ein Zeichen von schlechtem Design. .-) > Zudem kann Derjenige, der eine Laufzeitanpassung der Boxen u.a. braucht, > die in welcher Form auch immer bereitgestellte "NF" entsprechend > aufbereiten und wer das nicht braucht ebend nicht. Ich halte soche Laufzeiten zwar auch fuer Unsinn, allerdings nicht weil sie sich nicht auswirken, sondern weil normale Menschen auch mal Beifahrer im Auto haben. Technisch ist sowas aber nur ein entsprechend grosser Pufferspeicher. Also programmiertechnisch ein Witz. > Zudem fände ich es praktisch, zusätzliche Funktionen anzudenken, wie > z.B. einen Timer, der meine (Stand-)Heizung steuert. Sowas halte ich in der Tat fuer eine gute Idee. Genauso wie mein Wunsch meine ECU auslesen zu koennen. Aber das sind dann wohl Sachen die jeder fuer sich privat auf die Beine stellen muss. Olaf
> Und grundsatzlich ist es ja auch mal eine nette Idee ein groesseres > Project mit ein paar Leute durchzuziehen. Allerdings sehe ich etwas > Konfliktpotential. :-) Klar, das hat man in jedem Projekt, oder? :-) > So halte ich z.b TouchLCD fuer den groessten Unsinn seit der > Erfindung des Fuchschwanzes an Autoantennen. Und auch deine Idee > mit den Encodern mag ich nicht so weil sie keine direkte Rueckmeldung > erlauben. > Man muss zur Bedienung auf ein LCD schauen um zu wissen > was man da macht. Ich bin auch ein großer Unterstützer der einfachen Bedienung (und zur not mehr tasten unterzubringen), aber das stimmt denk ich nicht ganz: Lautstärke = Rückmeldung (Lauter/leiser) Sender wechseln = Audio Rückmeldung (anderer Content) auf MP3 Umschaltung = Audio Rückmeldung (Mp3 wird abgespielt) MP3 Track ändern = Rückmeldung (anderes MP3 wird abgespielt) ... Nicht so viel anders als bei Tasten. Natürlich etwas Verstand bei der Umsetzung vorrausgesetzt. Und um so Sachen wie Bass zu ändern oder so muss man auch bei Tasten auf das Display schauen, weil man sowas bestimmt nicht vom Top level aus änderbar macht weil man es nicht oft braucht. >> * RDS, inkl. Follow me, Radio text (+), TA, EON Hier hab ich noch RDS-ClockTime als Feature vergessen... >> * Evtl. TIM (Aufzeichnung von Verkehrsnachrichten wenn das Radio >> eigentlich aus ist und wiedergabe wenn das Auto das nächste mal >> gestartet wird). > Halte ich alles fuer Unsinn. Aber das schoene an solchen Projekten ist > ja das jeder seine eigene Firmware haben kann. :-) RDS unsinn? Staumeldungen sind doch nicht gerade uninteressant... TIM kann man mit einem Stromverbrauch <2 mA umsetzen. Ich finde sowas sollte man wenigstens im Powerkonzept mit Berücksichtigen zumal man evtl. auch noch etwas anderes im Hintergrund wenn das Radio aus ist machen können will und sei es nur die Uhr am Laufen zu lassen > Ich wuerde es aber fuer wichtig halten das ein Radio keinen Strom > verbraucht wenn das Auto aus ist. Es gibt ja Leute die benutzen ein > Auto auch mal laengere Zeit nicht. Ja, allerdings kann man den Stromverbrauch wirklich SEHR gering halten. >> * Der Empfang sollte wirklich sehr gut sein. Gutes Groß- und >> Kleinsignalverhalten. > Dir ist klar das dies dann ein hoellischer Aufwand wird wenn du > den Tuner nicht zukaufen willst? Es hat ja Gruende warum auch > gestandene Hersteller von Audio/Videokram Tuner lieber kaufen. Ich hatte beruflich damit zu tun (hab bei einem Tuner IC Semi gearbeitet) und das ist echt kein Hexenwerk. >> * 4 Kanal Verstärker (Evtl. Class-D) > Halte ich nichts von. Gelegenheitshoerer brauchen nur eine Endstufe > fuer zwei Lautsprecher. Die meisten Autos haben 4 Lautsprecher, die möchte ich auch gerne hören können. Zumal es fertige schöne Integrierte Verstärker mit 4 Kanälen gibt, teils sogar direkt mit integrierten Spannungsreglern. > Wer Ansprueche stellt will sowieso mehr > Leistung haben und schliesst dann immer eine externe Endstufe an. > Was du aber unbedingt vermeiden musst sind so miess designte > Rotzkisten die einen eigenen Luefter brauchen und wo schon beim Einbau > klar ist das sie 2-3Jahre spaeter kaputt sind weil dann der Luefter > tot ist und die ELektronik kurz darauf folgt. Man sollte also > nicht viele Waermequellen haben. Ein Lüfter gilt es auf jeden fall zu vermeiden. Wenn es im Auto knallheiß ist, nützt der eh nicht mehr.. > Oh..und Class-D wiederum passt nicht sorecht in deine Wunschliste > mit einem moeglichst guten Tuner. Ist möglich, schon getan, selbst mit guter Empfindlichkeit in den ganzen AM Bändern. Man kann z.b. die Class-D Verstärker abhängig von der getunten Frequenz takten (uC PWM Ausgang). >> * Funktionen sollten leicht erreichbar sein (keine 3 fach >> Shiftfunktionen auf Buttons, etc...) > > Da haette ich kein Problem mit. Es ist einfacher sich drei Belegungen > zu merken, mein Taschenrechner hat IMHO sogar sechs Belegungen, als > jedesmal zu gruebeln in welchem Untermenue irgendeine Funktion jetzt > ist. Du hast doch selbst geschrieben Du willst viele Tasten. > * Die Reaktion auf Benutzerfunktionen sollten schnell erfolgen. > Ist das keine Selbstverstaendlichkeit? Nein, im Zeitalter von > Pfusch und Billig wohl nicht mehr, seufz. Ja, leider. Sowas ist heutzutage absolut nicht (mehr) selbstverständlich. Wenn es z.B. 2 Sekunden (übertrieben) dauert die Wiedergabe von einem MP3 zu starten möchte ich noch immer die Möglichkeit haben auch während dieser 2 Sekunden durch die MP3 Trackliste zu scrollen um mich umzuentscheiden... > Du musst die Hardware modularisieren. Also im Prinzip eine Art kleines > Mainboard mit der CPU. Darauf dann Slots wo man Zusatzkarten > reinsteckt. Ich wäre für ein Basissystem aus: - Tuner - uC - Stromversorgung / Verstärker - Bluetooth slot - mind 1 universeller Erweiterungsslot mit Stromversorgung, interner I2C Bus, I2S, Audio in/out (durchschleifbar), ... > Das haette den Vorteil das du relativ leicht etwas aendern > koenntest ohne jedesmal gleich die gesamte Platine neu machen > zu muessen. Oder glaubst du das dein PCB des Tuners beim ersten > Versuch laufen wird? Ja, das denke ich schon, zumindest in großen Teilen. Optimierungen kann man immer noch vornehmen. Ich hab auch noch kein System gesehen das auf Anhieb 100% lief und man nicht noch irgendwelches HW-patches auf der Platine machen musste. > Ausserdem kann man so den Entwicklungsaufwand > auf mehrere Leute aufteilen. Deswegen mein Aufruf :-) > Dann wollen wir mal nicht vergessen das so ein Project fett ist und > lange dauern wird. Man muss moeglichst schnell zu einer Hardware kommen > mit dem jeder erstmal was rumspielen kann. Genau. 1.) Mechanik klären (Bedienkonzepte, Wie wird es gefertigt...) 2.) Hardware fertig machen, evtl. parallel schon Softwareentwicklung mit testboards o.ä. starten 3.) Software programmieren ... > Ich will dich da nicht missionieren, aber ich hab mir gerade in Japan > mal wieder eine Elektronikzeitung gekauft wo Renesas eine Platine > mitliefert. Da ist eine SuperH-2A CPU drauf SH7262. > Datenblatt ueber 2000Seiten. Speziell fuer Audiodevices gedacht, > SPDIF integriert, I2S integrierst, I2C integriert, CAN, SD-Karte > mit 1Bit und 4Bit integriert, 1MByte internes Ram in der CPU. > AUsserdem Fliesskomma-DSP der sicher genug Power fuer MP3 hat > ohne auch nur einen Muskel anzuspannen. :-) > USB2.0 integriert, DMA, usw usw. Wirf mal einen Blick drauf. Werd ich machen, klingt interessant. Gibt es auch bezugsquellen und nicht-BGA Gehäuse? > Dann mal zu den Kosten. Ich glaube nicht das soetwas unter 500Euro > an Kosten pro Radio machbar ist. Wieviele Leute sind jetzt noch > dabei und nicht in Ohnmacht gefallen? :-) Ich :-) Wäre auch durchaus bereit mehr auszugeben, ist schließlich Hobby... > Ich bin oefter im entfernten Ausland unterwegs und habe keinerlei > Bedarf an deutschen Radiosendern und schon garnicht auf Langwelle > oder Mittelwelle. Pfui Deibel. Die paar Leute die es da noch gibt > sind den Entwicklungsaufwand nicht wert. Gerade in dem Frequenzbereich > hast du doch am ehesten Stoerungen. Selbst die arevierten Hersteller > von Autoradios tun sich damit extrem schwer! > Aber wer das wirklich will kann es sich ja selber nachruesten. > Das ist einer der Gruende warum ich ein Steckkartenprinzip fuer > wichtig halte. Reine FM Tuner sind eh kaum zu finden, dann kann man von mir aus auch noch AM integrieren, OK? :-) Ich hab nur festgestellt das die Antennen, oder deren Verstärker in den Autos heutzutage oft Taub für AM sind. >> Alles was ich so kenne mit Linux arbeitet auch nicht stabil. > Das stimmt so allgemein nicht. Solche Projecte auf Linuxbasis sind > nicht stabil weil dort Linux verwendet wird um sich Arbeit zu sparen. Ich sag ja nicht, das es nicht stabil geht, die Praxis hat mich nur eines anderen belehrt, wie Du es auch schreibst... >> z.B. mein Chumby > Du hast auch einen? Man muss nur die Flashscheisse komplett loeschen > und alles mit Qt programmieren, dann macht das Dingen Spass. .-) Ich wollte einfach nur ein cooles shoutcast Küchenradio haben und nicht noch selber die Software entwickeln :-)
Ich würde auf jeden Fall ein CAN vorsehen, in den ganzen neueren Autos kommen viele benötigte Signale über CAN und nicht mehr diskret. KL S, KL 15, Licht, Geschwindigkeit usw.
Olaf Kaluza schrieb: >> Alles was ich so kenne mit Linux arbeitet auch nicht stabil. > > Das stimmt so allgemein nicht. Solche Projecte auf Linuxbasis sind > nicht stabil weil dort Linux verwendet wird um sich Arbeit zu sparen. > Die klauen sich also ueberrall rumliegende Source zusammen und modeln > da in moeglichst kurzer Zeit was draus zusammen. Das ist einer der > Gruende warum Linux nicht geeignet ist! Diejenigen die das hier > propagieren, wollen sich damit Arbeit sparen und glauben sich so jeden > Firlevanz in das Projekt holen zu koennen. Da kommt dann am Ende > wackeliger Murks raus. Deshalb bin auch ich gegen Linux! > Das passiert bei selbstgestrickter Software ebenfalls, und ist nicht Linux anzulasten, sondern der Sorgfalt bzw. den Fähigkeiten des Anwendungsentwicklers. >> z.B. mein Chumby > > Du hast auch einen? Man muss nur die Flashscheisse komplett loeschen > und alles mit Qt programmieren, dann macht das Dingen Spass. .-) > was hat QT und/oder Flash mit Linux zu tun???? > >> Naja linux wär ned schlecht aber 300MHz und linux + noch ein paar >> Spielereien ? Geht ned. absoluter Blödsinn! Es geht mit deutlich weniger, wenn der Kernel vernünftig auf das absolut notwendige abgespeckt wurde. > > Das ist eine Meinung die ich zu 100% Teile. Und auf meinen Rechner > laeuft zu 99% der Zeit Linux seit 0.95a. .-) > > Jedes Betriebsystem wuerde zuviel Rechenzeit brauche und das > Zeitverhalten komplizieren. Ich weiss man kann das mit viel Aufwand > hinbekommen, aber das was einem Linux schenkt, einfacher Zugriff auf > viele treiber ist unnoetig. Ich brauche auch gewiss kein WLAN im > Auto. Sonst verlange ich als naechstes einen Newserver damit ich > usenet unterwegs lesen kann. > > BTW: Wer sowas sucht soll sich einen Chumby aufs Armaturenbrett > schrauben. Da ist schon alles drin. :-D > So einen Blödsinn liest man sonst nur im Heise-Forum! Warum kaufst du dir nicht ein normales Autoradio, wenn du all die angedachten Inovationen nicht brauchst??? Mir scheint es, als ob du gar nicht wüsstest, was ein Embedded-Linux von einem Desktop-Linux unterscheidet. Ach ja...ich verwende Linux auch seit dem 0.95pl-irgendwas-Kernel. Harry
Wenn MP3 dekodierung + Grafikdisplay und noch so ein paar kleinigkeiten. Da wird dann doch so ein ARM Cortex M3 zu lahm weil dieser schon mit dem MP3 dekodieren und Speicherverhaltung beschäftigt ist (soll ja alles flüssig laufen). Für so sachen wie Geräuschkompensation für die Bluetooth Freisprechanlage is dann der M3 zu lahm. Bei solchen Sachen kommt dann auch schon ARM926 an seine Grenzen. Daher das mit den 300Mhz ggg
> RDS unsinn? Staumeldungen sind doch nicht gerade uninteressant... Soll ich dir was verraten. Ich hab bis vor einem Jahr mit einem Sony Autoradio gehoert das ich mir so um 1985 gekauft habe. (damals 999DM) Erst vor kurzem habe ich modernisiert weil das alte Sony doch etwas in die Jahre kam und ich gerne eine Bluetoothverbindung mit meinem Handy wollte. Und seitdem muss ich mich immer ueber den modernen Kram aufregen, seufz. Daher brauch ich kein RDS. Ich kenn die Frequenzen der Radiosender auswendig und das reicht mir. Und Staumeldungen interessieren mich auch nicht. Nicht das ich sowas fuer mich ein Ausschlusskriterium waere, aber ich messe dem halt selber keinen Wert zu. > machen können will und sei es nur die Uhr am Laufen zu lassen Die muss dann aber abschaltbar sein da ich es auch nervig finde wenn man eine Uhr im Auto hat (normalfall) und dann noch eine im Radio. Und dann noch eine am Arm und dann noch eine im Handy. Und dann kommt der Supergau (Sommerzeit) > Wenn es z.B. 2 Sekunden (übertrieben) dauert die Wiedergabe von einem > MP3 zu starten möchte ich noch immer die Möglichkeit haben auch während > dieser 2 Sekunden durch die MP3 Trackliste zu scrollen um mich > umzuentscheiden... Nein, argh! Er hat es gesagt. Mein Blutdruck..oh Gott.... Mein aktuelles Luxusradio braucht jedesmal echte 20-30s, also gefuehlte 1000Jahre wenn man auf DVD schaltet, und zwar JEDESMAL nicht nur wenn man die DVD wechselt. Und es gibt nur eine Taste um zwischen Radio, DVD, USB-Stick, Handy, HandyAudio und Aux umszuschalten. Also jedesmal einmal die ganze Reihe durch. Wenn eines Tages mal die Entwicklungsabteilung von JVC brennt dann bin ich der Hauptverdaechtige.... > Ich wäre für ein Basissystem aus: > - Tuner > - uC > - Stromversorgung / Verstärker > - Bluetooth slot > - mind 1 universeller Erweiterungsslot mit Stromversorgung, interner I2C > Bus, I2S, Audio in/out (durchschleifbar), ... Ich wuerde den Tuner auch auslagern wollen, aber wenn du sagst du bekommst das so hin ohne allzu viele Muster zu verhauhen. <BG> Ist vermutlich fuer die Anbindung der Antenne besser wenn es nicht ueber einen Stecker laeuft. Anonsten denke ich das man mehre Slots fuer Erweiterungen haben sollte. Wenigstens drei. Zumindest einer, besser alle sollten auch eine Verbindung zum Anschluss an der Rueckwand haben. > Werd ich machen, klingt interessant. Gibt es auch bezugsquellen und > nicht-BGA Gehäuse? http://shop.cqpub.co.jp/hanbai/books/MIF/MIF201006l.jpg Hmm..ich hab obige Zeitschrift gekauft. Da ist die Platine mit dabei. Das Dingen ist in einem 176Beinigen Standardgehaeuse. Leider ist meine nicht angetraute Uebersetzerin etwas zickig wenn es an die Uebersetzung von Texten geht die sie nicht versteht. :-D Aber soweit ich das bis jetzt verstanden habe hat das Teil fuer die meisten Leute hier einen dicken Nachteil so toll es sonst auch sein mag. Zum brennen benoetigt man normalerweise einen Renesas E10 Debugger. Weil den auch in Japan nicht jeder Bastler hat, haben die sich von der Zeitung etwas einfallen lassen. Auf dem Board ist ein Programm drauf das sich mit dem PC und der Entwicklungsumgebung von Renesas ueber USB unterhaelt. Der Prozessor selber enthaelt uebrigends kein Flashrom! Er liesst beim einschalten sein Programm aus einem externen seriellen 8Beiner in sein 1MByte Ram ein und startet es dann. Ich vermute mal das Flashrom zu langsam ist um bei der Geschwindigkeit noch mithalten zu koennen. Das laeuft also im Prinzip so wie bei einem FPGA Jedenfalls ist das ganze relativ aufwendig in Betrieb zu nehmen. Im Prinzip koennte man nur die japanische Loesung kopieren wenn man den Debugger verwenden will und darauf wuerde ich nur ungern verzichten. Ich weiss jetzt nicht wie die Programmiergeraete fuer die hier sonst vorgeschlagenen CPUs aussehen. Fuer Nichtprogrammierer ist das ja kein Problem, da ich denke mit das erste das man programmieren muesste ist ein Firmwareloader der ein Update ueber USB hinbekommt damit man sein System auch im Auto updaten kann ohne dort jedesmal mit dem Laptop rumhampeln zu muessen. > Ich hab nur festgestellt das die Antennen, oder deren Verstärker in den > Autos heutzutage oft Taub für AM sind. Das meinte ich. Und ich glaube das war auch noch nie wirklich gut. Andererseits ist B.Kainka ja ein Freund von mir und der freut sich immer wenn er ein AM-Radio bauen darf. Ich muss ihm nur klarmachen das er diesmal keine Roehre verwenden darf! :-D > Ich wollte einfach nur ein cooles shoutcast Küchenradio haben und nicht > noch selber die Software entwickeln :-) Das ist doch total verschwendet. Das Dingen soll mein neuer Laborrechner werden. I2C-Zugriff geht mit Testprogramm schon. Fehlt nur noch die GPIB Anbindung und ich kann mein Oszi ueber WLAN Fernbedienen. Olaf
seennoob schrieb: > Wenn MP3 dekodierung + Grafikdisplay und noch so ein paar kleinigkeiten. > Da wird dann doch so ein ARM Cortex M3 zu lahm weil dieser schon mit dem > MP3 dekodieren und Speicherverhaltung beschäftigt ist (soll ja alles > flüssig laufen). > Für so sachen wie Geräuschkompensation für die Bluetooth > Freisprechanlage is dann der M3 zu lahm. Bei solchen Sachen kommt dann > auch schon ARM926 an seine Grenzen. Daher das mit den 300Mhz *ggg* Warum sollte das denn alles die Haupt-CPU machen? MP3-Decoder gibt es als 1-Chip Lösung....Bluetooth-Freisprechen wird es sicherlich auch als fertigen Chip oder Modul geben. Ein Grafik-Display in einem DIN-Schacht kann auch nicht so riesig werden, daß eine aktuelle CPU da ins straucheln käme, und 3D brauch ich nicht wirklich. Harry
Eine Sache noch für die Wishlist: DCF77-Empfänger mit automatischer Umstellung Sommer-/Winterzeit Dass sowas bei einem Auto BJ 2009 nich Standard ist, ist mir ein Rätsel... VG
> Soll ich dir was verraten. Ich hab bis vor einem Jahr mit einem Sony > Autoradio gehoert das ich mir so um 1985 gekauft habe. (damals 999DM) Wow, in der Zeit wurden mir 2 Radios geklaut :-) > Daher brauch ich kein RDS. Ich kenn die Frequenzen der Radiosender > auswendig und das reicht mir. Und Staumeldungen interessieren mich auch > nicht. Nicht das ich sowas fuer mich ein Ausschlusskriterium waere, > aber ich messe dem halt selber keinen Wert zu. Es gibt einige Gegenden in Deutschland das willst Du ohne RDS-Follow me nicht freiwillig Radio hören. Wenn man dann noch über dual tuner Konzepte mit RDS basiertem frequency diversity nachdenkt dann kann man (mit etwas fleissarbeit) echt gute Empfangsqualitätsverbesserungen (tm) erreichen. > Die muss dann aber abschaltbar sein da ich es auch nervig finde wenn man > eine Uhr im Auto hat (normalfall) und dann noch eine im Radio. Und dann > noch eine am Arm und dann noch eine im Handy. Und dann kommt der > Supergau (Sommerzeit) Die im Radio würde zumindest automatisch upgedatet werden (RDS). > Nein, argh! Er hat es gesagt. Mein Blutdruck..oh Gott.... Sorry, es tut mir Leid ;-) Wenn ich sowas lese dann frag ich mich immer wie es möglich ist das Entwickler so wenig Enthusiasmus und Energie in Ihre Produkte setzen, wenigstens wenn es um Consumer Produkte geht. > Ich wuerde den Tuner auch auslagern wollen, aber wenn du sagst du > bekommst das so hin ohne allzu viele Muster zu verhauhen. <BG> Ist > vermutlich fuer die Anbindung der Antenne besser wenn es nicht ueber > einen Stecker laeuft. Habe vertrauen, das klappt schon :-) > Anonsten denke ich das man mehre Slots fuer Erweiterungen haben sollte. > Wenigstens drei. Zumindest einer, besser alle sollten auch eine > Verbindung zum Anschluss an der Rueckwand haben. Ja, evtl. ähnlich den PCI slots. > Der Prozessor selber enthaelt uebrigends kein Flashrom! Er liesst beim > einschalten sein Programm aus einem externen seriellen 8Beiner in > sein 1MByte Ram ein und startet es dann. Ich vermute mal das Flashrom zu > langsam ist um bei der Geschwindigkeit noch mithalten zu koennen. Das > laeuft also im Prinzip so wie bei einem FPGA Ja, das ist man sonst auch von vielen DSPs gewohnt. > Ich weiss jetzt nicht wie die Programmiergeraete fuer die hier sonst > vorgeschlagenen CPUs aussehen. Für denjenigen der erstmal die Harte Arbeit macht ein Grundgerüst an Software ans laufen zu kriegen reicht ein FTDI basierter Jtag debugger (z.B. Olimex OCD), ansonsten bringen z.B. die NXP LPCs fast alle einen UART basierten Bootloader mit der prima klappt und selbst für die meisten Softwareentwickler reicht (einen guten Debugoutput vorrausgesetzt). > Fuer Nichtprogrammierer ist das ja kein Problem, da ich denke mit das > erste das man programmieren muesste ist ein Firmwareloader der ein > Update ueber USB hinbekommt damit man sein System auch im Auto updaten > kann ohne dort jedesmal mit dem Laptop rumhampeln zu muessen. ACK! > Das ist doch total verschwendet. Das Dingen soll mein neuer Laborrechner > werden. I2C-Zugriff geht mit Testprogramm schon. Fehlt nur noch die GPIB > Anbindung und ich kann mein Oszi ueber WLAN Fernbedienen. Naja, warum nicht einfach ein GPIB interface mit USB Schnittstelle basteln/kaufen und die energie in ein cooles Autoradio stecken? :-)
Florian Th. schrieb: > DCF77-Empfänger mit automatischer Umstellung Sommer-/Winterzeit > Dass sowas bei einem Auto BJ 2009 nich Standard ist, ist mir ein > Rätsel... Über RDS wird die Uhrzeit, Datum und Zeitzone des Senders ausgesendet (ClockTime), zumindest bei den überregionalen sendern. Man braucht für eine aktuelle Uhrzeit also keine extra Hardware. Die Umstellung auf Sommer/Winterzeit geht darüber auch automatisch.
Kai G. schrieb: > Über RDS wird die Uhrzeit, Datum und Zeitzone des Senders ausgesendet > (ClockTime), zumindest bei den überregionalen sendern. Dann hab ich nix gesagt ;-)
Ich bin ein absoluter feind von diesen "Ein Chip MP3 dekoder" weil sie schluss und endlich zum Flaschenhals werden. Es soll ja eine Basisplatform werden welche ein guter Anlaufpunkt für einen eigenen Radio ist! Also lieber eine eigene DSP für das Audiozeugs, dann kann man sie auch auf andere Formate erweitern. Warum redet jeder immer von einer fertigen Lösung ? Das Gehäuse ist ja nur ein "Nebenprodukt". Zuerst geht es mal darum eine HW zu entwickeln das Gehäuse ist Schluss und endlich jedem selbst überlassen. Ein DIN Referenzdesign ist ned schlecht aber man muss sich ja ned darauf versteifen.
seennoob schrieb: > Ich bin ein absoluter feind von diesen "Ein Chip MP3 dekoder" weil sie > schluss und endlich zum Flaschenhals werden. Es soll ja eine > Basisplatform werden welche ein guter Anlaufpunkt für einen eigenen > Radio ist! > Also lieber eine eigene DSP für das Audiozeugs, dann kann man sie auch > auf andere Formate erweitern. ACK! ...aber bitte nicht die Haupt-CPU mit Aufgaben zumüllen, für die sie eigentlich nicht gemacht ist. > Warum redet jeder immer von einer fertigen Lösung ? Das Gehäuse ist ja > nur ein "Nebenprodukt". Zuerst geht es mal darum eine HW zu entwickeln > das Gehäuse ist Schluss und endlich jedem selbst überlassen. Ein DIN > Referenzdesign ist ned schlecht aber man muss sich ja ned darauf > versteifen. weil hier viele "Träumer" sind, die ein cooles Radio haben wollen, aber von den eigentlichen Problemen bei der Entwicklung keinen Schimmer haben. Harry
Harald L. schrieb: >> Ich bin ein absoluter feind von diesen "Ein Chip MP3 dekoder" weil sie >> schluss und endlich zum Flaschenhals werden. Es soll ja eine >> Basisplatform werden welche ein guter Anlaufpunkt für einen eigenen >> Radio ist! >> Also lieber eine eigene DSP für das Audiozeugs, dann kann man sie auch >> auf andere Formate erweitern. > ACK! Auch ACK. Das entkoppelt auch schön die Softwareentwicklung. Irgendwelche Vorschläge was für ein DSP/Controller? Schön fänd ich - Firmware upload über Hauptcontroller möglich (Damit man immer nur 1 Firmware image hat und keine komischen Versionskonflikte bekommt) - Kein externer Ram/Flash - Kein BGA Ich hätte erstmal nen Arm genommen, aber so richtig das wahre ist das nicht wenn man vorhat wirklich nur reines Signalprocessing zu machen. Aber bevor man irgendeinen exotischen DSP nimmt...
Das ist das Anfägerproblem! Man sieht das etwas voran geht aber man ist sich nicht bewusst das man in der Kindergartenliga arbeitet. Viele denken sich hmm Display haben ich schon angesteuert ist ned viel dabei und MP3 codecs gibts fertig also doch kein so großes Problem so ein MP3 Player! Wenn man aber erst mal das ganze wo neuimplementiert, wirds anstrnegend. Also sowas wie OMAP da kann man sich auch mit den Entwicklern vom Beagleboard zusammensetzen. Dann hat man schon mal ein gutes Hardware Grundgerüst und dann gehts weiter.... MFG Patrick
seennoob schrieb: > Das ist das Anfägerproblem! Man sieht das etwas voran geht aber man ist > sich nicht bewusst das man in der Kindergartenliga arbeitet. Viele > denken sich hmm Display haben ich schon angesteuert ist ned viel dabei > und MP3 codecs gibts fertig also doch kein so großes Problem so ein MP3 > Player! Hey, Kindergartenliga hab ich mal überhört ;-) Ich hab fast all das hier schon mal realisiert (auch from scratch) und bin mir durchaus der Komplexität bewusst.
> Das Gehäuse ist ja nur ein "Nebenprodukt". Das ist es leider nicht. Oder sagen wir mal so, das ist es bei vielen Bastlern schon und genau so sehen dann aber die Kisten aus! > Zuerst geht es mal darum eine HW zu entwickeln > das Gehäuse ist Schluss und endlich jedem selbst überlassen. Ein DIN > Referenzdesign ist ned schlecht aber man muss sich ja ned darauf > versteifen. Das ist natuerlich auch eine Loesung. Haette ich auch kein Problem mit. Wuerde aber wohl wieder einige Leute abschrecken. Schliesslich muesste dann ja jeder die endgueltige Platine passend zu seinem Gehaeuse anpassen. Mir ist gerade noch was zum Bedieninterface eingefallen das ich mal zur Diskussion stellen wollte. Man nimmt ein Encoder mit integrierter Taste auf der einen Seite um sich damit durch die Menues zu arbeiten, auf der anderen Seite kommt ein Motorpoti. So kann man dann z.b Lautstaerke ganz normal mit dem Poti einstellen und sie vor allem absolut-winkelabhaengig veraendern. Und wenn man jetzt im Menue auf Bass oder Fader schaltet dann dreht das Radio den Knopf schnell auf die aktuelle Ist-Position bevor man einen neuen Sollwert durch drehen einstellt. BTW: Wie gross, von den Massen her muesste das LCD eigentlich sein. Mein aktuelles Radio hat ein LCD fast so gross wie die Front weil es darauf auch Video darstellen kann. Da aber niemand im Auto Videos kucken will und hier auch noch keiner darueber gesprochen hat, gehe ich mal davon aus das dies nicht gewuenscht ist. Dann sollte doch eigentlich auch ein kleineres LCD reichen. So haette man vielleicht unter dem LCD Platz fuer eine Reihe von Knoepfen zur Direktanwahl von Senderspeichern und aehnlichem. > weil hier viele "Träumer" sind, die ein cooles Radio haben wollen, aber > von den eigentlichen Problemen bei der Entwicklung keinen Schimmer > haben. Meine Berufserfahrung als Hardwareentwickler sagt mir aber das da die Probleme liegen. Du kannst niemanden anrufen und sagen das du 10000Stk Bleche gelasert und gebogen haben willst. Wenn du sagst du brauchst nur 10Stk dann lacht der dich aus. Und alles was bei einen normalen Autoradio aus Spritzguss besteht kannst du auch vergessen. Du kannst vielleicht noch eine Aluplatte fraesen lassen, bekommst sie irgendwo eloxiert und kannst sie eventuell noch mir siebdruck beschriften lassen. Aber auch das sieht dann mehr nach einem Labornetzteil von Conrad als nach einem Autoradio aus. Es waer doch irgendwie doof wenn man sich erst die ganze Arbeit macht, dann ein Referenzdesign im Form einer Europlatine auf dem Tisch liegen hat und dann darauf stoesst das man es nirgendwo einbauen kann das einen WAF groesser 0.1 hat. Olaf
@darkover Wenn mal alles läuft kann man noch immer an einem Gehäuse arbeiten, außerdem wer will etwas kaufen was schön ist aber noch ned funktionsfähig ? MFG
> Man nimmt ein Encoder mit integrierter Taste auf der einen Seite um sich > damit durch die Menues zu arbeiten, auf der anderen Seite kommt ein > Motorpoti. So kann man dann z.b Lautstaerke ganz normal mit dem Poti > einstellen und sie vor allem absolut-winkelabhaengig veraendern. Und > wenn man jetzt im Menue auf Bass oder Fader schaltet dann dreht das > Radio den Knopf schnell auf die aktuelle Ist-Position bevor man einen > neuen Sollwert durch drehen einstellt. Eigentlich nicht schlecht. Man raubt sich nur die möglichkeit den linken Knopf für etwas komplett anderes benutzen zu können (Menüscrollen). Aber die Frage ist natürlich ob man das überhaupt wollte. Ein gutes Bedienkonzept zu haben ist wohl mit eines der wichtigsten Dinge, weil davon viele andere entscheidungen abhängen. > BTW: Wie gross, von den Massen her muesste das LCD eigentlich sein. Mein > aktuelles Radio hat ein LCD fast so gross wie die Front weil es darauf > auch Video darstellen kann. Da aber niemand im Auto Videos kucken will > und hier auch noch keiner darueber gesprochen hat, gehe ich mal davon > aus das dies nicht gewuenscht ist. Dann sollte doch eigentlich auch ein > kleineres LCD reichen. So haette man vielleicht unter dem LCD Platz fuer > eine Reihe von Knoepfen zur Direktanwahl von Senderspeichern und > aehnlichem. Ich schmeisse hier mal so ca. 10 * 3cm in den Raum mit der Bitte um Kommentare :-) > Meine Berufserfahrung als Hardwareentwickler sagt mir aber das da die > Probleme liegen. Du kannst niemanden anrufen und sagen das du 10000Stk > Bleche gelasert und gebogen haben willst. Wenn du sagst du brauchst nur > 10Stk dann lacht der dich aus. Und alles was bei einen normalen > Autoradio aus Spritzguss besteht kannst du auch vergessen. Ist das nicht so in etwa dasselbe Problem das Mechaniker haben wenn Sie über Elektronik sprechen, weil Sie einfach nicht die Möglichkeiten kennen. Ich gehe davon aus das es nicht so teuer ist eine Frontplatte fräsen zu lassen. Evtl. findet sich hier sogar jemand der eine Fräse hat und sich zutraut eine "Kleinserie" zu machen. Schöne Dreh- und Druckknöpfe die auch nicht so aussehen als ob man sie aus dem letzten Elektor selbstbauprojekt entwendet hat findet man zuhauf bei Farnell und Co., wenn man will sogar mit mehrfarh LEDs beleuchtete... Wie es hinten aussieht ist recht egal, solange es mechanisch stabil ist. Man kann auch z.B. ein paar mm dicke Aluminiumteile nehmen die man auf Länge sägt und an die Platine und untereinander verschraubt. > Du kannst vielleicht noch eine Aluplatte fraesen lassen, bekommst sie > irgendwo eloxiert und kannst sie eventuell noch mir siebdruck > beschriften lassen. Aber auch das sieht dann mehr nach einem > Labornetzteil von Conrad als nach einem Autoradio aus. Klar, es sollte schon nach etwas aussehen, allerdings möchte ich auch nicht unbedingt das es wie das letzt 5 farb China Transformer radio aussieht, sondern dezent bleibt, so wie mein altes Becker Radio.
> Aber bevor man irgendeinen exotischen DSP nimmt... Ich denke die Auswahl des Prozessors muss ueber die Entwicklungsumgebung erfolgen. Soll heissen es muss da was fuer umsonst geben. Schliesslich will hier wohl kaum einer erstmal ein paar kEuro nur dafuer ausgeben. Und nach meinem Kenntnisstand sieht es da fuer die meisten (alle?) DSPs schlecht aus. Vermutlich ist es da wirklich am besten wenn man mehrere Prozessoren nimmt. Sozusagen multitastking fuer Anfaenger. :-) > Ich hab fast all das hier schon mal realisiert (auch from scratch) und > bin mir durchaus der Komplexität bewusst. Ich auch, allerdings fuer Messgeraete und nicht fuer Autoradios. Daher meine Paranoia bei der Mechanik. Ich weiss halt wo die Probleme bei kleinen Stueckzahlen liegen. Dafuer musste ich noch nie einen Gedanken daran verschwenden ob ein Platine jetzt einen Euro teurer ist oder nicht. :-P > - Kein externer Ram/Flash Das ist in der Tat nicht so schoen weil es Platz braucht und mehr EMV erzeugt. Ich sehe aber keinen weg daran vorbei. Wenn man wirklich mit Audiodaten rumspielen will dann braucht man mehr als 10k Ram. Und wenn hier Leute das Inhaltsverzeichnis dicker SD-Karten einlesen wollen dann braucht auch das seinen Platz. Es ist ja kein Zufall das der von mir erwaehnte Audioprozessor von Renesas soviel internes Ram hat. Die haben sich da schon was bei gedacht. Schaut euch doch mal das Datenblatt an... http://www.renesas.com/products/mpumcu/superh/sh7260/sh7262/sh7262_root.jsp Wie gesagt, ich will den hier keinen aufschwatzen, dazu kenn ich das Teil selbst zu wenig. Aber man bekommt schonmal einen ungefaehren Eindruck was man so braucht. Denn die Teile sind ja fuer Grossserie gedacht. Da ist nicht ein Stueck mehr Silizium drin als man braucht weil das sonst nur unnoetig Geld kostet. Olaf
Olaf Kaluza schrieb: > Mir ist gerade noch was zum Bedieninterface eingefallen das ich mal zur > Diskussion stellen wollte. > > Man nimmt ein Encoder mit integrierter Taste auf der einen Seite um sich > damit durch die Menues zu arbeiten, auf der anderen Seite kommt ein > Motorpoti. So kann man dann z.b Lautstaerke ganz normal mit dem Poti > einstellen und sie vor allem absolut-winkelabhaengig veraendern. Und > wenn man jetzt im Menue auf Bass oder Fader schaltet dann dreht das > Radio den Knopf schnell auf die aktuelle Ist-Position bevor man einen > neuen Sollwert durch drehen einstellt. > > BTW: Wie gross, von den Massen her muesste das LCD eigentlich sein. Mein > aktuelles Radio hat ein LCD fast so gross wie die Front weil es darauf > auch Video darstellen kann. Da aber niemand im Auto Videos kucken will > und hier auch noch keiner darueber gesprochen hat, gehe ich mal davon > aus das dies nicht gewuenscht ist. Dann sollte doch eigentlich auch ein > kleineres LCD reichen. So haette man vielleicht unter dem LCD Platz fuer > eine Reihe von Knoepfen zur Direktanwahl von Senderspeichern und > aehnlichem. öh, bis auf das Motorpoti beschreibst Du damit doch gerade das Becker-Design was Du oben noch verschmäht hattest...oder? jedenfalls geht das ziemlich in die gleiche Richtung wie das Bedienkonzept was ich mir vorstellen würde ;-) denke gerade z.B. an ein Becker Mexico Pro, das hat in der Mitte ein relativ großes Pixeldisplay, je einen Drehencoder rechts (Menüs) und links (Lautstärke), darunter 10 Tasten die je nach Betriebsart belegt sind und darüber ein paar um Quellen umzuschalten usw. > Es waer doch irgendwie doof wenn man sich erst die ganze Arbeit macht, > dann ein Referenzdesign im Form einer Europlatine auf dem Tisch liegen > hat und dann darauf stoesst das man es nirgendwo einbauen kann das einen > WAF groesser 0.1 hat. sehe ich auch so. Das Gehäuse muss natürlich nicht als erstes fix und fertig sein, aber ich wüsste zumindest gerne vorher schon dass überhaupt die Chance besteht etwas ansprechendes hinzubekommen. Ich selbst hätte da nämlich wenig Möglichkeiten. Für meinen MP3-Player damals hab ich ein Gehäuse bei Schaeffer fräsen lassen, aber der ist auch nicht sichtbar montiert. Dafür ist das noch ok, aber im Armaturenbrett?? ich weiß nich so recht...
Ich sehe gerade die Vorteile eines Motorpotis ggü. einem Inkrementalgeber nicht. Kann mich kurz jemand aufklären?
Tobi schrieb: > Ich sehe gerade die Vorteile eines Motorpotis ggü. einem > Inkrementalgeber nicht. Kann mich kurz jemand aufklären? Die Relation zwischen Position des Potis und Lautstärke/Bass/... ist absolut und nicht relativ. Ausserdem hat man einen Anschlag => bis zum Anschlag nach links drehen = ganz leise.
> Ich gehe davon aus das es nicht so teuer ist eine Frontplatte > fräsen zu lassen. Das haengt von der Maschinenlaufzeit ab. Ausserdem auch von so Details ob man umspannen muss oder wieviele unterschiedliche Fraeser man braucht. Und natuerlich ganz entschieden von der Stueckzahl. Du hast relativ hohe Einricht/Programierkosten. Ich wuerde mal schaetzen das eine Frontplatte mit eloxieren und siebdruck irgendwo zwischen 100 und 200Euro liegen duerfte wenn du mindestens 10Stueck abnimmst. Aber das ist eine Schaetzung und ich kann da auch schnell danebenliegen. Und nebenbei gesagt, die weisst nicht wie oft man bei der 0-Serie erleben kann das da was schiefgeht. Was das selbermachen angeht habe ich so meine bedenken. Ich habe eine Fraese (nur Handbetrieb, Proxxon-Level) zuhause (bin ja nicht nur ET-Ing sondern noch Schlosser, da braucht man das <BG>) Ich weiss nicht ob man da vernueftige Oberflaechengueten hinbekommt. Aber immerhin koennte ich vernuenftige 3D-CAD Zeichnungen erstellen. Olaf
>Ich sehe gerade die Vorteile eines Motorpotis ggü. einem >Inkrementalgeber nicht. Kann mich kurz jemand aufklären? Es ging dabei (wurde weiter oben genannt) um die Absolutposition des Stellers. Da könnte man eher einen Slider auf einem Touchscreen basteln... Ich hätte hier noch ein Ford-Cassetten-Radio abzugeben... ;-)
> Da könnte man eher einen Slider auf einem Touchscreen basteln...
NEIN! Genau das will man nicht haben. Du kannst kein Touchscreen
bedienen ohne draufzuschauen und wenn ich Autofahre dann schaue ich
lieber auf die Strasse.
Es ist okay wenn seltene Sachen wie z.b das einprogramieren eines neuen
Senders etwas komplizierter sind, aber Sachen die man bei der Fahrt
aendern will muessen ganz einfach und mit taktiler Rueckmeldung
geschehen.
Olaf
Olaf Kaluza schrieb: > Es ist okay wenn seltene Sachen wie z.b das einprogramieren eines neuen > Senders Das geht ja nun tierisch einfach, einfach die gewünschte Stationstaste lange drücken. Sofern es Stationstasten gibt... > etwas komplizierter sind, aber Sachen die man bei der Fahrt > aendern will muessen ganz einfach und mit taktiler Rueckmeldung > geschehen. Aber will man den Bass-Level/Höhen/ähnliches während der Fahrt ändern? Lautstärke okay, aber das Ergebnis hört man ja.
>Die Relation zwischen Position des Potis und Lautstärke/Bass/... ist >absolut und nicht relativ. Ausserdem hat man einen Anschlag => bis zum >Anschlag nach links drehen = ganz leise. Das wäre sinnvoll, wenn der Knopf eine Skala hätte, die man während des Einstellens abliest. Bei Dingen wie Lautstärke, Bass usw. sind absolute Werte aber eher uninteressant. Ich höre ja das Ergebnis während des Einstellens - dazu brauche ich kein taktiles oder optisches Feedback.
Olaf Kaluza schrieb: >> Ich gehe davon aus das es nicht so teuer ist eine Frontplatte >> fräsen zu lassen. > > Das haengt von der Maschinenlaufzeit ab. Das hängt vor allem von den Ansprüchen ab, die man ans Design hat. Eine gefräste Fromtplatte von schaeffer-apparatebau.de kostet in der Größe tatsächlich nur ein paar Euro - und sieht dann aus, wie Apparatebau. Wenn dann die Frontplatte mal da ist, braucht es auch noch Knöpfe, für manchen hier möglichst viele. Wer schonmal versucht hat, so etwas anderes als 70er-Jahre-Hameg-Oszi-Design zu bekommen, weiß, was das bedeutet: Gibts nicht. Entweder auch aus dem vollen fräsen, oder in 1000 Stückzahlen in Kunststoff anfertigen lassen. Daher kommt der nicht ganz unvernünftige Vorschlag, alles per touchscreen zu lösen. Ist zwar von der Bedienung her scheixxe, vereinfacht dafür die Mechanik und damit die Probleme einer Realisierung ganz erheblich. Aber der Trend geht ja zur Zeit eher zur universell verwendbaren modularen Hardwareplattform, die das Gehäuse als kleines Problemchen dem Einzelnutzer überlässt. Mein Vorschlag dazu wäre dann noch ein Emulator für den PC, dann kann man das alles virtuell laufen lassen (als Real-Player-Alternative). Oliver
Wir haben aber schon festgestellt das so ein Radio einiges an Kosten bedeutet und ohne Zweifel noch mehr an Arbeit. Sowas wird man, ich auf jedenfall, dann sicher fuer viele Jahre verwenden. Und ich moechte nicht die naechsten 10 Jahre auf Schaeffer Apparatebau kucken. Und ich moechte mich auch nicht 10Jahre mit einem TouchLCD rumaergern! Wenn ich mich aergern will kann ich auch bei meinem aktuellen Radio bleiben. Ich will etwas das zum vornehmen Ambiente meines Lancia Kappa passt [mit Fuss aufstampf] :-) BTW: Wie lange haelt so ein TouchLCD eigentlich? Noch dazu in einem Auto wo es im Sommer auch mal 60Grad und im Winter -20 haben kann? Nachdem was ich so bei Palmpiloten beobachten konnte ist gerade die Touchfolie immer der Grund fuer den Muelleimer. Bei Handys die eh alle zwei Jahre weggeworfen werden natuerlich kein Problem. Und man muss natuerlich ein Display haben das fuer den Temperaturbereich im Auto geeignet ist. Olaf
Hallo,
ich habe zwar keinen Bedarf nach einem neuen Autoradio, aber vielleicht
solltet Ihr das Projekt in verschiedene Teilprojekte aufteilen, so dass
sich Leute gezielt den jeweiligen Gruppen zuordnen können.
- Gehäuse (DIN-Schacht, Frontpanel, Display, Knöpfe)
- Hardware (Basisplatine, Anbindung I/O, Erweiterungskarten)
- Software (Linux, Anwendungen)
Damit das Ganze nicht in zwei Monaten wieder vergessen ist, wird
man auch nicht drumherum kommen, ein bisschen was schriftlich
festzuhalten.
Gruss
Micha
PS: Wenn, dann würde ich auf jeden Fall was Linux-basiertes nehmen.
Micha C. schrieb: > Damit das Ganze nicht in zwei Monaten wieder vergessen ist, wird > man auch nicht drumherum kommen, ein bisschen was schriftlich > festzuhalten. > Das seh ich genauso! ich währe bereit, ein Wiki dafür einzurichten, falls Interesse besteht. Harry
Harald L. schrieb: > Das seh ich genauso! > ich währe bereit, ein Wiki dafür einzurichten, falls Interesse besteht. Wenn Dir das einfach von der Hand geht und nicht zu umständlich ist, sehr gerne. Das ich mit Webservern und co hantiert habe ist ein paar Jahre her und würde sicher 2* so lange dauern als wenn es jmd. macht der ein bißchen "fitter" ist. Wenn nötig, kann ich Dir auch gerne einen Zugang zu meinem momentan ungenutzten webserver geben, hätte noch ne MySQL Datenbank und ne Menge webspace "frei".
Kai G. schrieb: > Harald L. schrieb: >> Das seh ich genauso! >> ich währe bereit, ein Wiki dafür einzurichten, falls Interesse besteht. > > Wenn Dir das einfach von der Hand geht und nicht zu umständlich ist, > sehr gerne. > Das ich mit Webservern und co hantiert habe ist ein paar Jahre her und > würde sicher 2* so lange dauern als wenn es jmd. macht der ein bißchen > "fitter" ist. Geht klar! Mach ich im Lauf des Tages fertig. Heute Abend sollte das laufen. Da du ja der Initiator dieses Projekt bist, richte ich dich da als Admin ein, und schick dir die Zugangsdaten via PN. Harry
Dann sollten wir trotzdem noch eine Seite im Wiki hier platzieren, als Statusseite.
Harald L. schrieb: > Geht klar! > Mach ich im Lauf des Tages fertig. Heute Abend sollte das laufen. > Da du ja der Initiator dieses Projekt bist, richte ich dich da als Admin > ein, und schick dir die Zugangsdaten via PN. Klasse!
Ich bin ja mal gespannt wie viele Leute von denen, die angekündigt haben zu helfen, am Ende tatsächlich mitarbeiten oder sogar investieren. Bis jetzt sieht es ja so aus als könnte man ja mit einer interessanten Idee schnell Leute zusammen trommeln!
Noch was zum vorgeschlagen reneseas controller under development also scheidet schon aus. Aber warum nicht echt einen Prozessor mit CPU + DSP nehmen ?
wäre nett, wenn jemand ein Logo für dieses Projekt entwickeln könnte!!! Harry
Der Link scheint nicht zu funktionieren? Ich finde das Projekt aber sehr interessant! Vielleicht könnte man es auch als normales Radio umfunktionieren? mit freundlichen Grüßen, Valentin Buck
Valentin Buck schrieb: > Der Link scheint nicht zu funktionieren? kann sein, daß die Domain bei deinem Provider noch nicht im DNS-Cache angekommen ist. Die URL hab ich eben erst in den DNS eingetragen. Innerhalb der nä. paar Stunden sollte die Seite allgemein erreichbar sein. Harry
Hallo, Sven schrieb: > Ich bin ja mal gespannt wie viele Leute von denen, die angekündigt haben > zu helfen, am Ende tatsächlich mitarbeiten oder sogar investieren. Bis > jetzt sieht es ja so aus als könnte man ja mit einer interessanten Idee > schnell Leute zusammen trommeln! ja, der Bedarf nach so einem Radio ist offenbar da (und bei dem was so an Fertiggeräten angeboten wird finde ich das nicht sehr überraschend ;-) ) -- nur wie es dann aussieht wenn es an die Umsetzung geht ist natürlich eine berechtigte Frage... Dazu kommen dann noch die verschiedenen Zielsetzungen wie sie hier im Thread ja schon vorkamen: * "erstmal die Hardware ans Laufen bekommen, das Gehäuse wird dann schon" vs. "ohne Gehäuse brauchen wir gar nicht erst anfangen; die restliche Hard- und Software kriegen wir dann schon hin wenn das erstmal steht" * Eierlegende Wollmilchsau mit WLAN und Pipapo oder "nur" ein Radio mit MP3 * und schließlich Linux: ja unbedingt, oder: nein, bloß nicht! die man wohl schwer unter einen Hut bringen kann... Von Fragen wie Touchscreen ja/nein oder Drehencoder/Motorpoti mal zu schweigen, aber sowas ist denke ich auch nicht soo tragisch, ändert ja an der Plattform nicht (viel). Also für mich ist wie gesagt die Mechanik auch erstmal k.o.-Kriterium, da ich da bisher keine brauchbare Lösung kenne. Bei allem weiteren kann man ja dann noch diskutieren, da mache ich mir jedenfalls weniger Sorgen... Gruß, Mathias
@Kai G. (xyphro), noch eine Frage am Rande: kann es sein, dass Du einmal für den Beck IPC@CHIP einen FAT32-Treiber portiert hast, oder verwechsle ich Dich da mit jemand?
DAs Hauptproblem ist glaub ich, aber, dass es bei modernen Autos kaum möglich ist, das Autoradio gegen ein beliebiges auszutauschen, da die so fix integriert sind, dass sie komplett an die Formen der Kosnole angepasst sind und 2. das Display ganz woanders ist als das Radio.
Mathias A. schrieb: > @Kai G. (xyphro), noch eine Frage am Rande: kann es sein, dass Du einmal > für den Beck IPC@CHIP einen FAT32-Treiber portiert hast, oder verwechsle > ich Dich da mit jemand? jep, genau der bin ich :-)
seennoob schrieb: > Hab mal mit den Feautures auf Wiki angefangen. ..und ich hab ein wenig Formatierung hinzugefügt ;) Hier: http://meta.wikimedia.org/wiki/Hilfe:Textgestaltung gibts ne ganz brauchbare Anleitung, wie man den Text formatiert. Harry
seennoob schrieb: > Danke Mysth ich hab zu danken! ;) immerhin bist du der erste, der meine Installation testet. Du willst ja sicher noch mehr dazu beitragen, daher fänd ich es nett, wenn du dich auch als User dort anmelden würdest. (re. oben auf "anmelden" klicken und neuen Account anlegen) Harry
Browser lässt darauf schließen, dass jetzt doch Linux verwendet wird? Eine wie ich finde gute Entscheidung, da es unter anderem dem Hobby-Nutzer die Meisten Erweiterungsmöglichkeiten bietet.
Ich will jedem Hobby Programmierer das Hardware gefrickel ersparen auch wenn das 20% Leistungsverlust bedeutet ! Wenn dann wird was gscheids verbaut sowas in die Richtung OMAP. Wer mich noch die Tage mit der Beagleboard Community zusammenschließen und mal schauen was sie sagen wegen Hardware anpassung usw. Da ist auch Erfahrung da wenns um die Entwicklung von so sachen geht. MFG PAtrick
Olaf Kaluza schrieb: > Andererseits ist B.Kainka ja ein Freund von mir und der freut sich > immer wenn er ein AM-Radio bauen darf. Ich muss ihm nur klarmachen das > er diesmal keine Roehre verwenden darf! :-D Ach, wenn er ein Hybrid-Auto fährt, warum eigendlich nicht ? Beim Prius III die 650 Volt Batteriespannung als Anodenspannung verwendet, da kommt sogar ordentlich Leitung im echten Röhrensound bei raus. Die Ausgangsübertrager könnten etwas schwer werden. 12 Volt zum Heizen (z.B. RV12P2000) sind ja sowieso da... ;-) Man sollte bedenken, daß viele Fahrzeuge über Lenkradbedienungen verfügen, die z.T. unterschiedlich angesprochen werden -> per CAN oder auch spannungscodiert. Bei CAN kommt noch das Problem der unterschiedlichen Identifiers dazu. Möglicherweise ein externes Modul zum Anpassen ? LG Elux
Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel endet. So Sachen wie UMTS und WLAN würde ich auch rauslassen, schließlich soll es ein Autoradio werden und kein mobiles entertainmentsystem. Dann würd ich lieber gleich nen Mini ITX board benutzen...
word! Ich bin auch gerne dabei solch ein radio zu realisieren, aber ohne linux! Auch wenn ich dadurch nie nen browser im radio haben werde. Vielleicht sollten zwei projekte gestartet werden
Linux ist in meinen Augen fast Pflicht. Aber der Kernel muss angepasst werden auf die Anwendung als Radio ! Ein RT-Kernel wär vielleicht ganz cool aber muss nicht sein. Wenns aber Richtung multitasking geht ist Linux die beste Wahl.
seennoob schrieb: > Linux ist in meinen Augen fast Pflicht. Aber der Kernel muss angepasst > werden auf die Anwendung als Radio ! > Ein RT-Kernel wär vielleicht ganz cool aber muss nicht sein. Wenns aber > Richtung multitasking geht ist Linux die beste Wahl. ...den part würde ich gerne übernehmen! Harry
Über die Suche nach einem geeigneten Autoradio-Empänger-IC bin ich auf den TEF6901 (Integrated car radio) von NXP gestossen und auf diesen Thread: http://www.car-pc.info/phpBB2/viewtopic.php?t=22498. Dort ist man seit ca. 1 1/2 Jahren mit einem ähnlichen Projekt beschäftigt. Den TEF6901 gibt es auch auf einer fertigen Platine bei http://www.techdesign.be/projects/041/041.htm für 106€. Ist zwar ne Menge Geld, dafür aber eine sehr gute Lösung. Walter
Ohne Linux kannste aber sowas wie OMAP3 vergessen - sonst ist man ja monatelang damit beschäftigt nur die ganzen Hardwaremodule ans laufen zu bringen. Ist ja schon was anderes als nen AVR oder nen kleiner ARM7... Man könnte ja evtl. ein Basisboard bauen wo man optional nen Beagleboard anschließen könnte ODER alternativ irgendwas anderes ohne Linux. Also einfach alles Modular gestalten - evtl. auch den Audioteil dann kann man das auch leichter upgraden, so wie mans braucht. Nur so ne Idee.
rakkatakka schrieb: > Ohne Linux kannste aber sowas wie OMAP3 vergessen - sonst ist man ja > monatelang damit beschäftigt nur die ganzen Hardwaremodule ans laufen zu > bringen. Ich sag ja auch nicht das man dem OMAP3 nehmen muss. Ein Arm9, nein selbst ein größerer Arm7 würde alle Sachen aus der Feature list erledigen können (OK, jetzt mal echo cancelation aussen vor gelassen). > Also einfach alles Modular gestalten - evtl. auch den Audioteil dann > kann man das auch leichter upgraden, so wie mans braucht. > Nur so ne Idee. Zu Modular ist auch nicht gut, dann brauchst Du für nen Grundsystem mit Basisfunktionen schon 5 Platinen. Daher hatte ich vorgeschlagen ein Grundsystem zu machen mit allen Basisfunktionen für ein Radio + "Erweiterungsslots".
walter schrieb: > Über die Suche nach einem geeigneten Autoradio-Empänger-IC bin ich auf > den TEF6901 (Integrated car radio) von NXP gestossen und auf diesen > Thread: > http://www.car-pc.info/phpBB2/viewtopic.php?t=22498. Dort ist man seit > ca. 1 1/2 Jahren mit einem ähnlichen Projekt beschäftigt. Den TEF6901 > gibt es auch auf einer fertigen Platine bei > http://www.techdesign.be/projects/041/041.htm für 106€. Ist zwar ne > Menge Geld, dafür aber eine sehr gute Lösung. Die TEF690x Reihe ist für low cost Radio gedacht, aber qualitativ echt nicht schlecht. Viele Features von echten Radio DSPs fehlen halt, aber alles was man in einem einfachen Radio braucht ist enthalten. Ich dachte auch von Anfang an an sowas wie den TEF6903. 106 EURO ist echt ein stolzer Preis!!
walter schrieb: > Den TEF6901 gibt es auch auf einer fertigen Platine bei > http://www.techdesign.be/projects/041/041.htm für 106€. Ist zwar ne > Menge Geld, dafür aber eine sehr gute Lösung. Der Chip kostet bei Digikey nur 9,30$. http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=TEF6901AH/V5S,518-ND Und die Platine wollen wir wenn dann ja selber machen. Richtig kompliziert sieht die auch nicht aus.
> Der Chip kostet bei Digikey nur 9,30$. > http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=TEF6901AH/V5S,518-ND > Und die Platine wollen wir wenn dann ja selber machen. Richtig > kompliziert sieht die auch nicht aus. Wenn ich die Platine sehe, bezweifel ich erlich gesagt das viel über das Layout nachgedacht wurde. Ich seh auch nirgendwo Messergebnise (SINAD, Empfindlichkeit, Intermodulation und co.).
Ich bin auf jedem Fall für einen Linuxkernel, würde jedoch Browser, GPS und co weglassen.
Browser halte ich ebenfals für überflüssig, und GPS wäre sogar mit nem ATTiny zu erschlagen ;) Harry
seennoob schrieb: > Wie ist das jetzt zu verstehen ? > > MFG Ich würde mich um den Kernel kümmern. Das Thema ist mir nicht fremd. Harry
> Noch was zum vorgeschlagen reneseas controller under development also > scheidet schon aus. Ich will es nicht ausschliessen, aber die verschenken den hier im Japan als Beigabe zu einem Elektronikheft und es gibt auch bereits einige Applikationen zu diesem Prozessor bei Renesas zum download. Ich glaube nicht das noch viel dran entwickelt wird. Es gibt ausserdem die Entwicklungsumgebung von Renesas mit Compiler von Renesas, nach 60Tagen auf maximal 256k Codegroesse beschraenkt. Und es gibt den gcc auch dafuer. Ich will aber nicht ausschliessen das die Beschaffung in Deutschland schwieriger sein koennte! > DAs Hauptproblem ist glaub ich, aber, dass es bei modernen Autos kaum > möglich ist, das Autoradio gegen ein beliebiges auszutauschen, Das Problem umgehe ich dadurch das ich beim kauf darauf achte das dies bei meinen Autos kein Problem ist! Ansonsten meine ich das das die Protokolle bei ein paar Autos fuer die externen LCDs auch schonmal analysiert wurden. Wer sowas braucht kann es sich dann ja auch nachprogrammieren. > Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt > das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel > endet. Ich ebenfalls! > So Sachen wie UMTS und WLAN würde ich auch rauslassen, Ich auch. Das braucht man in einem Radio nicht. Und es wuerde die Sache nur unnoetig kompliziert machen. > Wenns aber > Richtung multitasking geht ist Linux die beste Wahl. Ich will kein echtes Multitasking in einem System das in Echtzeit Audiodaten verschiebt. Das ist unnoetiger Aufwand! Man kaempft dann an der einen Front mit der Zuverlaessigkeit und an der anderen damit das System ausreichend schnell zu halten damit der Nutzer nicht gaehnen muss. > Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt > das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel > endet. Ich habe noch nie was mit Arm gemacht, in den letzten Jahren nur Renesas, aber wenn die schnell genug sind dann unterstuetze ich das. Im Zweifel lieber das fetteste Teil das man bekommen kann solange es kein BGA ist. BTW: Was ist eigentlich mit dem Prozessor der im Chumby ist? Das ist doch auch ein ARM und ich fand da den integrierte Analogteil und den Spannungswandler ganz interessant. Ich weiss aber nicht wie Motorola so mit Kleinmengen rueberkommt. Glyn/Renesas war da bisher immer sehr entgegenkommend! Ich denke das dieser Prozessor sich um SD-Karte und Audio kuemmern sollte. Fuer die Bedieneinheit sollte es einen zweiten Prozessor geben. So koennte man da halt relativ einfach was umdesignen wenn einer eine andere Front mit einem anderen Interface moechte. Olaf
Aechz! Ich hab mir gerade mal die Featurelist auf der OSCAR Seite durchgelesen. Wenn ihr das alles einbauen wollt dann wird das nie fertig. Das halte ich fuer ein 3-4Personen-basteln-nach-Feierabend Project fuer eine Groessenordnung zu fett. Mich wundert fast das noch keiner eine IRFB haben wollte. War bei meinem aktuellen Autoradio dabei und es gibt fast nichts wobei man sich noch bescheuerter fuehlt als wenn man im Auto 40cm vom Radio entfernt sitzt und das mit einer FB bedient. Aeh..und wo ich schonmal am meckern bin. Was soll denn ein zweites LCD und Spiele? Wenn den Kroeten auf der Ruecksitzbank langweilig ist dann sollen sie halt aus dem Fenster schauen und Nummernschilder zaehlen. Hat fuer uns doch auch gereicht. Und wenn sie meckern dann macht man ihnen klar das dad naechste Auto das Papa sich kauft ein Sportwagen ohne Ruecksitzbank sein koennte. :-) Und wenn ich auf dem Campingplatz ins Internet will dann verbindet sich mein Laptop ueber Bluetooth mit dem Handy in meiner Tasche und auch nur weil mein Laptop schon so alt ist das da kein UMTS eingebaut ist. Aber wegen so einem Firlefanz einen UMTS-WLAn Router entwickeln zu wollen? Da frage ich mich wirklich ober der Wuenscher eine Vorstellung von der Komplexizitaet hat. Olaf
Olaf Kaluza schrieb: > Aechz! Ich hab mir gerade mal die Featurelist auf der OSCAR Seite > durchgelesen. Wenn ihr das alles einbauen wollt dann wird das nie > fertig. Das halte ich fuer ein 3-4Personen-basteln-nach-Feierabend > Project fuer eine Groessenordnung zu fett. Ich habe das ganze mal etwas umgestrickt und ein neuen Unterpunkt "Basis Features" gemacht. Weil ich denke das sich die 2 unterschiedlichen Ansätze sowieso nicht so ohne weiteres unter einen Hut bekommen lassen werden. Diese "Basisfeatures" sind leicht in Hardware implementiert und in Software muss man nicht alles sofort implementieren. z.B. kann man erstmal ein 1 Tuner System nur mit RDS Radiotext und MP3 Wiedergabe bauen und dann Schritt für Schritt erweitern. => Gerne weiter editieren, z.B. features hinzufügen/ändern oder Prioriäten hinzufügen oder so. > Aeh..und wo ich schonmal am meckern bin. Was soll denn ein zweites LCD > und Spiele? Wenn den Kroeten auf der Ruecksitzbank langweilig ist dann > sollen sie halt aus dem Fenster schauen und Nummernschilder zaehlen. Hat > fuer uns doch auch gereicht. Und wenn sie meckern dann macht man ihnen > klar das dad naechste Auto das Papa sich kauft ein Sportwagen ohne > Ruecksitzbank sein koennte. :-) LOL ;-) Meine Eltern hatten mich auch noch mit tollen Spielen wie "zähl mal die roten Autos" beschäftigt und ich hoffe mit unserem kleinen bekommen wir das auch noch auf die Variante hin ;-) > Ich will kein echtes Multitasking in einem System das in Echtzeit > Audiodaten verschiebt. Das ist unnoetiger Aufwand! Man kaempft dann an > der einen Front mit der Zuverlaessigkeit und an der anderen damit das > System ausreichend schnell zu halten damit der Nutzer nicht gaehnen > muss. Man kann noch weiter gehen und sich Fragen ob man überhaupt Tasks und einen Scheduler braucht. Viele Sachen haben schon so harte Echtzeitbedingungen (z.B. RDS) das man mit Tasks schon nicht mehr so ohne weitere arbeiten kann.
Kai G. schrieb: > Dann > würd ich lieber gleich nen Mini ITX board benutzen... Das ist natürlich auch eine Idee, wieso kein x86? Datasheet für Pico-ITX-Board: http://www.spectra.de/produkte/124083/web/spectra/Datasheet-LP-170.pdf Im 3,5"-Format gibts auch einiges. Problematisch stellt sich für mich die Bauteilhöhe (Platz?) und der Preis dar ;)
Olaf Kaluza schrieb: > Mich wundert fast das noch keiner eine IRFB haben wollte. War bei meinem > aktuellen Autoradio dabei und es gibt fast nichts wobei man sich noch > bescheuerter fuehlt als wenn man im Auto 40cm vom Radio entfernt sitzt > und das mit einer FB bedient. Es gibt nix sinnvolleres als eine Fernbedienung. Wenn sie nicht im Lenkrad integriert ist, dann muss es eben eine IRFB sein. Während der Fahrt am Radio rumzuspielen ist kreuzgefährlich, die IRFB bedient man blind und v.a. ohne sich vorbeugen zu müssen. Der Abstand von 40cm ist vollkommen irrelevant.
Dann bevorzuge ich allerdings die Lenkradfernbedienung; die hab ich im aktuellen PKW und möchte sie wirklich nicht mehr missen. Sprich es müsste eine entsprechende Schnittstelle eingeplant werden. IRFB sind meiner Meinung nach obsolet. VG
Kai G. schrieb: > Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt > das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel > endet. Also wir setzen Debian Stable in embedded Systeme bei unseren Kunden ein. Die laufen dort bereits seit Jahren ohne Probleme oder Unterbrüche. Eine Instabilität können wir überhaupt nicht feststellen. Das Basissystem (ohne X-Windows Server) ist extrem stabil und sehr resourcenschonend. Zudem setzen wir Asterisk auf eine angepasste Linux-Distro ein. Die läuft auch schon seit zwei Jahren ohne Unterbruch und steuert alle unsere Telefonate. Ausserdem laufen bei uns im Unternehmen auch alle Router und Telefone unter Linux, bisher auch fehlerfrei. Von Seiten der Wartbarkeit hat sich die Modularität für uns sehr positiv ausgewirkt. An einer grossen monolythischen Firmware ist die Wartung und Pflege eine Sache, die zumeist von einem Spezialisten duchgeführt werden muss, der die gesamte Firmware kennt. Mit modularen Systemen können unterschiedliche Entwickler an verschiedenen Komponenten arbeiten. Aus meiner Sicht spräche aber vor allem der Punkt, dass man auf bereits entwickelte, sehr stabile Komponenten setzen kann und nicht alles neuentwickeln muss, für den Einsatz eines embedded Linux. Zudem können Nutzer recht einfach weitere Komponenten für sich hinzunehmen. Just my 2c. Michael
Reinhard S. schrieb: > Kai G. schrieb: > >> Dann >> würd ich lieber gleich nen Mini ITX board benutzen... > > Das ist natürlich auch eine Idee, wieso kein x86? > > Datasheet für Pico-ITX-Board: > http://www.spectra.de/produkte/124083/web/spectra/Datasheet-LP-170.pdf > > Im 3,5"-Format gibts auch einiges. Problematisch stellt sich für mich > die > Bauteilhöhe (Platz?) und der Preis dar ;) Falls wirklich ein x86, dann würde ich eher ein alix3 (www.pcengines.ch) nehmen. Die Leistung mit 500 MHz reicht allemal aus für selbst die grössten Spielereien. Eine WLAN-Karte kann eingesteckt werden (für die, die das brauchen), und auch eine CF-Karte für die Firmware. Der Stromverbrauch mit 2-5 Watt typ. ist angenehm, ebenso wie der Preis von weniger als 100 Euro. Die Grösse ist deutlich kleiner als Mini-ITX und sollte eigentlich problemlos in den DIN-Rahmen passen.
Soll das ein Car PC werden oder ein Radio? Ich bin auch stark für nen Arm7 oder Arm9 ohne Linux. Für ein richtigen Computer mit WLAN und sonstigem Schnick Schnack reicht's dann natürlich nicht aus. Aber für ein bisschen Radio, USB und sd Karten und mp3 Funktionalität(was wohl sowieso ausgelagert wird) sollte das wohl reichen, oder nicht?
Harald L. schrieb: > Wenn das Auto im Carport steht, kann ich per WLAN & SSH drauf zugreifen, > und an dem System arbeiten. > (Auch hier hilft uns Linux, weil auch SSH hier nicht neu geschrieben > werden muss) > Ach ja....und unterwegs kann darüber in Verbindung mit dem Mobiltelefon > der Stick als AP arbeiten, und man kann per Laptop ins Netz. Und während der Fahrt kann das AR mit seinesgleichen Musikdateien tauschen, mit anderen Fahrzeugen in der Nähe eine VoIP-Verbindung aufbauen, um sich gegenseitig mal so richtig anschnauzen zu können ;-), während Staus kann man damit Nothilfe an Verdurstende organisieren, Kinder können die auf anderen ARs gespeicherten Spiele spielen für etwas mehr Abwechslung, und wenn einer seinen USB-UMTS-Router ansteckt, kann der ganze Stau E-Mails an die jeweiligen Großomas und den ADAC mit den Positionsdaten schicken usw. Und die verrücktesten Freaks können sich dabei dann gegenseitig beim Direkt-Tunen ihrer Motoren über CAN unterstützen. Nun, man sollte wohl nicht alles davon tun, aber coole Möglichkeiten gäbe es schon.
Michael B. schrieb: >> Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt >> das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel >> endet. > Also wir setzen Debian Stable in embedded Systeme bei unseren Kunden > ein. Die laufen dort bereits seit Jahren ohne Probleme oder Unterbrüche. > Eine Instabilität können wir überhaupt nicht feststellen. Das > Basissystem (ohne X-Windows Server) ist extrem stabil und sehr > resourcenschonend. > Zudem setzen wir Asterisk auf eine angepasste Linux-Distro ein. Die > läuft auch schon seit zwei Jahren ohne Unterbruch und steuert alle > unsere Telefonate. Ausserdem laufen bei uns im Unternehmen auch alle > Router und Telefone unter Linux, bisher auch fehlerfrei. Ich sag ja nicht das Linux generell instabil ist, ich bin eigentlich pro-Linux. Aber in einem Autoradio finde ich hat es nichts zu suchen. Ich will mich nicht ärgern wenn jemand irgendwo in einem Script beim parsen mit grep vergessen hat eine Rückgabe zu berücksichtigen oder weil er benutzte Komponenten nicht im Detail kennt etwas wichtiges vergessen hat was dann z.B. zu sowas führt wie das die dann evtl. benutzte WLAN Verbindung nicht wieder automatisch aufbaut wenn Sie wegfällt, oder was weiss ich. Ich sehe auch keinen Vorteil. Wenn man kein Multimediasystem mit Mplayer und co. machen will dann kann man in einem System ohne Linux genauso code "recyclen". Mal ganz abgesehen von dem Speicherbedarf, der Tatsache das man eine dynamische Speicherverwaltung braucht (was man meiner Meinung nach in kleinen embeddedsystemen sowieso vermeiden sollte), ... Wie gesagt, ich bin nicht contra linux und auch kein Windows jünger, ich finde es einfach nur sehr unpassend für solch ein einfaches System. > Aus meiner Sicht spräche aber vor allem der Punkt, dass man auf bereits > entwickelte, sehr stabile Komponenten setzen kann und nicht alles > neuentwickeln muss, für den Einsatz eines embedded Linux. Zudem können > Nutzer recht einfach weitere Komponenten für sich hinzunehmen. Ich behaupte genauso einfach, wenn nicht sogar einfacher geht es wenn man ohne Linux arbeitet. Eine saubere und modulare Software vorrausgesetzt. Die Build- und Testumgebung ist deutlich schlanker und übersichtlicher. Wer nicht viel Ahnung hat muss sich nicht erst in Linux einarbeiten und man hat evtl. eine chance auch als reiner Windows-user mal etwas an dem Radio zu ändern ohne in die Tiefen von Linux, Cygwin oder so abzutauchen.
didadu schrieb: > Und die verrücktesten Freaks können sich > dabei dann gegenseitig beim Direkt-Tunen ihrer Motoren über CAN > unterstützen. Oder den Motor eines "Rivalen" beim Straßenrennen einfach mal ausschalten...
Sven schrieb: > Soll das ein Car PC werden oder ein Radio? > > Ich bin auch stark für nen Arm7 oder Arm9 ohne Linux. Für ein richtigen > Computer mit WLAN und sonstigem Schnick Schnack reicht's dann natürlich > nicht aus. Aber für ein bisschen Radio, USB und sd Karten und mp3 > Funktionalität(was wohl sowieso ausgelagert wird) sollte das wohl > reichen, oder nicht? Klar würde das auch reichen, ich als µC-Laie dachte mir aber, das man das evtl. auch mit x86 hinbekommt, was aus meiner Sicht den Vorteil von leichterer Entwicklung hätte. Wäre dann zwar klar ein Car-PC, der aber nur Audio-Sachen managen soll/kann. Bin grad bissel am stöbern zwecks passender Boards, aber problematisch ist für mich immer wieder der Audio-Ausgang, der, wenn überhaupt, nur als 3,5mm-Klinke da ist. Ich persönlich hätte ja gern S/PDIF, aber gibts für S/PDIF auf Lautsprecher überhaupt kleine & ordentliche Verstärker? Also jetzt für die 12-24 W im Auto.
Kai G. schrieb: > Wer nicht viel Ahnung hat muss sich nicht erst in Linux einarbeiten und > man hat evtl. eine chance auch als reiner Windows-user mal etwas an dem > Radio zu ändern ohne in die Tiefen von Linux, Cygwin oder so > abzutauchen. Dem stimme ich zu. Ich hab (fast) keine Ahnung von Linux, kann aber unglaublich gut Controller programmieren ;-) Sicherlich gibts noch die Leute, die genau anders herum gepolt sind. Das ist dann mehr die CarPC Fraktion...
dito Um diesen Thread nicht noch unübersichtlicher zu machen und weiter über die Verwendung von Linux oder nicht zu diskutieren, sollten ernsthaft zwei Projekte daraus werden. Dafür sollte ein extra Thread entstehen und dieser eher für Grundlagen benutzt werden. Auch würde ich eher dieses wiki hier im Forum benutzen, um möglicherweise mehr Leute für dieses Projekt zu begeistern. Ich finde nämlich, dass es ein wirklich interessantes Projekt ist.
So. Jetzt bin ich auch mal angemeldet :-) Also wird jetzt ein CarPC und ein Radio gebaut? Das mit dem Wiki ist so ne Sache. Die Frage ist, was bringt ein externes Wiki für Vorteile? Ist da eventuell das Rechtemanagement besser zu gestalten? Mit einem internen Wiki werden sicherlich mehr Leute erreicht. Aber sollte nicht sowieso eine Seite hier entstehen, auf der der Status verfolgt werden kann? Man kann ja die Diskussion auslagern und hier die Ergebnisse präsentieren..
Sven H. schrieb: > So. Jetzt bin ich auch mal angemeldet :-) > > Also wird jetzt ein CarPC und ein Radio gebaut? > Beides? > Das mit dem Wiki ist so ne Sache. Die Frage ist, was bringt ein externes > Wiki für Vorteile? Ist da eventuell das Rechtemanagement besser zu > gestalten? Bzgl. der Rechteverwaltung hast du natürlich Recht. Aber jeder kann sehen, was eine andere Person geändert hat und ggf. zurücksetzen. Soweit ich beurteilen kann, funktioniert es in diesem Portal ganz gut, auch ohne die Rechte großartig einzuschränken. > Man kann ja die Diskussion auslagern und hier die Ergebnisse präsentieren.. Für die Diskussionen gibt es pro Wikiseite immer eine Diskussionsseite.
Sven H. schrieb: > So. Jetzt bin ich auch mal angemeldet :-) Prima :-) > Also wird jetzt ein CarPC und ein Radio gebaut? Ich denke man sollte 2 Projekte starten und evtl. Teile austauschen, wie z.B. Tuner. Ich wäre dann eher in dem nicht-Linux, nicht-Wlan Projekt. > Das mit dem Wiki ist so ne Sache. Die Frage ist, was bringt ein externes > Wiki für Vorteile? Ist da eventuell das Rechtemanagement besser zu > gestalten? Mit einem internen Wiki werden sicherlich mehr Leute > erreicht. Aber sollte nicht sowieso eine Seite hier entstehen, auf der > der Status verfolgt werden kann? Man kann ja die Diskussion auslagern > und hier die Ergebnisse präsentieren.. Hier gibts ein Wiki? :-)
Sven H. schrieb: > Also wird jetzt ein CarPC und ein Radio gebaut? Wieso muß man hier so stark differenzieren? Ich denke auch das so ein mini-itx/mini-.... Board eine gute Grundlage wäre. Ob man das nun PC nennt oder einen ARMxyz der "nur" ein µP ist ist doch egal. Man hätte auf jedenfgall eine Platform auf der man vieles einfach aufsetzen kann (USB-Reciver/TV-Karte) und zu basteln gibt es noch genug (Display, Schnittstellen nach außen, Stromversorgung) als das es "langweilig" werden würde.
Kai G. schrieb: >> Also wird jetzt ein CarPC und ein Radio gebaut? > > Ich denke man sollte 2 Projekte starten und evtl. Teile austauschen, wie > z.B. Tuner. Ich wäre dann eher in dem nicht-Linux, nicht-Wlan Projekt. Dito. Drei mal ;-)
Sven H. schrieb: > Also wird jetzt ein CarPC und ein Radio gebaut? Ist doch gar nicht schlecht, dann muß aber jeder in einen einzel-DIN-Schacht passen, damit ich beides im Auto haben kann :-)
Also das Alixboard würde schon passen (152.4 x 152.4 mm) Din-Schacht Breite etwa 178mm... Höhe scheint mir hauptsächlich durch die LAN Buchsen gegeben. Man könnte dan sogar als Datenspeicher ein NAS oder USB-Stick/HD ranhängen, oder wirklich einen WLAN-Router ;) I2C für erweiterungen ist auch dabei (optional) Spannungsbereich passt auch recht gut (7-20V) + ein echter Seriell-Port ggf. kann auch HW mittels mini PCI nachgerüstet werden :)
Läubi .. schrieb: > Wieso muß man hier so stark differenzieren? > Ich denke auch das so ein mini-itx/mini-.... Board eine gute Grundlage > wäre. Ob man das nun PC nennt oder einen ARMxyz der "nur" ein µP ist ist > doch egal. Man hätte auf jedenfgall eine Platform auf der man vieles > einfach aufsetzen kann (USB-Reciver/TV-Karte) und zu basteln gibt es > noch genug (Display, Schnittstellen nach außen, Stromversorgung) als das > es "langweilig" werden würde. Mit dem USB Krams fängts doch schon an. Da ist so viel Software im Spiel (Firmware, Treiber, ...). Ich hab z.B. auch noch nie ein stabiles Mediacenter system gesehen (VDR eingeschlossen, der DSP auf den DVB Karten stürzt auch bei schlechtem Empfang mal gerne ab, besonders wenn in Richtung DVB-T was macht). Ich will im Auto nicht den selben Bastelkrampf haben wie am PC. Ich behaupte das viel consumer peripherie nicht dafür gemacht und auch nicht getestet um stabil zu laufen. Dann ist man bei solch einem Projekt mehr damit beschäftigt die halbwegs stabile TV/Tuner Karte zu finden als mit der eigentlichen Entwicklungsarbeit. Etwas zu machen das "nur funktioniert" ist einfach, aber etwas zu machen das gut und stabil funktioniert noch lange nicht, erst recht nicht mit so einem modularen System wie einem PC Board + aufgeblasenes Betriebssystem.
> Wie gesagt, ich bin nicht contra linux und auch kein Windows jünger, ich > finde es einfach nur sehr unpassend für solch ein einfaches System. Das sehe ich genauso, und ich waere sonst total fuer Linux. Lasst das erstmal ein normales Radio werden. Wer danach sich nicht ausgefuellt fuehlt kann ja immer noch weitermachen. > Mal ganz abgesehen von dem Speicherbedarf, der Tatsache > das man eine dynamische Speicherverwaltung braucht (was man meiner > Meinung nach in kleinen embeddedsystemen sowieso vermeiden sollte), ... Yep. Dynamische Speicherverwaltung ist kaese. Sobald sowas drin ist braucht man auch den Resetknopf auf der Front. Kennt einer sonst noch CPUs ausser der SuperH-2A die viel Speicher enthalten? Ich wuerde es naemlich auch sehr toll finden wenn man auf externen Speicher verzichten koennte. Ich habe gerade beruflich einen R32 mit externen Sram in Betrieb genommen und das ist vom Aufwand und dem Platinenplatz schon doof, da bei laeuft das der Speicher mit lahmen 25Mhz. Ich denke wenn man so eine moderne CPU mit SD-Ram hat dann steigt der Aufwand nochmal ganz erheblich. ich wuerde es z.b gut finden wenn man mit einer doppelseitigen Platine auskommen koennte. Irgendwo hab ich auch noch eine Multimedia-CPU von Fujitsu rumliegen die hatte auch so 512MB-1MB, aber die wird auch schwierig zu beschaffen sein. Was haben denn die ARMe so eingebaut. Vielleicht reichen ja auch erstmal 256k hin. Man muss ja nicht immer so uebertreiben. Eines ist mir bei dem Wikikram nicht ganz klar. Wenn ich jetzt hingehe und da was aendere und jemand anderes aendert das dann wieder nach seinen Vorstellungen und ich dann wieder zurueck usw... Gibt das dann nicht so eine Art Krieg? Ich habe den Eindruck als wenn diese Art Medium in der Anfangszeit eines Projektes wo es noch starke Aenderungen geben kann, nicht so geeignet. Wenn man sich jetzt mal darauf zu einigen schafft das wir erstmal ein normales Radio bauen, wer ist den wirklich ernsthaft dabei. Ich haette gerne mal eine Vorstellung ob am Ende 3 oder 15 Radios gebaut werden. Olaf p.s: Ich habe gerade meine Renesas SuperH dazu gebracht mit einer LED zu blinken. Unglaublich das so eine fette CPU das noch kann. ;-D
Zumindest WLAN scheint noch eine Marktlücke zu sein. Ich verstehe ja Leute, die als leidenschaftliche CD-Sammler gerne jede Original-CD zu Hause in ihrem Regal haben und in den Händen halten wollen. Aber warum schleppt man heute noch gerne Speichermedien von Gerät zu Gerät mit sich herum? Klar, die Gewohnheit stammt noch aus der Zeit, als nur eine kleine Anzahl Stücke auf ein Medium passten und es sich nicht vermeiden ließ. Oder bin ich einfach nur faul? Meine gesamten Musik-/Filmsammlungen liegen auf einem Server. Im Haus sind LAN/WLAN-Mediaplayer verteilt. Nur für's Auto scheint es da noch keine kaufbare Lösung zu geben. Es ist doch viel praktischer, abends von der Couch aus über den Laptop flott ein paar MP3s zum Auto zu schicken, als erst in die Garage laufen zu müssen, den USB-Stick auszustöpseln, zu bespielen und ihn am nächsten Morgen nicht zu vergessen - vom Brennen auf CDs/DVDs ganz zu schweigen. Alternativ könnte das Radio selber periodisch nachschauen, was auf dem Server neu hinzugekommen ist, und sich von allein eine Kopie davon ziehen. Dass ich für Linux bin muss da wohl nicht extra erwähnt werden :) Mir ist jetzt auch kein Embedded-Gerät bekannt, auf dem Linux unzuverlässig läuft. Selbst wenn zweimal am Tag ein Neustart erforderlich wäre - was nicht so sein wird - wär das bei einem Autoradio, das selten so lange an einem Stück läuft, durchaus kein Drama.
So jetzt muss ich mal als langjähriger Car-PC Bastler und Nutzer auch mal ein paar Worte dazu sagen. Hier wurde zuerst die Idee angeregt an ein Open-Source Radio zubauen und so sollte es vielleicht auch bleiben. Wer eine Eierlegende Wollmilchsau will sollte gleich direkt auf Car-PC einsteigen. Und jeder Car-PC ist Open-Source. ;) Ein Car-PC hat nur ein Problem. Es gibt derzeit keine wirklichen Alternativen zum Empfang von FM/DAB. Und hier könnte das Projekt voll einhaken. Das Radio sollte deswegen, wie weiteroben schon geschrieben, Modular aufgebaut sein. Grundplatine sollte im Grunde nur ein vollwertiges und gut funktionierndes RDS FM/DAB Radio sein. Jede Erweiterung, wie W-Lan, CD-Laufwerk, MP-3 ect. sollte dann über einen Zusatzslot verfügbar sein. Mit dem Verfahren könnte man viel mehr Leute begeistern. Mir persönlich würde nur ein RDS-Radio mit USB-Anbindung für den Car-PC reichen. ;) Zum Thema Touchscreen Bedienung: Das Touchscreen ist viel einfacher zu bedienen als man glaubt. Vorrausestzt ist ein gutes "Skin-Konzept" am Bildschirm. Wichtig sind große Bedienfelder und eine feste Belegung aller wichtigen Bedienelemente. So sollte die Lautstärkeregelung in allen Betriebsmodis (egal ob Radio, CD, ODB ect) an der gleichen Stelle sitzen. Innerhalb kurzer Zeit hat man sich dann daran gewöhnt und man muss nicht mehr zwingend auf den Monitor schauen. Ich persönlich hab zwar dutzende Versuche gebraucht um die richtige Aufteilung zufinden, aber jetzt ist es nahezu perfekt. Als Feedback benutze ich den Buzzer vom PC-Mainboard. Reicht völlig aus. Aufalle Fälle bahnt sich hier ein richtiges MEGA-PROJEKT an und ich bin voll begeistert davon. ;) Trotzdem sollten wir klein anfangen. Es wird nicht einfach einen guten Radioempfang im Auto zuerreichen. lg Pezi
Olaf Kaluza schrieb: > Lasst das erstmal ein normales Radio werden. Wer danach sich nicht > ausgefuellt fuehlt kann ja immer noch weitermachen. Full ack :-) > Kennt einer sonst noch CPUs ausser der SuperH-2A die viel Speicher > enthalten? Ich wuerde es naemlich auch sehr toll finden wenn man auf > externen Speicher verzichten koennte. Ich habe gerade beruflich einen > R32 mit externen Sram in Betrieb genommen und das ist vom Aufwand und > dem Platinenplatz schon doof, da bei laeuft das der Speicher mit lahmen > 25Mhz. Also etwas in der Größenordnung von 64/96 KB ist kein Problem und wäre erfahrungsgemäß genug für solch ein Radio. Allerdings wäre es schön doch noch etwas mehr zu haben. Wenn wir allerdings echt Codec/Radio in 2 uCs splitten würde etwas in der 64 KB Größenordnung sicher voll und ganz reichen. Die Idee mit dem extra Frontpanel uC würd ich übrigens auch voll unterstützen. Da reicht dann sicher was kleines (PIC/AVR oder so). > Ich denke wenn man so eine moderne CPU mit SD-Ram hat dann steigt der > Aufwand nochmal ganz erheblich. ich wuerde es z.b gut finden wenn man > mit einer doppelseitigen Platine auskommen koennte. ...mal ganz abgesehen von den schönen "Zaunpfosten" im Spektrum die mal durch den schnellen parallelen Bus bekommt. > Was haben denn die ARMe so eingebaut. Vielleicht reichen ja auch erstmal > 256k hin. Man muss ja nicht immer so uebertreiben. Also Flash in der Größenordnung ist kein Thema, aber RAM leider schon. 256K wäre echt mehr als perfekt. > Eines ist mir bei dem Wikikram nicht ganz klar. Wenn ich jetzt hingehe > und da was aendere und jemand anderes aendert das dann wieder nach > seinen Vorstellungen und ich dann wieder zurueck usw... > Gibt das dann nicht so eine Art Krieg? Probier einfach mal ;-) > Ich habe den Eindruck als wenn diese Art Medium in der Anfangszeit eines > Projektes wo es noch starke Aenderungen geben kann, nicht so geeignet. gibts andere Vorschläge (Kick off meeting? :-)) > Wenn man sich jetzt mal darauf zu einigen schafft das wir erstmal ein > normales Radio bauen, wer ist den wirklich ernsthaft dabei. Ich haette > gerne mal eine Vorstellung ob am Ende 3 oder 15 Radios gebaut werden. Also ich bin NATÜRLICH ernsthaft dabei! Würden eher 2 Radios werden (1 für Entwicklung, 1 fürs Auto). Das Entwicklungsradio kann breadboardmässig sein, braucht auch kein Gehäuse... > p.s: Ich habe gerade meine Renesas SuperH dazu gebracht mit einer LED > zu blinken. Unglaublich das so eine fette CPU das noch kann. ;-D Das erinnert mich an mein erstes Z80 board mit per Taster programmiertem Eeprom (ein LED Blink programm). Es funktionierte auf Anhieb und ich hab mich total gefreut, bis ich dann feststellte das die Blinkfunktion eher durch den 7805 kam, weil die POWER-LED auch blinkte, denn mein Z80 board mit RAM, IO Port IC und co hat zu viel Strom gezogen hat. Der 7805 wurde zu heiss => er schaltete ab => er kühlte ab => er schaltete sich an ;-)
> Mir persönlich würde nur ein RDS-Radio mit USB-Anbindung für den Car-PC > reichen. ;) Evtl. sollte man genau hier ansetzen. Das "Autoradio-projekt" stellt eine Schnittstelle für ein CAR-PC zur Verfügung. Sämtliche Funktionen des Radios können über eine API angesteuert werden. > Trotzdem sollten wir klein anfangen. > Es wird nicht einfach einen guten Radioempfang im Auto zuerreichen. Nicht mit einem full featured PC Board und 3 PCI Karten, stimmt. Einen guten Empfang in dem beschriebenen Autoradio-system zu erreichen ist nicht so schwer wenn man sich mit der Materie schonmal beschäftigt hat.
Hallo,
ich werde zwar nicht zu den Projektbeteiligten gehören, lese aber sehr
interessiert mit.
Kann man das gesamte System nicht soweit modularisieren, so dass beide
Fraktionen (Non-Linux, Linux) möglichst viel Überschneidungen haben?
Wenn ich es richtig herauslese, gibt es ja Einigkeit darüber, dass der
Radioteil (Tuner, RDS, ...) und die Bedieneinheit als eigene Module
entwickelt werden sollen. Da sollte es doch möglich sein, die
Schnittstellen so zu gestalten, dass die einen einen Mikrocontroller als
Steuereinheit verwenden, während die anderen ein Linux-Embedded-System
einsetzen.
Gruss
Micha
Kai G. schrieb: >> Was haben denn die ARMe so eingebaut. Vielleicht reichen ja auch erstmal >> 256k hin. Man muss ja nicht immer so uebertreiben. > > Also Flash in der Größenordnung ist kein Thema, aber RAM leider schon. > 256K wäre echt mehr als perfekt. Wir haben grade nen lpc2214 in Benutzung. Der hat intern 256k Flash und 16k Ram. An dem ist aber extern nochmal 2mb Ram dran gepömpelt und wir kommen locker mit einer zweilagigen Platine aus. Jetzt ist die Frage ob 45ns Ram reicht. Wenn mehr Flash gebraucht wird, könnte man auch externes Flash nehmen und den Krämpel daraus bei Systemstart ins externe Ram kopieren und das Programm von da aus laufen lassen. Meines Wissens nach gibt es aber auch LPCs mit mehr Ram und Flash und noch jeder Menge anderer Peripherie (i2c, can, usb, spi).
Silabs hat unter Si47xx einige AM/FM-Receiver, mit integr. DSP, die man vielleicht für Empfangsteil nehmen könnte. ------------------------------- RX-CPUs sind moment mit bis ca 2MB Flash zu bekommen. Und das bis echte 100MHz! (später sogar bis echte 200MHz). Bei den meisten anderen uCs ist das Flash wesentlich langsamer! Ich denke mit den RX kann man schon sehr viel machen. ..haben auch einige DSP-Befehle.
Sven H. schrieb: >> Also Flash in der Größenordnung ist kein Thema, aber RAM leider schon. >> 256K wäre echt mehr als perfekt. > Wir haben grade nen lpc2214 in Benutzung. Der hat intern 256k Flash und > 16k Ram. An dem ist aber extern nochmal 2mb Ram dran gepömpelt und wir > kommen locker mit einer zweilagigen Platine aus. Es gibt noch größere nicht-bga LPCs, mit bis zu 96 KB internen ram (64KB echten, 16 KB Ethernet, 16 KB USB, die man aber wenn z.B. ethernet nicht genutzt wird auch für andere sachen einsetzen kann). > Jetzt ist die Frage ob 45ns Ram reicht. Kann reichen. Stack würd sowieso besser im internen liegen und sachen die schnell sein müssen schiebt man eben auch ins interne. Wobei halt noch die Frage ist ob man überhaupt externen einsetzen sollten. > Wenn mehr Flash gebraucht wird, könnte man auch externes Flash nehmen > und den Krämpel daraus bei Systemstart ins externe Ram kopieren und das > Programm von da aus laufen lassen. Flash wird wahrscheinlich nicht das Problem sein. > Meines Wissens nach gibt es aber auch LPCs mit mehr Ram und Flash und > noch jeder Menge anderer Peripherie (i2c, can, usb, spi). z.B. LPC2388. Hat auch interessanterweise auch direkt I2s ports. Ist allerdings ein Arm7.
MCUA schrieb: > Silabs hat unter Si47xx einige AM/FM-Receiver, mit integr. DSP, die man > vielleicht für Empfangsteil nehmen könnte. Die Si47xx sind reine portable ICs für Handies und co. Die sind von den technischen Daten her her nicht mit einem Car-tuner vergleichbar. Dafür allerdings wirklich sehr einfach zu programmieren! > RX-CPUs sind moment mit bis ca 2MB Flash zu bekommen. Und das bis echte > 100MHz! (später sogar bis echte 200MHz). Bei den meisten anderen uCs ist > das Flash wesentlich langsamer! Ich denke mit den RX kann man schon sehr > viel machen. ..haben auch einige DSP-Befehle. Ich schau mir die Rx und S2h dinger mal genauer an!
Vielleicht wäre es sinnvoll vor die Si47xx bessere HF-Eing.stufen zu bauen, um die rel. hohe Komplexität der Si47xx's ausnutzen zu können. --------------------------- RX's sind krachneu, und weitere zukünftige Neuerungen werden wohl am ehesten dort rein gebaut. Es wird in Zukunft auch eine rel. grosses Spektrum dieser Chips geben, also auch von einigen EUR an.
MCUA schrieb: > Vielleicht wäre es sinnvoll vor die Si47xx bessere HF-Eing.stufen zu > bauen, um die rel. hohe Komplexität der Si47xx's ausnutzen zu können. Einige Sachen kriegt man durch Vorschalten von "Eingansstufen" nicht mehr geradegebogen oder es wäre aufwändiger als direkt einen vernünftigen CAR-Tuner zu benutzen. Ein car tuner wie die weiter oben erwähnten ist sicher einem Si47xx oder TEA5990 vorzuziehen. Die bringen meist auch noch einen Audio multiplexer und etwas Audiosignalprocessing (Equalizer, ...) oder ähnliches mit sich.
>Die bringen meist auch noch einen Audio multiplexer und etwas >Audiosignalprocessing (Equalizer, ...) oder ähnliches mit sich. Oder gleich HF-teil und ADC/DAC u. DSP u.s.w. diskret machen, dann ists auch universeller benutzbar, bzw kann auch individuell angepasst werden. (Was ja bei ner fertigen IC-Lösung nicht mehr geht)
MCUA schrieb: >>Die bringen meist auch noch einen Audio multiplexer und etwas >>Audiosignalprocessing (Equalizer, ...) oder ähnliches mit sich. > Oder gleich HF-teil und ADC/DAC u. DSP u.s.w. diskret machen, dann > ists auch universeller benutzbar, bzw kann auch individuell angepasst > werden. (Was ja bei ner fertigen IC-Lösung nicht mehr geht) Oha, das ist ein Projekt für sich und selbst nach der eigentlichen FM Demodulation noch lange nicht erledigt (weak signal handling, etc...);-) Einige Autoradio DSPs bieten allerdings auch die Möglichkeit das ZF-Spektrum nach aussen zu bringen und andere Spielereien.
Hallo, Kai G. schrieb: > Mathias A. schrieb: >> @Kai G. (xyphro), noch eine Frage am Rande: kann es sein, dass Du einmal >> für den Beck IPC@CHIP einen FAT32-Treiber portiert hast, oder verwechsle >> ich Dich da mit jemand? > > jep, genau der bin ich :-) ah, ja Dein Nick/Name kam mir gleich irgendwie bekannt vor, aber erst gestern abend kam ich drauf dass das dorther gewesen sein könnte. Ein Blick in die Sourcen (Kommentare) hat den Verdacht dann erhärtet -- also an dieser Stelle nochmal danke dafür :-) Hast Du damals eigentlich auch den Player von Thomas Kindler nachgebaut? falls ja, noch im Einsatz? Meiner läuft wie gesagt noch immer ziemlich gut, seit über 7 Jahren mittlerweile... hier mal noch ein Link dazu: http://www.adamis.de/prj/mp3/index.html ~~~ Zu dem OS-Radioprojekt noch: ich hab' jetzt noch nicht alles hier durchlesen können, aber so wie mir scheint läuft es ja auf eine Zweiteilung hinaus. Denke auch dass das das beste wäre, daher mein Vorschlag sich zunächst auf Tuner, Verstärker und Bedienteil&Gehäuse zu konzentrieren. Dafür müsste doch ein recht kleiner Controller reichen (PIC/AVR, jedenfalls ohne externen Speicher etc. sodass Hard- und Software dabei nicht soo aufwändig werden dürfte), der dann z.B. einen UART als Interface zum Rest hat. Dieser Rest könnte dann eben je nach Wunsch entweder ein größerer Controller ohne Linux, ein Linuxsystem, ein x86-PC oder was auch immer sein. Je nach dem mit im gleichen Gehäuse integriert oder nach außen verlegt (Car-PC). Was meint ihr dazu? Gruß, Mathias
Michael B. schrieb: > Kai G. schrieb: >> Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt >> das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel >> endet. > > Also wir setzen Debian Stable in embedded Systeme bei unseren Kunden > ein. Die laufen dort bereits seit Jahren ohne Probleme oder Unterbrüche. > > Eine Instabilität können wir überhaupt nicht feststellen. Das > Basissystem (ohne X-Windows Server) ist extrem stabil und sehr > resourcenschonend. > 100% ACK > Von Seiten der Wartbarkeit hat sich die Modularität für uns sehr positiv > ausgewirkt. An einer grossen monolythischen Firmware ist die Wartung und > Pflege eine Sache, die zumeist von einem Spezialisten duchgeführt werden > muss, der die gesamte Firmware kennt. Mit modularen Systemen können > unterschiedliche Entwickler an verschiedenen Komponenten arbeiten. > > Aus meiner Sicht spräche aber vor allem der Punkt, dass man auf bereits > entwickelte, sehr stabile Komponenten setzen kann und nicht alles > neuentwickeln muss, für den Einsatz eines embedded Linux. Zudem können > Nutzer recht einfach weitere Komponenten für sich hinzunehmen. 100% ACK Harry
Kai G. schrieb: > (Firmware, Treiber, ...). Ich hab z.B. auch noch nie ein stabiles > Mediacenter system gesehen (VDR eingeschlossen, der DSP auf den DVB > Karten stürzt auch bei schlechtem Empfang mal gerne ab, besonders wenn > in Richtung DVB-T was macht). von wann stammen deine Erfahrungen mit VDR?....5J oder älter??? Sorry, aber, was du da schreibst, ist völliger Quatsch!!!! Mein VDR Mediacenter läuft hier seit Jahren absolut stabil! Stabilitätsprobleme gibt es beim Einsatz des Development-Branch oder bei defekter Hardware. Ein sauber aufgesetzter VDR läuft absolut stabil. Die Zeiten, wo die DSPs auf der DVB_Karte sassen ist eh vorbei. Harry
Harald L. schrieb: > Kai G. schrieb: > von wann stammen deine Erfahrungen mit VDR?....5J oder älter??? ca. 4 Jahre (DVB-T) + die Rückkehr vor ca. 1 Jahr (DVB-S) mit komplett anderer Hardware. > Sorry, aber, was du da schreibst, ist völliger Quatsch!!!! Mag sein. Es läuft aber bei mir halt nicht stabil (CTVDR und ein einziges Plugin für MediaMvp). Evtl. bin ich zu doof nen einfaches CTVDR zu installieren und es liegt an mir. Nach ein paar Wochen rumgebastel inkl. komplett neuaufsetzen auf einem echten Debian hab ich aufgegeben und jetzt schau ich halt mit meinem normalen SAT receiver fern, ohne aufzunehmen. > Mein VDR Mediacenter läuft hier seit Jahren absolut stabil! Dann sei froh! > Ein sauber aufgesetzter VDR läuft absolut stabil. Die Zeiten, wo die > DSPs auf der DVB_Karte sassen ist eh vorbei. Da fängts an: Was genau ist sauber aufgesetzt... Die DSPs sitzen bei den Full featured doch noch immer, oder vertu ich mich da?!
Harald L. schrieb: > Kai G. schrieb: >> (Firmware, Treiber, ...). Ich hab z.B. auch noch nie ein stabiles >> Mediacenter system gesehen (VDR eingeschlossen, der DSP auf den DVB >> Karten stürzt auch bei schlechtem Empfang mal gerne ab, besonders wenn >> in Richtung DVB-T was macht). > > von wann stammen deine Erfahrungen mit VDR?....5J oder älter??? > > Sorry, aber, was du da schreibst, ist völliger Quatsch!!!! > > Mein VDR Mediacenter läuft hier seit Jahren absolut stabil! > > Stabilitätsprobleme gibt es beim Einsatz des Development-Branch oder bei > defekter Hardware. > > Ein sauber aufgesetzter VDR läuft absolut stabil. Die Zeiten, wo die > DSPs auf der DVB_Karte sassen ist eh vorbei. > > Harry Ich glaube wir sollten auf weitere Diskussionen verzichten. Die einen haben gute, die anderen schlecht Erfahrungen gemacht. Jetzt wird es vermutlich zweigleisig laufen und somit m.E. ein guter Kompromiss gefunden.
> (Firmware, Treiber, ...). Ich hab z.B. auch noch nie ein stabiles > Mediacenter system gesehen (VDR eingeschlossen, der DSP auf den DVB > Karten stürzt auch bei schlechtem Empfang mal gerne ab, besonders wenn > in Richtung DVB-T was macht). Solche sachen werden über Car-PC's gesagt. Meiner läuft jedeoch seit über 4 Jahren Problemlos und Störungsfrei. Einzig die On-Screen-Tastatur (wird bei Navi-Eingabe oder bei MP3 Suche eingeblendet) macht hin und wieder Probleme. Wobei das eher nach einem Bug in der Front-End Software aussieht. Das wird schon. ;)
Kai G. schrieb: >> Ein sauber aufgesetzter VDR läuft absolut stabil. Die Zeiten, wo die >> DSPs auf der DVB_Karte sassen ist eh vorbei. > > Da fängts an: Was genau ist sauber aufgesetzt... keine unnötigen Dienste, nur stabile Plugin (da gibts leider einige Ausreisser) kein X...zuverlässige Hardware...etc...aber, ich geb auch zu, daß die meisten Anfänger damit überfordert sein dürften. > Die DSPs sitzen bei den Full featured doch noch immer, oder vertu ich > mich da?! Das ist zwar richtig, jedoch spielen diese Full featured Karten praktisch keine Rolle mehr, da heute jeder Single-Kern-Atom ausreichend Leistung hat, um selbst ein HD-Signal zu dekodieren. Harry
Hallo Zunächst einmal: Was immer Ihr auch macht, ob nun Linux oder nicht, ich find es klasse! Unsere Erfahrungen mit Linux sind eben (wie oben beschrieben) sehr positiv. Wichtig ist vor allem, keine exzentrische Hardware zu nehmen, da da vielleicht die erhältlichen Treiber nicht ausgereift sind. Das wird wohl auch der Grund für die Erfahrungen mit instabilen Mediacentern sein. Schlechte Treiber bringen aber auch einen Mikroprozessor zum Absturz. Da tut sich dazwischen nichts. Der Vergleich mit dem Mediacenter ist also eigentlich aussagelos. Für Linux gilt, dass das Basis-System, so wie es Harry beschrieben hat, EXTREM stabil ist. Je mehr Hardware man nun anfügt, desto mehr Treiber müssen entweder geschrieben oder aus dem bestehenden Repertoire genutzt werden, und desto höher ist das Risiko, Fehler im Treiber zu haben (die im unglücklichsten Falle zu einem Absturz führen können). Das gilt natürlich ebenfalls für ein reines Mikrocontroller-Board. Wenn Ihr da Treiber für den Screen, für das Radio, für WLAN, Bluetooth und TCP/IP-Stack schreiben wollt, dann können (und werden) sich da auch Fehler einschleichen, die auch zum Absturz des Systems führen können. Bei Linux ist eben der Vorteil, dass viele Komponenten bereits vorhanden sind und davon die meisten auch eine gute Qualität haben und ausgereift sind. Bei diesen schätze ich die Wahrscheinlichkeit eines Absturzes deutlich geringer ein, als wenn man die selber implementiert (auch auf einem Mikrocontroller). Was das Thema "Skripte etc" angeht: Das ist doch ein grosser Vorteil. Die Skript-Programmierung ist sehr viel einfacher als ein C-Compiler oder gar Assembler-Code. Damit können (einfache funktionale) Änderungen ohne viel Expertenwissen leicht vorgenommen werden. Viele unserer Systeme sind in Python programmiert. (Die Treiber im Kernel natürlich in C.) Aber die ganze Diskussion führt ja zu nichts. Es sind ja alle Vor- und Nachteile ausführlich diskutiert worden. Ich denke, es ist jetzt Zeit, dass eine Entscheidung getroffen wird und dann einfach in diese Richtung weiter gearbeitet wird. Da Kai der Initiator dieses Projektes ist, sollte er, meiner Meinung nach, diese Entscheidung treffen und dann geht es dahin weiter. Alle anderen Wünsche etc. sollten dann in ein anderes Projekt. Viele Grüsse Michael
> Also etwas in der Größenordnung von 64/96 KB ist kein Problem und wäre > erfahrungsgemäß genug für solch ein Radio. Allerdings wäre es schön doch > noch etwas mehr zu haben. Wenn wir allerdings echt Codec/Radio in 2 uCs > splitten würde etwas in der 64 KB Größenordnung sicher voll und ganz > reichen. Bist du da sicher? Mein Eindruck ist das gaengige MP3 Player alle ein Problem mit der maximal moeglichen Dateianzahl haben. Und die Ursache duerfte wohl im Ram liegen. Ich meine ich koennte vermutlich damit leben wenn man nur 1GB mit MP3 Dateien benutzen koennte. Aber hier waren doch Leute die wollten unheimlich total viele MP3s in so einer Kiste haben. Ausserdem waere es doch schon schoen wenn man wenigsten die komplette FAT der Speicherkarte im Ram halten koennte. Ich weiss es geht auch anders, waer IMHO netter. > Kann man das gesamte System nicht soweit modularisieren, so dass beide > Fraktionen (Non-Linux, Linux) möglichst viel Überschneidungen haben? Man kann es auf Schaltplanlevel und auf Firmwarelevel modularisieren. Aber Kai will ja eine Basisplatine auf der schon das Grundkonzept drauf ist. Was ich auch fuer vernuenftig halte. Wer also dann Teile fuer eine andere Sache braeuchte, der muesste sich dann eine FM-Radioplatine selber machen. > Es gibt noch größere nicht-bga LPCs, mit bis zu 96 KB internen ram (64KB > echten, 16 KB Ethernet, 16 KB USB, die man aber wenn z.B. ethernet nicht > genutzt wird auch für andere sachen einsetzen kann). Es gibt von Renesas IMHO auch schon recht schlichte M16er mit 128kb Ram. Und Flash ist sowieso kein Problem. Da hat man ja nie weniger als 256-512kb. Das bekommt nie voll. Allerdings sind das alles CPUs die fuer industrielle Steuerungen gedacht sind. (z.b Motorsteurung) Man brauchte aber eine CPU die schnell genug ist die Daten von SD zu lesen, MP3 zu dekodiern und mindestens noch ein I2S Interface hat um die Daten dann richtung DA-Wandler zu schubsen. Und dann haben wir noch keine Filtern, Mischung und aehnliches durchgefuehrt. BTW: Ich gehe mal davon aus das Balance, Faden, Bass usw in Software gemacht werden soll und nicht mit einem analogen AutoradioIC? Ich wuerde dann mal folgendes vorschlagen: 1. Ein spezieller Controller der sich um LCD, Tastatur, Encoder usw kuemmert. Leistungsklasse etwa M16C/29 oder was es da von AVR in der Liga geben mag. Der muss auch ein bisschen Ram haben weil er ja z.B Liedtitel darstellen muss und hier sollten auch Grafikelemente und aehnliches liegen. Dieser Prozessor redet mit dem Hauptprozessor ueber I2C, SPI oder RS232. Er ist der eigentlich Boss der entscheidet was jetzt gerade ablaeuft. Daher kann er auch einfach durch was ganz anderes ersetzt werden und man kann den ganzen Rest der Hardware durch was anderes ansteuern. 2a. Ein moeglicht potenter Hauptprozessor der die Daten von der SD holt und die MP3 dekodierung durchfuehrt. Frage: Ich gehe mal davon aus das die FM-Daten analog aus dem Tuner kommen. Dann muessten sie hier auch digitalisiert werden. Die Ausgangsdaten werden dann ueber I2S rausgeworfen. 2b. Ein durschnittlicher Prozessor der mit der SD Reden kann aber einen externen MP3-Decoder braucht. Spart vermutlich eine Menge Arbeit, aber nicht so elegant. 3. Ein weiterer Prozessor nimmt die I2S-Daten und kuemmert sich um Lautstaerke, Fading, Klangregelung und gibt es dann an die DA-Wandler. Fuer den Prozessor unter Punkt3 habe ich derzeit keine Vorstellung. Von der Idee her erwartet man da natuerlich als erstes einen DSP, aber es sollte halt eine brauchbare Entwicklungsumgebung mit C-Compiler fuer umsonst geben. Ist schon eine Weile her das ich einen DSP in Assembler programmiert habe und ich war nicht so angetan. :-) Auf diese Weise laesst sich alles in sechs getrennte Aufgaben aufteilen, die obigen drei und zusatzlich noch Tuner, Spannungsversorgung, Audioverstaerker. Olaf
Harald L. schrieb > Das ist zwar richtig, jedoch spielen diese Full featured Karten > praktisch keine Rolle mehr, da heute jeder Single-Kern-Atom ausreichend > Leistung hat, um selbst ein HD-Signal zu dekodieren. bei weitem nicht. wohl eher, das die GPUs mitlwerweile genug rechenleistung haben die CPU dabei zu unterstützen. Wobei man fährer weise auch sagen muss, es kommt immer darauf an wie HD codiert wird. bei h.264 mit einem sigelcore Atom aber sicher nicht. Mit ION board sicher machbar, nur das stabil stell ich mal in frage (c't hat das damals in einem test als nicht stabil bezeichnet, bzw mit viel aufand aufgesetzt werden muss) wenn doch bitte ich um den gegenbeweis mit link. grus
Hallo zusammen, vielleicht kann ich noch was zum Gehäuse beitragen. Schaut mal hier die CarPC's an. Die Gehäuse werden aus ganz normalen Belch gefertigt, gelasert und gebogen. http://www.delta-components.com/products/mobile_carpc_muenchen.htm Die Gehäuse werden in "kleinen" Serien gefertigt 100 Stück. Das kostet nicht die Welt. Meiner Meinung nach, sollte das "drum herum" als erstes entwickelt werden, sobald klar ist welche Funktionen integriert sein sollen. Für den DIN Schacht gibt es immer hin auch Vorschriften (Positionen von Steckern, Wärmeabfuhr vom Gehäuse, usw.). Mit dem Massen die das Gehäuse dann hat kann man die Platine, bzw. Platinen ableiten. Sonst hat man viel Zeit in ein Layout gesteckt und muss es dann noch mal machen weil nichts passt. Zudem sollte jemand mal eine "Projektplanung" machen, aufteilen der einzelen Schritte usw. Sonst stehen hier dann schluss endlich 1000 Beiträge und ein Radio gibts immer noch nicht.
Olaf Kaluza schrieb: > 2a. Ein moeglicht potenter Hauptprozessor der die Daten von der SD holt > und die MP3 dekodierung durchfuehrt. Vorteil: Man ist offen für zukünftige Standards oder auch aktuelles wie zum Beispiel Ogg. > Frage: Ich gehe mal davon aus das die FM-Daten analog aus dem Tuner > kommen. Dann muessten sie hier auch digitalisiert werden. Ist das notwendig? Am Ende muss es doch sowieso wieder Analog sein. Oder hast Du mit den Daten noch etwas spezielles vor?
... schrieb: > vielleicht kann ich noch was zum Gehäuse beitragen. > Schaut mal hier die CarPC's an. Danke;) Schöner kann man die Problematik wirklich nicht rüberbringen. Super Design, besonders der Drehknopf am Modell Berlin, der ist einsame Spitze. Oliver
Vielleicht könnte man sich dahingehend einigen, die Hardware ausreichend gross zu dimensionieren, um den Einsatz von Linux möglich zu machen. Es scheint ja wohl darauf hinauszulaufen, daß es 2 Software-Ansätze für diese Hardware gibt. Treiber könnten innerhalb einer gemeinsamen Code-Basis entwickelt werden. Ich denke, daß mit diesem Ansatz allen gedient währe. Harry
Audi macht das mit WLAN und Bluetooth neuerdings auch: http://www.basicthinking.de/blog/2010/05/25/audi-a8-auf-der-internet-ueberholspur-mit-wlan-ab-werk/
Olaf Kaluza schrieb: > Bist du da sicher? Mein Eindruck ist das gaengige MP3 Player alle > ein Problem mit der maximal moeglichen Dateianzahl haben. > Und die Ursache duerfte wohl im Ram liegen. Mit intelligenten Konzepten klappt es auch mit vielen Dateien. Ich kenne da 2: 1.) Wenn man eine sortiere Fileliste im Speicher halten will braucht man nicht den Dateinamen, sondern es reicht aus -FAT sei dank- den Startsektor zu speichern. Das ist eindeutig und lässt sich dann wieder in einen Dateinamen auflösen. Das klappt natürlich nur so lange, wie man die Möglichkeit hat an den Filesystem "Treibern" selbst zu basteln. 2.) Man kann einen Quicksort algorithmus implementieren und immer das aktuelle Verzeichnis nach dem nächst"höheren" oder nächst"kleineren" Dateinamen durchsuchen lassen. Das geht rasend schnell, auch mit langen Dateinamen. Die Optimierte Variante wäre immer eine Anzahl von z.B. 10 Dateinamen im Speicher zu halten. Vorteil: Absolut unbegrenzt in der Dateianzahl. Beides hab ich shcon mal realisiert und klappt echt prima. Selbst bei Variante 2 merkt man nicht das im Hintergrund verdammt viel I/O passiert. Parallel MP3 Abspielen ist auch noch mit Möglichkeit 2 Möglich. Ansonsten unterstütze ich aber stark den Drang nach mehr Speicher, solche Kunstgriffe sind nicht immer schön. Wenn sich also was schönes finden läßt (muss mir noch immer Deine vorgeschlagenen uCs anschauen, mach ich heute Abend)... > Ich meine ich koennte vermutlich damit leben wenn man nur 1GB mit MP3 > Dateien benutzen koennte. Aber hier waren doch Leute die wollten > unheimlich total viele MP3s in so einer Kiste haben. > Ausserdem waere es doch schon schoen wenn man wenigsten die komplette > FAT der Speicherkarte im Ram halten koennte. Ich weiss es geht auch > anders, waer IMHO netter. Ja, sicher schön, aber so eine FAT kann recht groß werden. Caching ist doch auch kein Problem, oder. Man kann im Filesystem treiber 2 caches implementieren. Einer für FATs, einer für anderen Kram. > Man kann es auf Schaltplanlevel und auf Firmwarelevel modularisieren. > Aber Kai will ja eine Basisplatine auf der schon das Grundkonzept drauf > ist. Was ich auch fuer vernuenftig halte. Wer also dann Teile fuer eine > andere Sache braeuchte, der muesste sich dann eine FM-Radioplatine > selber machen. Ja, in einem Autoradio den tuner modular zu machen hat denk ich nicht viel sinn weil ein FM Empfänger halt schon eine Grundfunktion von einem Autoradio ist. Selbigest trifft denk ich auch auf MP3 zu. > Es gibt von Renesas IMHO auch schon recht schlichte M16er mit 128kb Ram. > Und Flash ist sowieso kein Problem. Da hat man ja nie weniger als > 256-512kb. Das bekommt nie voll. Stimmt, solange man nicht 200 Icons mit ablegt ;-) > Allerdings sind das alles CPUs die fuer industrielle Steuerungen gedacht > sind. (z.b Motorsteurung) Man brauchte aber eine CPU die schnell genug > ist die Daten von SD zu lesen, MP3 zu dekodiern und mindestens noch ein > I2S Interface hat um die Daten dann richtung DA-Wandler zu schubsen. > Und dann haben wir noch keine Filtern, Mischung und aehnliches > durchgefuehrt. Mischen, Filtern und so kann der Car "tuner". > BTW: Ich gehe mal davon aus das Balance, Faden, Bass usw in Software > gemacht werden soll und nicht mit einem analogen AutoradioIC? Wäre machbar, allerdings würde das je nachdem welchen AuroradioIC man nimmt intern sowieso auch wieder digital laufen, also nicht viel anders. > 1. Ein spezieller Controller der sich um LCD, Tastatur, Encoder usw > kuemmert. Leistungsklasse etwa M16C/29 oder was es da von AVR in der > Liga geben mag. Der muss auch ein bisschen Ram haben weil er ja z.B > Liedtitel darstellen muss und hier sollten auch Grafikelemente und > aehnliches liegen. Evtl. wäre es sinnvoll (der Geschwindigkeit wegen) ein direktes Interface vom Haupt uC zum Display zu machen. > Dieser Prozessor redet mit dem Hauptprozessor ueber I2C, SPI oder RS232. > Er ist der eigentlich Boss der entscheidet was jetzt gerade ablaeuft. > Daher kann er auch einfach durch was ganz anderes ersetzt werden und man > kann den ganzen Rest der Hardware durch was anderes ansteuern. Prima! > 2a. Ein moeglicht potenter Hauptprozessor der die Daten von der SD holt > und die MP3 dekodierung durchfuehrt. > Frage: Ich gehe mal davon aus das die FM-Daten analog aus dem Tuner > kommen. Dann muessten sie hier auch digitalisiert werden. Digitalisieren ist nicht unbedingt nötig wenn man einen externen Audio-Multiplexer hat. > 2b. Ein durschnittlicher Prozessor der mit der SD Reden kann aber einen > externen MP3-Decoder braucht. Spart vermutlich eine Menge Arbeit, aber > nicht so elegant. Ein Arm7 mit 60 MHz würde reichen, wäre aber trotzdem für was Leistungsstärkeres. > 3. Ein weiterer Prozessor nimmt die I2S-Daten und kuemmert sich um > Lautstaerke, Fading, Klangregelung und gibt es dann an die DA-Wandler. > Fuer den Prozessor unter Punkt3 habe ich derzeit keine Vorstellung. Von > der Idee her erwartet man da natuerlich als erstes einen DSP, aber es > sollte halt eine brauchbare Entwicklungsumgebung mit C-Compiler fuer > umsonst geben. Ist schon eine Weile her das ich einen DSP in Assembler > programmiert habe und ich war nicht so angetan. :-) Ein DSP wäre evtl. auch wegen der Verfügbarkeit nicht gerade von Vorteil. Das ist meist recht exotisches zeugs. > Auf diese Weise laesst sich alles in sechs getrennte Aufgaben aufteilen, > die obigen drei und zusatzlich noch Tuner, Spannungsversorgung, > Audioverstaerker. ACK!
Mathias A. schrieb: > ah, ja Dein Nick/Name kam mir gleich irgendwie bekannt vor, aber erst > gestern abend kam ich drauf dass das dorther gewesen sein könnte. Ein > Blick in die Sourcen (Kommentare) hat den Verdacht dann erhärtet -- also > an dieser Stelle nochmal danke dafür :-) Schön zu sehen das mein Code noch aktiv benutzt wird ;-) Dann war die Arbeit nicht ganz umsonst. > Hast Du damals eigentlich auch den Player von Thomas Kindler nachgebaut? > falls ja, noch im Einsatz? Meiner läuft wie gesagt noch immer ziemlich > gut, seit über 7 Jahren mittlerweile... hier mal noch ein Link dazu: > http://www.adamis.de/prj/mp3/index.html Sieht nett aus. Ich hatte eine eigene Version von den KreaPC Player gemacht, die allerdings zwischendurch dem Bastelwahn zum Opfer gefallen ist und alle Teile mittlerwelie in anderen Projekten verbaut wurden ;-(
Harald L. schrieb: > Vielleicht könnte man sich dahingehend einigen, die Hardware ausreichend > gross zu dimensionieren, um den Einsatz von Linux möglich zu machen. Wie würden denn die Anforderungen an RAM/ROM ausshenen (mal z.B. einfach von einem ARM9 ohne MMU ausgegangen)? Ansonsten gäb es halt noch die erwähnte remote möglichkeit, 2 Projekte, CarPc steuert CarRadio fern.
... schrieb: > vielleicht kann ich noch was zum Gehäuse beitragen. > Schaut mal hier die CarPC's an. Die Gehäuse werden aus ganz normalen > Belch gefertigt, gelasert und gebogen. > http://www.delta-components.com/products/mobile_carpc_muenchen.htm > Die Gehäuse werden in "kleinen" Serien gefertigt 100 Stück. Das kostet > nicht die Welt. Gibts da evtl. Kontakte zu firmen? > Zudem sollte jemand mal eine "Projektplanung" machen, aufteilen der > einzelen Schritte usw. Sonst stehen hier dann schluss endlich 1000 > Beiträge und ein Radio gibts immer noch nicht. Vorher sollten wir grob abstecken wie das Interface zwischen den 2 Interessengruppen liegt, sofern es eins gibt.
Kai G. schrieb: > Harald L. schrieb: >> Vielleicht könnte man sich dahingehend einigen, die Hardware ausreichend >> gross zu dimensionieren, um den Einsatz von Linux möglich zu machen. > > Wie würden denn die Anforderungen an RAM/ROM ausshenen (mal z.B. einfach > von einem ARM9 ohne MMU ausgegangen)? > > Ansonsten gäb es halt noch die erwähnte remote möglichkeit, 2 Projekte, > CarPc steuert CarRadio fern. 2 Projekte halte ich nicht für sinnvoll. Eine Hardwareplattform und 2 alternative Software-Ansätze wär doch ok! 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. Ohne die Möglichkeit Linux zu verwenden, wär das Projekt für mich uninteressant. HW-Vorraussetzung: * 32bit-CPU mit MMU GCC-Toolchain MUSS verfügbar sein; Windows-Tools vom Hersteller sind für mich absolut unbrauchbar, da ich meine Software unter Linux entwickel. Ausserdem wär das kein "OpenSource-Autoradio", wenn schon der Compiler nicht OpenSource ist. * 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. Harry
Harald L. schrieb: > 2 Projekte halte ich nicht für sinnvoll. > Eine Hardwareplattform und 2 alternative Software-Ansätze wär doch ok! 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. > * 32bit-CPU mit MMU > GCC-Toolchain MUSS verfügbar sein; Windows-Tools vom Hersteller sind für > mich absolut unbrauchbar, da ich meine Software unter Linux entwickel. > Ausserdem wär das kein "OpenSource-Autoradio", wenn schon der Compiler > nicht OpenSource ist. Klar, was sollte gegen gcc sprechen. Ist eine MMU wirklich unbedingt nötig? > * 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...
Als Projektmanagmentsystem würde sich das webbasierte System Redmine anbieten. http://www.redmine.org/ Beide Fraktionen wollen das gleiche! Sauber programmierte Basissoftware die einen vor Problemen bewahren soll. 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. 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. Als DSP würden sich die Blackfins anbieten, sie werden vom GCC unterstützt und haben LQFP Gehäuse oder der kleinere Bruder ADSPxx . MFG Patrick
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 ;-)
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. > > Klar, was sollte gegen gcc sprechen. > Ist eine MMU wirklich unbedingt nötig? > >> * 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... Linux mit einigen kB geht nicht.....ohne MMU geht das zwar, ist aber ein extremer Krampf, und eigentlich auch nicht mehr zeitgemäss. Das Flash könnte man ggf. als CF-Kartenslot einbauen. Harry
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!!
Ich hab auch mal ein wenig zum Thema SH7264 recherchiert. * er hat eine SH-2A_Architektur, die nicht unmittelbar durch das GCC-Team supportet wird. Der GCC auf der Renasis-Seite scheint ein eigener Fork von Rernasis zu sein. GCC unterstützt SH-3 und SH-4. *GDB-Unterstützung dann wohl eher auch nicht. D.h.: man ist bei der Entwicklungsumgebung (heute) auf Gedei und Verderb an Renasis gebunden.....ob das so schlau ist? * für mich ist bisher auch völlig ungeklärt, wie ich meine Software in das Board bekomm, solange ich nicht das (teure) Development-Kit von Renasis, oder den beschriebenen USB-Adapter aus dem japanischen Elektronik-Magazin (Beschaffung völig ungeklärt) besitze. Selbstbau-Projekte mit diesem Chip finden sich im Netz scheinbar (noch) nicht. Von nachbaubaren "ISP-Adaptern" ganz zu schweigen. Zudem scheint Renasis da auch eine recht restriktive Lizensierungsstrategie zu fahren, wenn ich z.B. lese, daß ich für die Nutzung der Hardwaredebug-Funktion eine extra (kostenpflichtige) Lizens benötige... Also irgendwie hab ich bei dem Ding im Moment kein so gutes Gefühl, auch, wenn die Features wirklich verlockend sind. Harry
Auch wenn er auf den 1. Blick vielversprechend aussieht, warum solch einen exotischen Prozessor verwenden? Nach den Problemen mit verschiedensten Renesasprozessoren, die ich in der Firma immer wieder sehen muß, käme für mich solch ein Prozessor nie in Frage, auch wenn man die Entwicklungskits zur Zeit regelrecht hinterhergeworfen bekommt. Zeitgemäß und relativ zukunftssicher sehe ich Prozessoren mit Arm-Kern. Hier sind die Toolchains komplett frei und gut erprobt. Es gibt genügend Hilfestellung im Netz und viele Leute, die sich damit auskennen.
Ich halte das auch für mutig auf so einen Exoten zu setzen. Der mag für kommerzielle Autoradios ganz nett sein, aber für Open Source Projekte gelten andere Anforderungen. Gibt es z.B. überhaupt einen Open-Source-MP3- und AAC-Decoder für den Prozessor?
Jan X. schrieb: > Auch wenn er auf den 1. Blick vielversprechend aussieht, warum solch > einen exotischen Prozessor verwenden? Nach den Problemen mit > verschiedensten Renesasprozessoren, die ich in der Firma immer wieder > sehen muß, käme für mich solch ein Prozessor nie in Frage, auch wenn man > die Entwicklungskits zur Zeit regelrecht hinterhergeworfen bekommt. > Zeitgemäß und relativ zukunftssicher sehe ich Prozessoren mit Arm-Kern. > Hier sind die Toolchains komplett frei und gut erprobt. Es gibt genügend > Hilfestellung im Netz und viele Leute, die sich damit auskennen. 100% ACK 32bit Atmel erscheint mir auch ganz OK Harry
es gibt einen E10A-USB Lite On-Chip Debug Emulator, ua von MSC, der sollte günstiger sein. SH2-A ist min. genau so sicher wie ARM, wenn nicht sicherer. Es gibt von dieser Schiene (von Renes) extrem viele Controller, weit mehr als ARM von einer einzelnen Firma (von verscheidenen Firmen, sind ja ARM.Controller auch nicht kompatiberl, nur die CPU) >Soweit ich das aber nach nur lesen sagen kann ist es weniger komplex als >eine R32 oder M16. Stimmt so nicht. SH2(-A) ist RISC mir nur 16bit OPcode-satz (desw auch rel wenig Adr-möglichkeiten, (bzw Table im code nötig)), braucht also oft viele Befehle wo nen CISC nur 1 braucht. Die MIPS-Angaben sind da nicht sehr wirklichkeitsnah! SH2-A ist eine Erweiterung von SH2, um einige Befehle, insbes Erweit. mit 15 Registerbänken. Aber SH2(-A) hat DelayedBranches, also etwas knifflig zu progr.! SH..CPUs gibts seit ca 1993. Der Kern ist also auch nicht der Neuste und ist immer 'aufgestockt' worden. Renesas favorisiert die im Hochleistungsbereich, bzw auch im Bereich mit sehr viel Periferie. RX's (gibts mit sehr viel Flash, auch sehr schnell, zukünft. bis max 200MHz ) sind dagegen ganz neu und sind von der Leistung her auch i.e. mit SH2's vergleichbar, und sind besser zu programmieren. Viele Periferie-teile von neueren Renes-Derivate der verschiedenen CPU-Familien überschneiden sich bzw werden sich in Zukunft immer mehr überschneiden (da Ren. das Rad auch nicht immer neu erfinden will) DTC (von Ren.) ist auch eine nette Perif-einheit (die in den meisten neueren Deriv eingebaut ist), fast so schnell wie DMA, aber mit wesentlich mehr Kanälen. Die meisten anderen Chip-Hersteller haben nichts vergleichbares zum DTC. --- Vielleicht so'n RX nehmen --ist General Purpose, sehr schnell, hat integr. schnelles Flash -- und ggfs I2S-Teile usw einfach über PLD/FPGA anbinden (dann wär man da noch flexibler als mit nem o.g. SH2-A)
Ehrlich gesagt, ich fühle mich mit dem Renesas auch nicht so ganz wohl, aus den Gründen die die Vorposter schon erwähnt hatten... Die Features von ihm klingen allerdings schon nicht schlecht, gerade die speziellen Audiosachen. Wobei es mir persönlich gar nicht so wichtig wäre die Audiosignale digital verarbeiten zu können, soweit ich bisher über den Tuner gelesen habe denke ich könnte ich mit dessen (analogen) Möglichkeiten auskommen. Da aber für manche die Prioritäten ja anders liegen, möchte ich die Euphorie für den Renesas hier nicht bremsen ;-) Somit ein Vorschlag: wie wäre es den Analogteil (Tuner/Verstärker, evtl auch die ADC/DACs) und den Renesas jeweils auf einer eigenen Platine unterzubringen? zumal ja anscheinend ein Evalboard für den Renesas geplant ist - möglicherweise könnte dieses dann damit auch gleich für das Radio weiterverwendet werden? Auf die Tunerplatine dann nur einen kleinen Controller setzen, der z.B. die RDS-Dekodierung, Abfragen von Tasten/Drehgebern etc. übernimmt. Das hätte auch den Vorteil, diese (zeitkritischen) Steuerungsaufgaben von dem Controller der die Signalverarbeitung macht abzukoppeln (Olaf hatte ja auch bereits angesprochen, dass das eine Herausforderung werden könnte). Somit könnten am Tuner alle gemeinsam arbeiten und trotzdem jeder den Controller seiner Wahl verwenden. Was meint ihr dazu? Einwände? Gruß Mathias
So, meine Entscheidung steht fest: Ich votiere aus o.g. Gründen eindeutig GEGEN die Renesas CPUs Harry
> Der Renesas protzt zwar mit seinem großen RAM, aber er lädt > das Programm aus einem SerialFlash... D.h. effektiv steht > einem nicht mehr RAM zur Verfügung als bei einem beliebigen > anderen CortexM3 oder AVR32 mit internem 512kB Flash und > 64..128k internem RAM. Ich weissen nicht ob 'protzen' das richtige Wort ist. Ich koennte mir vorstellen das RAM an dieser Stelle einfach eine Notwendigkeit war um die notwendige Geschwindigkeit zu erreichen. Ansonsten hast du natuerlich recht wenn du wirklich planst ein Programm zu schreiben das 512kByte gross ist. Allerdings hindert dich beim RAM keiner eine beliebige Funktionalitaet nachzuladen. Soll heissen eine der Funktionen die ich spaeter beim Bootmanager integrieren wollte, war das er einem die Moeglichkeit gibt die Firmware auch von der SD-Karte zu laden. > Jungs hat wer von euch erfahrung mit LineIn und Out. Besonders > welche beschaltung man zwischen CODEC und verstärker braucht usw ? Du brauchst einen Tiefpass gegen die Samplefrequenz. Idealerweise vielleicht nur eine RC Kombination wenn Oversampling. Ausserdem einen OP am Ausgang als Puffer und einen am Eingang um das Signal DC-maessig auf das anhebt was der Wandler unter 0 versteht. Ich denke mal der Hersteller deines Codecs koennte dazu eine Applikation haben? > BTW: Denkst Du, das es evtl. möglich ist einen anderen jTag > debugger zu benutzen? J-Link, FTDI basierte designs oder > standard RDI debugger nehmen? Bzw. kannst Du mal in den > Einstellungen der Entwicklungsumgebung schauen? Hm...ich selber habe bisher noch niemals JTAG benutzt. Ich denke aber das die verwendung eines beliebigen Debuggers kein Problem sein sollte wenn man einfach nur uebersetzten Code in das Flashrom schreiben moechte. Der Compiler kann sicherlich Motorola-S, Hex und Bin erzeugen. Ich weiss aber nicht ob und wie ein fremdes JTAG-Interface mit dem Debugger zusammenarbeiten kann so das der halt vollen Zugriff hat. Ich koennte mir vorstellen das dies nicht ohne ernste Programmierarbeit auf PC-Seite abgeht! > Ich dachte eher an jeder Seite doppelreihige Steckerleisten zu machen. Hm..gut, das koennte auch gehen. Ich denke da auch nochmal drueber nach. Aber erstmal will wenigstens mal I2C laufen habe damit ich einen ersten Erfolg sehe. :-) > Dann wird es klein und kompakt und ist trotzdem noch auf > Lochrasterplatinen benutzbar. Das wuerde ich auch fuer wichtig halten damit man es wenigstens auf so ein Standard 100x160 Board stecken kann. BTW: Die Verteilung der Signale auf dem japanischen Board ist etwas hm... chaotisch. > Übrigens find ich das decoupling schon recht ungewöhnlich, bzw. > SEHR auf Sicherheit gebaut. 10µ, 100n, 10n und 1n in Reihe? So genau habe ich mir den Schaltplan noch garnicht angeschaut. Wuerde ich fuer etwas sehr uebertrieben halten. Ein 100n in als kleiner 0603 oder 0402 sollte doch wohl reichen. > Was für Typen sind das? X7R/NP0/? Gibts zufällig ne BOM wo > das drinsteht? http://www.criseis.ruhr.de/SuperH/bom.jpg Den Text spare ich mir jetzt mal. :-) > Der GCC auf der Renasis-Seite scheint ein eigener Fork von > Rernasis zu sein. Dazu kann ich nichts sagen, ich habe mir nur mal alles runtergeladen was die Japaner selber angeboten haben: [root] /mnt/E/Daten/Etechnik/SuperH/sh7262/Dokus/gcc: l insgesamt 31M 348K 2010-05-24 14:29 asp_cq_frksh2a_gcc-20100409.tar.gz* 929K 2010-05-24 15:20 cq_gnu_resources20100424.tar.gz* 217K 2010-05-24 15:19 cq_sh7262_gcc.zip* 28M 2010-05-24 14:28 gnu_sh-hitachi-elf_cygwin-2.95.3-1.tar.gz* 1,5M 2010-05-24 14:30 jsp-1.4.3_cq_frksh2a-20100409.tar.gz* 40K 2010-05-24 14:30 jsp-config-cq_frksh2a-20100409.tar.gz* Selber habe ich momentan noch keinen Grund mich damit zu beschaeftigen. > * für mich ist bisher auch völlig ungeklärt, wie ich meine Software in > das Board bekomm, solange ich nicht das (teure) Development-Kit von > Renasis, oder den beschriebenen USB-Adapter aus dem japanischen > Elektronik-Magazin (Beschaffung völig ungeklärt) besitze. Wie du das unter Linux schaffen willst weiss ich auch nicht. Selbst ist der Mann :-) Unter Windows sieht es so aus.... Man muss einmalig ein SPI-Flash mit einer Bootfirmware haben. Auf dem japanischen Board ist dieses Flash ein M25P05 von Numonix. Renesas selber gibt in seinen Applikationen aber ein Datenflash von Atmel an. Das muss man selber brennen koennen, SPI halt, oder jemand anders (ich z.B) brennt es einem in einem Brenner. Oder sonstwie. Ich meine das beschreiben eines SPI-Flash sollte ja keine grosse Sache sein. In dieses Flash kommt ein 8kb grosser Bootloader von Renesas. Den gibt es im uebrigen auch im Source! Ausserdem kommt da ein 24kb grosses Programm rein das mit dem Debugger von Renesas reden kann. Letzeres vermutlich auch im Source, habe ich aber noch nicht verifiziert. (8kb+24kb=32kb) Der Bootloader in der augenblicklichen Form (wie gesagt Source, kann beliebig umgeschrieben werden) laedt entweder das Debuggerprogramm oder aber aber die anderen 32kb des Flashrom und startet die. Dieses 32kb in dem 64kb Flash sind fuer den User vorgesehen. Wobei natuerlich 64kb etwas mickrig sind. Das wollte ich in naher zukunft auch durch was anderes ersetzen. Aber erstmal egal. Sobald eine funktionierende Anbindung an eine SD-Karte vorhanden ist wollte ich den Bootloader auf jedenfall dazu bringen das er auch etwas von SD-Karte startet! Wenn der Debugger das Monitorprogramm (24kb) startet dann meldet sich das Board ueber USB als virtueller COM-Port an dem PC an. Danach kann die Entwicklungsumgebung von Renesas mit dem Board reden. Es ist dann z.B moeglich Programme zu schreiben die im Ram laufen und vom HEW (Der Oberflaeche von Renesas) da reingeladen werden. Ausserdem gibt es noch einen Flashwriter (Renesas, Source verfuegbar) der ist in der Lage beliebige Sachen in das Boot-SPI-Flash zu schreiben. So kann man ein fertiges Programm dauerhaft in die Hardware bekommen, aber auch den Bootloader selber updaten. Nur wenn man sich selber den Bootloader kaputflasht und den Controller ausschaltet wird er danach nicht mehr starten und man muss erstmal das SPI-Flash extern herstellen! Wer das ganze im Detail nachlesen will die Applikation heisst: rej06b0867_sh7262_sh7264ap.pdf Und sollte hier zu bekommen sein: http://america.renesas.com/support/downloads/download_results/C2016701-C2016800/an_rej06b0867_sh_sboot.jsp > Zudem scheint Renasis da auch eine recht restriktive > Lizensierungsstrategie zu fahren, wenn ich z.B. lese, daß ich für die > Nutzung der Hardwaredebug-Funktion eine extra (kostenpflichtige) Lizens > benötige... Gib mal eine Quelle. Ich sehe im Moment nicht fuer was ich eine Lizenz benoetige und was ich nicht kann. Was ich sehe das ich vollkommen kostenlos eine sehr leistungsfaehige Oberflaeche verwenden kann die alles kann was man sich wuenschen kann. > Auch wenn er auf den 1. Blick vielversprechend aussieht, warum solch > einen exotischen Prozessor verwenden? Nach den Problemen mit > verschiedensten Renesasprozessoren, die ich in der Firma immer wieder > sehen muß, käme für mich solch ein Prozessor nie in Frage, auch wenn man > die Entwicklungskits zur Zeit regelrecht hinterhergeworfen bekommt. Ich setze Renesas auch seit Jahren ein und habe bis auf ein kleines Problem mit I2C an einem Port eines R32C116 noch kein unloesbares Problem gehabt. Anderer Probleme waren bis jetzt immer loesbar, das auch oft unter freundlicher Hilfe vom Distributor. > Ich halte das auch für mutig auf so einen Exoten zu setzen. Den Prozessor selber halte ich nicht fuer Exotisch. Ist halt ein SuperH. Dieser spezielle Typ ist sicher exotisch weil er halt fuer Audiokram optimiert ist. Aber dafuer bekommt man halt eben auch die ganzen Spezialfunktionen. > Der mag für kommerzielle Autoradios ganz nett sein, aber > für Open Source Projekte gelten andere Anforderungen. Welche? > Gibt es z.B. überhaupt einen > Open-Source-MP3- und AAC-Decoder für den Prozessor? Ich kenne mich mit MP3 nicht so aus, aber ich meine ich haette einen Link dazu gepostet. > Aber SH2(-A) hat DelayedBranches, also etwas knifflig zu progr.! Ist das nicht piepegal? Bei so einem Prozessor wird doch niemand mehr als 10-20Assemblerinstruction hintereinander schreiben. Um den Rest soll sich bitte der Compiler kuemmern. > Vielleicht so'n RX nehmen --ist General Purpose, sehr schnell, hat Waer mir noch zu neu. Olaf
> Ich votiere aus o.g. Gründen eindeutig GEGEN die Renesas CPUs
Sehe ich das richtig das du vor allem deprimiert bist weil du nicht so
einfach alles unter Linux machen kannst?
Nun setze ich ja auch zu 95% Linux ein, aber das ist fuer dieses Project
vollkommen irrelevant weil die Idee darin besteht mit anderen Leuten
ZUSAMMENZUARBEITEN und du willst doch jetzt nicht allen vorschreiben auf
Linux umzusteigen nur damit es genauso wie bei dir laeuft oder?
Olaf
Ich verfolge diesen Thread schon eine Weile und bin verblüfft wie hier im Handstreich eigene Meinungen durchgesetzt werden. Der Renesas mag technisch toll sein, aber das er hierzulande kein Exot ist halte ich für eine ziemlich isolierte Meinung. Sicher gibt es Leute die damit arbeiten, aber verglichen mit ARM ist die Verfügbarkeit von Tools jeder Art recht bescheiden. Wer das nicht hören will darf sich dieser Richtung gerne zuwenden, sollte aber akzeptieren das andere diese Meinung nicht teilen und diese Leute dann nicht als verbohrt hinstellen. Offenheit funktioniert immer in beide Richtungen.
Ok es gibt freie Compiler für die SuperH von Renesas. So lange es einen Kostenfreien Compiler gibt, gibt es von mir grünes Licht!
Jens schrieb: > Ich verfolge diesen Thread schon eine Weile und bin verblüfft > wie hier im Handstreich eigene Meinungen durchgesetzt werden. An dem System ist noch fast nichts wirklich 100% fest. Das einzige was in meinen Augen echt fest ist (oder?) ist die Art und Weise wie man mit den vielfältigen Interessen umgeht: Ich denke wir haben einen guten Kompromiss zwischen den beiden Lagern gefunden und der Vorschlag kam nicht von mir alleine. Ein reines aber gutes Autoradio (konservativerer und übersichtlicherer Ansatz) und einen multimedia CarPC (modernerer Ansatz) lässt sich sonst nicht so wirklich unter einen Hut bringen. Die einen wollen Touchscreen, Kopfstützenmonitore, etc., die anderen wollen sowas auf gar keinen Fall, andere wollen sich wieder die option offen halten. Den Multimediaansatz find ich nicht uninteressant (z.B. Wlan sync), aber ich würde primär erstmal gerne ein verdammt gutes und stabiles Autoradio bauen. Mit einer API kann man dann vom PC aus (für die Entwicklung) oder auch mit einem "Linux Modul" das Radio fernsteuern. Für die Linuxer ist das doch bestimmt auch einfacher. Sie müssen nicht viel im Kernel mode basteln sondern können das Radio komplett von user mode aus über UART (als Beispiel) fernbedienen. Und sie müssen sich nicht mehr mit den Problemen der Radiowelt auseinandersetzen sondern können es einfach als Blackbox ansteuern. Bzw. bei Nutzung einer Uart schön auf dem PC entwickeln und testen. Weiterhin haben wir schon ganz am Anfang gesagt das man abstimmt, aber niemand hat sich getraut ein paar Striche ins Wiki [1] zu tippen. Wenn man keine demokratische Rückmeldung bekommt und weiter kommen will muss man an einem gewissen Punkt einfach entscheiden. [1] http://osar.it-livetalk.de
Mathias A. schrieb: > Auf die Tunerplatine dann nur einen kleinen Controller setzen, der z.B. > die RDS-Dekodierung, Abfragen von Tasten/Drehgebern etc. übernimmt. Das > hätte auch den Vorteil, diese (zeitkritischen) Steuerungsaufgaben von > dem Controller der die Signalverarbeitung macht abzukoppeln (Olaf hatte > ja auch bereits angesprochen, dass das eine Herausforderung werden > könnte). RDS braucht -wenn man es gut machen will- relativ viel Speicher. Das Basisfeature follow me (beste Frequenz finden) an sich ist schon echt nicht ohne und nicht schnell nebenbei am Schreibtisch designed. Ein AtMega dürfte da aufgrund des geringen RAMs überfordert sein. Wenn man Frequency diversity zur Empfangsverbesserung einsetzen will braucht man sogar noch deutlich mehr Ressourcen.
@Kai Der SuperH ist eine der besten Lösungen wenn man mal von diversen ARMs im BGA absieht. Außerdem der Olaf spielt schon mit dennen. Ich würd ned immer alles über UART machen wollen es gibt ja auch noch SPDIF usw. Echtzeit schließt nicht unbedingt Linux oder so aus !
Patrick Weinberger schrieb: > @Kai > Der SuperH ist eine der besten Lösungen wenn man mal von diversen ARMs > im BGA absieht. Außerdem der Olaf spielt schon mit dennen. Ja, ich bin auch immer noch für den/die SuperHs. Ich nutz zwar Linux, aber programmieren tu ich meist unter Windows, insofern würde mich der fehlende GCC nicht stören. Zumal der Support für diese Architektur mit Sicherheit auch noch irgendwann mal kommen wird! Wenn Arm und BGA wär ich eindeutig für den LPC2888 von NXP. Aber leider nichtmal nur ein BGA, sondern sogar ein FBGA... > Ich würd ned immer alles über UART machen wollen es gibt ja auch noch > SPDIF usw. Klar, Line in-out (digital oder analog) sollte extra laufen. Wenn man auf die SD Karte vom Mainboard zugreifen wollte müsste man evtl. auch noch über eine weitere Schnittstelle nachdenken, wobei die Linux-Leute wahrscheinlich besser einen eigenen Massenspeicher nutzen. > Echtzeit schließt nicht unbedingt Linux oder so aus ! Ja, ich weiß!
Bezüglich Prozessor: Ich brauche kein Linux. Es wäre aber schön, wenn ich trotzdem die Möglichkeit habe, dieses einzusetzen. Worauf es mir aber ankommt: - Für einen Hobbyelektroniker mit beschränktem Werkzeugpool noch lötbar; kein BGA und QFN - Finepitch ist aber kein Problem (sollte halt herausragende Pins haben, die man mit dem Lötkolben erfassen kann). - Frei verfügbare Entwicklungsumgebung (gcc mit Bibliotheken; idealerweise gdb). - Kostenloses oder kostengünstiges Programmiertool. - Keine Einschränkungen in der Codegröße - ich möchte auch den kompletten Prozessor nutzen können und nicht dafür viele Euros aus der Hand geben müssen. - Kein NDA um an die Datenblätter zu kommen. - Verfügbarkeit auch für Hobbyelektroniker ohne Firma. Optional: - Gerne auch kostenlosen oder kostengünstigen Debugger. Wenn der Renesas das abdeckt, bin ich immer noch dabei.
Christian H. schrieb: > - Frei verfügbare Entwicklungsumgebung (gcc mit Bibliotheken; > idealerweise gdb). Heißt frei denn das es der GCC sein muss?
Es gibt den KPIT GNU compiler und sourcerey G++ Lite. Beide sind freie compiler aber man hat keinen Support. Zum Debugger: Der Olaf hat einen Debugger, mit dem kann man sich sicher zusammen reden. MFG
>Der Renesas mag technisch toll sein, aber das er hierzulande >kein Exot ist halte ich für eine ziemlich isolierte Meinung. Falsch. Renesas spielt weltweit in den obersten Rängen der Mikrocontroller-Firmen. Man könnte höchstens spez. Derivate von Ren. als Exot bezeichnen (vielleicht weil schlecht kaufbar o.ä.), aber nicht deren ganze CPU-Familien.
MCUA schrieb: >>Der Renesas mag technisch toll sein, aber das er hierzulande >>kein Exot ist halte ich für eine ziemlich isolierte Meinung. > Falsch. > Renesas spielt weltweit in den obersten Rängen der > Mikrocontroller-Firmen. > Man könnte höchstens spez. Derivate von Ren. als Exot bezeichnen > (vielleicht weil schlecht kaufbar o.ä.), aber nicht deren ganze > CPU-Familien. Man muss sagen das für den AVR, PIC oder vielleicht noch ARM User ein gewahltiger Sprung ist wenn man auf zB die SuperH Serie umsteigt. Wer von euch benutzt Blackfins ? Ich glaub niemand weil einfach das Gehäuse nichts mehr für Hobbiesten ist. lg Patrick
Olaf Kaluza schrieb: >> Ich votiere aus o.g. Gründen eindeutig GEGEN die Renesas CPUs > > Sehe ich das richtig das du vor allem deprimiert bist weil du nicht so > einfach alles unter Linux machen kannst? > Siehst du Falsch! Mir ist das Ding zu exotisch! *kein offizieller GCC...etc *die Software auf der Renases-Seite scheint mir keinesfalls kostenlos. Alles dort ist als Trial-Version gekennzeichnet - also irgenwie kastriert. Sorry!....offen ist anders. ...und natürlich ist mir der Gedanke mit dem Bootloader auch bereits gekommen. sag mal Olaf!....arbeitest du bei Renases in der Marketing-Abteilung? Harry
Bei Blackfin gibt es rel wenig Derivate, den kann man nicht mit anderen gut verbreiteten Controllern vergleichen. Blackfin würde ich, wenn überhaupt, nur für DSP-Spezialaufgaben nehmen, nicht als Haupt-Prozessor. Ich denke, von kleinen 8 bittern auf (die meisten) 32 bitter ist der Sprung weitaus grösser, als ein Sprung innerhalb 32 bitter. Aber ich würde nicht einzelne Periferiteile (wie beim hier diskut. SH2-A) als ausschlaggebenden Grund für CPU Wahl nehmen, ich würde eher eine CPU wählen, die vieleicht auch GeneralPurpose'd besser aufgestellt ist, (wäre dann universeller), denn so hohe Stückzahlen werden's ja (wahrscheinlich) nicht. Da würd ich mir den RX noch ansehen .
Wenn es nach mir ging würd ich am Liebsten einen ARM Cortex A5 verwenden, leider ist der noch nirgends zu bekommen. So ein OMAP L138 wär auch schön aber BGA gehäuse ....
Wozu überhaupt so eine "fette CPU" auf dem Mainboard? Haben wir uns von dem modularitäts-Gedanken jetzt wieder verabschiedet? Nur wegen der I²S-Ports?....Das wird ja wohl auch anders gehen. Und nochmal: der Renases ist alles andere als offen, solange Renases selbst der einzige Lieferant von Software ist. Selbstbauprojekte mit den Dingern findet man im Netz auch so gut wie nicht. Wir wären also echte Pioniere, und auf uns selbst gestellt. Zum Experimentieren ist sowas ja ganz nett, aber, wir wollen ja irgendwann auch mal ein benutzbares Radio haben. Auf der anderen Seite gibt es für ARM oder AVR32 jede Menge Code, und entsprechend viele Leute, die damit bereits Erfahrung haben. Harry
AVR die mag ich ned früher gabs mal die geilen AVR32 mit 150MHz + aber heut nimmer deswegen eher ARM9.
Harald L. schrieb: > sag mal Olaf!....arbeitest du bei Renases in der Marketing-Abteilung? <sozialarbeitermodus> Och Leute, seid doch nett zueinander. Geht raus, tankt ein bißchen Sonnenstrahlen (=Glückshormone) und kommt zurück ;-) </sozialarbeitermodus>
Kai G. schrieb: > Übrigens find ich das decoupling schon recht ungewöhnlich, bzw. SEHR auf > Sicherheit gebaut. 10µ, 100n, 10n und 1n in Reihe? Was für Typen sind > das? X7R/NP0/? Gibts zufällig ne BOM wo das drinsteht? Wow, das ist schon mächtig. Normalerweise sollten für mittlere Lasten auch 100n und 10n parallel reichen. Allerdings sind die heutigen Cores bei einzelnen Operationen sehr hungrig. Da kann es die gesammte Versorgung sehr beruhigen, wenn diese Spitzen lokal abgefangen werden. Je näher das an den Vcc Pinnen des Chips passiert, desto weniger kann sich die 'Welle' über die Platine ausbreiten. Auch sind die DC/DC Wandler weniger aufwändig, weil die nicht dermaßen impulsfest sein müssen. Außerdem gibt es im Auto genügend Probleme, dass der DC/DC Wandler von der Eingangsseite her mit Bursts und Surges belagert wird. Wenn der kurz aus dem Tritt gerät, würde das dann gleich auf die CPU durchschlagen. Generell sollten alle keramischen im Auto >100°C abkönnen. Das Dashboard ist mit der heißeste Platz im Auto (Sonne!). Also X7R ist für alles entkoppelnde perfekt. (Wer jetzt nicht weiß, wovon wir reden: http://en.wikipedia.org/wiki/X7R) Außerdem ist X7R bei vielen Bestückern vorrätig. Gruß, Ulrich
Klare Frage: Was soll der Controller machen? Mit dieser Info kann man etwas passendes raussuchen. Es scheint in dieser Diskussion 2 Zielrichtungen zu geben (man korrigiere mich falls ich das falsch sehe): 1) Ein Controller der den/die Tuner steuert und über ein Interface von außen parametriert wird und dort seine (RDS-)Daten abliefert. Der 'äußere' Controller steuert dann das Bedieninterface, andere Komponenten des Radios und übernimmt wenn er üppig dimensioniert ist evtl. auch gleich die MP3-Dekodierung. Eine digitale Signalverarbeitung ist bei dieser Variante höchstens in einem eigenen Schaltkreis, Controller, DSP oder was auch immer möglich (der dann vermutlich auch von außen gesteuert wird). Der äußere Controller bindet die spezialisierten Controller sozusagen zusammen. 2) Dann gibt es die Variante wo der Controller den Tuner steuert und gleichzeitig die MP3-Funktionen und warscheinlich auch noch die Signalverarbeitung (Klangregelung usw.) machen soll. Wenn außen nichts dran hängt macht er auch noch das Bedieninterface, ansonsten wird das vom 'äußeren' Controller gemacht. Der Controller auf dem Tuner kann ggf. das gesamte Radio steuern. Angesichts dieser Varianten verstehe ich die unterschiedlichen Ansichten darüber welcher Controller denn nun passt. Mir wäre Variante 1 sympatischer da die Pakete und damit die Abhängigkeiten kleiner sind. Der Tuner ist etwas günstiger und universeller einsetzbar. Just my 4 ct.
Jens schrieb: > Angesichts dieser Varianten verstehe ich die unterschiedlichen > Ansichten darüber welcher Controller denn nun passt. Mir wäre > Variante 1 sympatischer da die Pakete und damit die Abhängigkeiten > kleiner sind. Der Tuner ist etwas günstiger und universeller > einsetzbar. FULL ACK Harry
1.) Ok also einfach 2 Tuner mit Audio-CODEC -> Digital + Analogoutput. Zur Kontrolle des Tuners einen kleinen Cortex M0. 2.)SuperH für MP3, Audio-Manipulation, gegebenfalls Splitten der Signale auf mehrere Kanäle (zB Kinder hören ein hörbuch auf den Rücksitzen) und Bedienteil (direkt oder indirekt). 3.) Wer einen Car-PC will baut sich noch ein Beagleboard (Mx) oder so ein. Der Soundprozessor (SuperH) kann dann entweder über Spdif oder I2S mit Daten versorgt werden. 3 Probleme 3 Lösungen nach der Step by Step Methode. Also ich wär so zufrieden! Patrick
Patrick Weinberger schrieb: > 1.) > Ok also einfach 2 Tuner mit Audio-CODEC -> Digital + Analogoutput. > Zur Kontrolle des Tuners einen kleinen Cortex M0. Lieber einen M3, zumindest die von NXP haben etwas mehr RAM als die M0 und der wird für RDS und freq. diversity benötigt. z.B. der LPC1754 sollte ausreichend sein. > 2.)SuperH für MP3 [...] > 3.) [...] Beagleboard (Mx) oder so [...] > 3 Probleme 3 Lösungen nach der Step by Step Methode. Also ich wär so > zufrieden! Ja, auf so ein Konzept würd ich mich auch einlassen. Ist noch sauberer getrennt und wahrscheinlich auch einfacher zu debuggen. Der Controller in Punkt 2 sollte dann aber den Master spielen und alles kontrollieren, also das Linux board auch über den Controller in Pkt 2 mit dem Gesamtsystem kommunizieren.
Frage: 2 Tuner mit 2 Audioausgängen oder nur einem (2. Tuner für Diversity und aktualisierte Senderliste)?
Hi Jens, Das ist so nicht ganz einfach auf zu schlüsseln. Um einen Tuner zu steuern und die RDS-Daten auf einen Bus zu senden, braucht es nicht mal einen ATmega0,5... Das kann jeder Controller im Vorbeigehen. So ein DIN-Schacht ist verdammt Eng, wenn man das ganze mal im Zusammenhang betrachtet: Große DC-Drossel, einige DC/DC Wandler, 4 Class-D Endstufen, ein paar Kühlflächen und jede Menge Hühnerfutter für die Entstörung. Beim MP3-Decoding ist es auch so eine Sache. Wenn man ausschließlich auf MP3 aus ist, dann tut es jeder ARM7 mit 50MHz problemlos, vor allem, wenn er über I2S Ausgänge verfügt. Wenn es aber um zusätzliche andere Decoder geht, wird es teilweise eng. Allerdings ist das dann auch mit einem schnelleren oder größeren Controller nicht getan, denn dann müsste man entweder gleich Linux einsetzen und dessen gängige Mediaplayer nutzen oder man muss deren Decoder portieren. Außerdem ist das Programmieren von Codecs nicht jedermanns Sache. Abgesehen davon gibt es da von TI bessere Chips mit DSP Core. Da wäre man mit einem VLSI VSxxxx besser beraten. Die Chips decodieren alle möglichen Streams und man muss sie nur zyklisch mit Daten füttern. Auch das Lizenzpflichtige WMA decodieren sie, man muss es nur aktivieren. Der VLSI1051 hat auch I2S Ausgänge und kann damit in den digitalen Mischer eingebunden werden. Auch der Vorschlag, dass der Renesas mit I2S Ein- und Ausgängen das Soundmixing übernehmen kann ist auf den ersten Blick sicherlich verlockend. Aber nicht jeder kann digitale Filter programmieren. Muss allerdings auch nicht jeder können, es ist ja ein Gemeinschaftsprojekt, da reicht es, wenn es einer der anderen kann. Trotzdem gibt es dafür, gerade von NXP, ausgezeichnete Chips. Die beherrschen dann auch das Mischen und Überblenden von Kanälen, wenn es um die Freispreche oder das Navi geht. Die CPU könnte dann noch ein 'Bing' oder 'Beep' beisteuern für besondere Funktionen. Wenn man die Grenzen des Projektes fest umreißt, dann kann man auch die CPU festlegen. Soll das Ding letztendlich 'nur' ein MP3-Radio werden, dann ist der Renesas zu groß, bzw hat mit seinen wenigen I2S Fähigkeiten sogar zu wenig Kanäle um einen separaten Audio-Mixer überflüssig zu machen. Will man nach oben hin offener sein, also eventuell Video erlauben, dann ist er zu klein, wenn man nicht auf fertige DVD-Video Laufwerke zurück greifen kann. Also, wenn MP3-Radio, dann CortexM3, kleiner AVR32 oder SAM7. Wenn mehr, dann ARM9/11 oder CortexAx oder großer AVR32. Wenn All-In-One Lösung, dann TMS32xxx Serie, eventuell sogar mit Software-Defined-Radio. Mal ehrlich, wenn es um ein MP3-Radio geht, dann reicht ein kleiner STM32 oder ein AT90USB128 völlig aus, wenn man die Tuner, einen VLSI Decoder, einen Audio-Multiplexer und ein paar Endstufen dazu packt. Er hat USB-OTG, kann also USB-Sticks auslesen. SPI für SD-Cards und VLSI, I2C für die Tuner und den Mixer. Ein Serial-Flash für die bunte Grafik auf dem Display, beides per SPI angebunden oder das LCD/OLED per Parallelbus. Dann kann man ungenutzten Grafikspeicher gleich noch als RAM verwenden. Hab ich noch was vergessen? Wer viele Knöppe mag, kann noch einen PCA9555 I2C-Parallel Chip nehmen und hat zusätzliche 16 Leitungen. Mit dieser Lösung und meinem DVD Laufwerk ist dann sogar MP3 von Scheibe (auch DVD) und Video mit möglich. Würde mir fast ausreichen. Vermutlich ist es mit einem STM32F103 besser ausgestattet, zumal der auch noch CAN hat. Ob ARM7/9 nun veraltet ist und man unbedingt auf CortexMx oder Ax aufsetzen muss, darüber kann man diskutieren. Alle bezahlbaren ARM CPUs können mit OpenOCD programmiert und GDB debuggt werden. Man muss also für nicht tief in die Tasche greifen. Bei STM32 bin ich mir noch nicht sicher. Die ganzen bei ST genannten Compiler sind nur bis 64k Code frei, dann kostet es Geld. Wenn einer einen gcc für STM32 kennt, ich wäre sehr daran interessiert. Gruß, Ulrich
Ach so... Es ist eigentlich egal, welchen Prozessor man einsetzt oder ob man es auf verschiedene CPUs verteilt. Wenn sauberer C-Code geschrieben wird und jedem Chip seine API gegönnt wird, ist die Hardware Plattform in weiten Teilen egal. Man muss ich halt einfach seine eigene kleine Abstraktion für seinen Prozessor schreiben und kann dann den eigentlichen Chip-Treiber gleich verwenden. Womit ich dann noch mal Nut/OS ins Spiel bringe :) Gruß, Ulrich
Wie beim Objektorientierten Programmieren. Also wenn ich es mal in Level unterteilen darf: Level 1: Tuner, Verstärker und Powermanagment Level 2: SuperH oder Spezielle Audio-Dsp Level 3: Bedienteil am Radio mit Display oder/und Car-PC-Board Ein Teil des Level 2 kann nur Device des Level 1 ansteuern. Wobei es zwischen den Leveln fest definierte Schnittstellen gibt welche wie eine Art Fasade wirken. Also Level 3-> Level 2 -> Level 1
Ulrich P. schrieb: > Das ist so nicht ganz einfach auf zu schlüsseln. Um einen Tuner zu > steuern und die RDS-Daten auf einen Bus zu senden, braucht es nicht mal > einen ATmega0,5... Ich finde der Tuner sollte nicht nur die Daten durchschicken, sondern auch dekodieren und interpretieren. Dann ist etwas größeres als ein Atmega schon hilfreich. > Trotzdem gibt es dafür, gerade von NXP, ausgezeichnete Chips. Die > beherrschen dann auch das Mischen und Überblenden von Kanälen, wenn es > um die Freispreche oder das Navi geht. Ja, solche Chips hatte ich vorhin gesucht. Ich weiss das es sie gibt, hab auch schonmal sowas eingesetzt, aber ich finde es echt nicht wieder. Mit integriertem Tuner oder so => kein Problem, find ich, aber nur mixing/equalizing => Pustekuchen. Ansonsten stimme ich Dir zu...
Kai G. schrieb: > Christian H. schrieb: >> - Frei verfügbare Entwicklungsumgebung (gcc mit Bibliotheken; >> idealerweise gdb). > > Heißt frei denn das es der GCC sein muss? nein, ich nehme auch andere, für die ich nichts bezahlen muss. Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch unter Mac OS-X) verwenden kann.
Ok, das ist die andere Sichtweise. Ich meinte das eher so: Level 3: Applikation Radio Level 2: Tuner, Filesystem, Display, Tasten Level 1: Tuner->I2C Control, Filesystem->USB, Grafix/Text->SPI/Databus->Display, Tasten->I2C MatrixDriver... Level 0: API I2C, API SPI, API GPIO, API... Wenn ich dann eine andere CPU verwenden will, dann muss ich nur Level 0 und vielleicht ein paar Dinge in Level 1 anpassen. Fertig. Patrick, Du meinst sicher, dass die Software auch sinnvoll in Tasks aufgeteilt ist und dort bestimmte Dinge nur von einem bestimmten Task erledigt werden sollten. Diese Sicht verhindert immer noch nicht, dass einer entscheiden kann, dass ein Task von der CPU erledigt werden kann, auf der auch alle anderen Tasks laufen und ein anderer diesem Task eine eigene CPU spendiert. Wichtig ist immer, wer redet mit wem, wer kontrolliert wen. Viele Tasks werden immer laufen, ob ihre Nachrichten vom Haupt-Task dann weiter verarbeitet werden, oder nicht, entscheidet der dann anhand von Benutzervorgaben. So würde der RDS Task immer laufen, denn der erkennt das Bit, dass Verkehrsnachrichten kennzeichnet und stellt die Liste der alternativen Frequenzen. Ob das aktivierte Bit nun dazu führt, dass der Master dem USB-MP3 Task sagt, er soll anhalten, weil er jetzt auf den Tuner wechselt, liegt daran, ob der Benutzer TM Aktiviert hat. Natürlich kann der USB-MP3 Task anhalten, wenn Radio läuft, aber der Tuner muss weiter laufen, damit er im Hintergrund immer auf der richtigen Frequenz bleibt und RDS/TMC laufen. Gruß, Ulrich
Christian H. schrieb: >> Heißt frei denn das es der GCC sein muss? > nein, ich nehme auch andere, für die ich nichts bezahlen muss. > Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch > unter Mac OS-X) verwenden kann. <ironie>und noch Amiga-OS (ab Kickstart/Workbench 1.4) und CPM</ironie> SCNR
Ulrich das mein ich ned. Ich wollt damit sagen jede Schicht über eine bestimmte Schnittstelle verfügt welche nach definition nicht mehr geändert werden darf. So kann man das Modul einfach ersetzen. Bei der Software würd ich mit objektorientierten C arbeiten. Mfg Patrick
> So würde der RDS Task immer laufen, denn der erkennt > das Bit, dass Verkehrsnachrichten kennzeichnet und stellt die Liste der > alternativen Frequenzen. Ist übrigens nicht nur 1 Bit, sondern 2 die für Verkehrsnachrichten interpretiert werden müssen. Die beiden Bits zusammen geben nicht nur an wie Du sagtest ob bei dem aktuellen Sender gerade Verkehrsnachrichten ausgesendet werden, sondern auch ob man prinzipiell für Verkehrsnachrichten in den EON Informationen nachschauen soll (also bei anderen Sendern aus dem Netzwerk, weil der aktuelle keine oder nur "kastrierte" aussendet). Auch an diesem handling kann man gute und schlechte Radios (bzw. RDS implementationen) auseinanderhalten. Schlechte Radios springen nicht auf andere Sender aus dem aktuellen Netzwerk um wenn sie VKnachrichten aussenden. Solche Fehler bekommt man im allgemeinen nicht direkt mit, höchstens durch den Informationsmangel.
Christian H. schrieb: > Kai G. schrieb: >> Christian H. schrieb: >>> - Frei verfügbare Entwicklungsumgebung (gcc mit Bibliotheken; >>> idealerweise gdb). >> >> Heißt frei denn das es der GCC sein muss? > > nein, ich nehme auch andere, für die ich nichts bezahlen muss. > Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch > unter Mac OS-X) verwenden kann. Du verwechselst Open-Source mit kostenlos!!!! Und zu einem Open-Source-Autoradio gehört auch, daß die verwendeten Toolchains Open-Source und frei verfügbar sind! Harry
Hi Kai, ist schon recht :) Es ging in dem Beispiel um das Tasking und die API, nicht um das Bit speziell. Abgesehen davon wäre es für den Master-Task weiterhin nur ein Bit welches sagt, dass es Nachrichten gibt. Dass es auf mehrere Bits und deren korrekte Konstellation ankommt wäre Aufgabe des RDS-Tasks :) Zur Toolchain kann ich nur sagen, dass es ohnehin schon der teuer wird, die Hardware umzusetzen. Es ist daher belanglos, ob die Toolchain kostenfrei oder OpenSource-kostenfrei ist. Allerdings besteht bei den Nicht-O/S Toolchains immer die Gefahr, dass sie limitiert ist ( nur xxkB Code), dass sie mit der Plattform stirbt, wenn die Nachfrage nicht hoch genug ist oder dass sie nicht auf allen Plattformen einsetzbar ist. Bei GCC kann man immerhin Win/Linux/Mac erschlagen, Amiga und CP/M bleiben wohl aussen vor, fürchte ich. Wenn GCC läuft, dann kann ich meinen Source-Insight einsetzen und ein anderer Eclipse. Ist dann egal. Was ich nebenbei für den STM32 wäre ein gcc, kein kostenlos-Tool. Gruß, Ulrich
Ulrich P. schrieb: > Was ich nebenbei für den STM32 wäre ein gcc, kein kostenlos-Tool. Wie ist das zu verstehen? GCC und alles, was man daraus ableitet unterliegt der GPLv2 und ist damit incl. Quellcode offen, egal, was man damit macht oder wie man das verändert. Harry
ach ja....wenn es für STM32 nur kommerzielle Entwicklungsumgebungen gibt, fällt der ja aus o.g. Gründen dann auch aus. (hab ich aber noch nicht recherchiert) Harry
Ok, da hatte ich noch was vergessen. Die Einwände, dass Renesas nicht so verbreitet ist, kann ich verstehen. Sie sind sicherlich gut vertreten, aber nicht in der 'Bastelnden Schicht'. Daher fehlt es an vielen Dingen, die alle erst einmal neu gemacht werden müssten. Man kann sich das ein oder andere Aus den AppNotes von Renesas zusammen bauen, aber ein eigenes System mit TaskSwitching aufzusetzen, heißt wirklich ganz unten anfangen. Ich würde die Plattform noch mal überdenken. Bei den CPUs sollte man genau so wie bei dem Tuner, ganz genau überlegen, ob man das Risiko eingeht. Die CPU ist in Produktion, aber unter den meisten Lesern unbekannt. Risiko: Einige müssen alles komplizierte machen, bis die anderen einsteigen können. Vorsicht auch bei dem Tuner, der ist im Sample-Stadium. Es kann also noch alle möglichen Bugs beinhalten und wir suchen uns nen Ast ab, bis wir merken, dass es an uns garnicht liegt. Außerdem kann es sein, dass außer uns keiner das Teil kauft, also stampft NXP das Teil wieder ein, bevor die ersten B-Samples draußen sind. Naja, NXP ist nicht Maxim, also besteht Hoffnung. Ich habe keinen Kommentar bzgl. Nut/OS (www.ethernut.de) gehört, aber Atmel wird schon vollständig unterstützt. Da könnte man bei der Wahl der CPU in gewissem Rahmen auch Freiheiten erlauben. Der reine SD-Card MP3-Radio Bastler nimmt einen ATmega128, der Fullfeatured Basteler einen SAMx/AVR32. Die Bausteine sind verfügbar, die Treiber existieren, Taskswitching, Semaphoren und Mailboxen gehen auch. Auch TCP/IP ist dabei. An LCD/OLED schreibe ich gerade. Damit wäre die Diskussion um die CPU überflüssig. Wer es gerne mit der groben Kelle mag, der portiert Nut/OS auf den Renesas, warum nicht. Gruß, Ulrich
...und ich kann für den STM32 nichts freies finden. Damit hätten wir einen Kandidaten weniger. Harry
Harald L. schrieb: > Ulrich P. schrieb: >> Was ich nebenbei für den STM32 wäre ein gcc, kein kostenlos-Tool. > > Wie ist das zu verstehen? > GCC und alles, was man daraus ableitet unterliegt der GPLv2 und ist > damit incl. Quellcode offen, egal, was man damit macht oder wie man das > verändert. > Das ist mir klar. Einfach ausgedrückt, freue ich mich über jeden freien kostenlosen Compiler, aber am liebste.... So ein Quatsch, ich bin in meinen Projekten etwas durcheinander geraten. Die Compiler waren ein Problem bei den STM8. Der STM32 ist ein CortexM3 und der GCC funktioniert damit wunderbar. Ich ziehe meine Frage also zurück :) Sorry!
www.ethernut.de sieht sehr vielversprechend aus! Ich werd im Wiki mal einen Hinweis einbauen. Harry
Danke Harry! http://sites.google.com/a/stf12.net/developer-sw-fw/eclipse-demo Zeigt GCC zusammen mit STM32. Der Vorteil der ST CPUs ist, dass sie sehr günstig sind. Sie sind schnell und auch gut mit Peripherie ausgestattet. ST ist auch im Automotive Bereich gut platziert. Ich muss für die Dinger vermutlich eh das Nut/OS portieren, da ich sie beruflich einsetze. Mein EIR und damit auch meine erste Idee den genannten Tuner einzusetzen basieren auf Nut/OS, also wird es einen Treiber dafür geben. Auch ein breitformatiges LCD oder OLED wird es geben, bzw dessen Ansteuerung. Viele andere Sachen sind schon drin. Gruß, Ulrich
Ulrich P. schrieb: > Die Compiler waren ein Problem bei den STM8. Der STM32 ist ein CortexM3 > und der GCC funktioniert damit wunderbar. Ich ziehe meine Frage also > zurück :) Ahh....damit ist der STM32 wieder im Rennen ;) Harry
Hallo, finde die Diskussion äußerst Interessant. Bin sehr an dem Radio interessiert kann aber wahrscheinlich nur wenig dazu beitragen. Möchte es aber auf jeden Fall auch aufbauen. Ich kann mir auch vorstellen, dass es vielen anderen ähnlich geht. Jetzt aber zum Grund meines Geschreibsels. Ihr diskutiert hier gerade über die CPU und es wird immer nur MP3 als Format neben dem Radio erwähnt. Gerade in einem Open-Source Radio finde ich es eigentlich unerläßlich, auch OGG und FLAC zu unterstützen. Ich habe z.B. den größten Teil meiner Musik im Flac Format gespeichert. Ich möchte sie eigentlich nicht jedesmal umkodieren, wenn ich sie mit in's Auto nehmen möchte. Wenn ich dran denke, das mein Sansa Player mit Rockbox drauf diese Formate anstandslos abspielt, und da sicher keine Super CPU drin ist, sollte das hier doch eigentlich auch möglich sein. Schließt aber natürlich Hardware MP3 Dekoder aus. Übrigens müsste man doch, was Implementierung von Codecs angeht, vom Rockbox Projekt einiges übernehmen können?! Just my 2 Cent Gerhard
Der Vorteil von Nut/OS wäre der gleiche wie bei Linux, das System wird separat von der Applikation entwickelt. Also alle Chips und deren API werden im System gepflegt, das Radio selbst wird separat in einem eigenen Repository gehalten. Wer mitmachen will, lädt sich die Quellen des Systems, macht einen Build und lässt das Applikationsverzeichnis erzeugen. In letzteres lädt er dann die Radio-Applikation und kompiliert sie. Dann noch flashen und fertig. Wer einen anderen Tuner Chip oder ein anderes Display verwenden will, schreibt eben seinen eigenen Treiber und macht die API OS-Konform. Dann braucht es auch nur wenige Anpassungen in der Appliaktion ( Größe, Zeilenanordnung, Schrifttype) und schon läuft es wieder. Gruß, Ulrich
Gerhard Zintel schrieb: > Hallo, > > finde die Diskussion äußerst Interessant. Bin sehr an dem Radio > interessiert kann aber wahrscheinlich nur wenig dazu beitragen. Möchte > es aber auf jeden Fall auch aufbauen. Ich kann mir auch vorstellen, dass > es vielen anderen ähnlich geht. So würde ich das nicht sehen. Hier lesen und schreiben alle drei Gruppen. Die, die glauben, dass das alles einfach ist, die denen die Idee schon zu komplex erscheint und die, die wissen, was das alles bedeutet, bzw. das oder ähnliches schon mal gemacht haben. Schau mal was passiert und Du findest Deinen Mitmach-Punkt. > > Jetzt aber zum Grund meines Geschreibsels. Ihr diskutiert hier gerade > über die CPU und es wird immer nur MP3 als Format neben dem Radio > erwähnt. Gerade in einem Open-Source Radio finde ich es eigentlich > unerläßlich, auch OGG und FLAC zu unterstützen. Ich habe z.B. den > größten Teil meiner Musik im Flac Format gespeichert. Ich möchte sie > eigentlich nicht jedesmal umkodieren, wenn ich sie mit in's Auto nehmen > möchte. > > Wenn ich dran denke, das mein Sansa Player mit Rockbox drauf diese > Formate anstandslos abspielt, und da sicher keine Super CPU drin ist, > sollte das hier doch eigentlich auch möglich sein. Schließt aber > natürlich Hardware MP3 Dekoder aus. > Das ist falsch, sorry: http://www.vlsi.fi/en/products/vs1053.html Ogg Vorbis MP3 = MPEG 1 & 2 audio layer III (CBR+VBR+ABR) MP1 & MP2 = MPEG 1 & 2 audio layers I & II optional MPEG4 / 2 AAC-LC(+PNS), HE-AAC v2 (Level 3) (SBR + PS) WMA4.0/4.1/7/8/9 all profiles (5-384 kbps) FLAC lossless audio with software plugin (upto 24 bits, 48 kHz) WAV (PCM + IMA ADPCM) General MIDI 1 / SP-MIDI format 0 > Übrigens müsste man doch, was Implementierung von Codecs angeht, vom > Rockbox Projekt einiges übernehmen können?! > Auch das ist sicherlich eine Lösung. Der Software-Stack des Elektor Internt Radio funktioniert auch auf einem SAM7X256 Board mit einem TI-AudioCoDec als DAC. Der SAM7X macht das Decoding in Software und nutzt dazu einen GPL Decoder. Das Nut/OS selbst ist BSD, sieht für GPL Code aber ein besonderes Verzeichnis vor, dass auf diesen Umstand hinweist. Es ist also möglich BSD und GPL Code zu mischen. Es könnten also auch andere Codecs portiert werden, ohne die GPL zu verletzen. Aber wenn wir auf einen Software-Decoder gehen und dann jeder seine Wünsche für die Formate einklagt, dann landen wir doch wieder bei einem 400MHz ARM oder einem Atom und Linux. Ich denke, die Trennung von CoDec und CPU löst eine ganze Menge Probleme, vor allem für die Mitmacher, die noch nicht 20 Jahre Assemblern und Coden und mal eben auswendig das Framing von MPEG aufschreiben können. Außerdem kann man sich recht schnell auf die eigentliche Sache, das Radio, konzentrieren. Also, nicht übel nehmen, ich kann nachvollziehen, dass man das ganze in einer schnellen großen CPU verarbeiten möchte. Aber ich fürchte, dass die Nachbaubarkeit und die Verstehbarkeit darunter leidet und der Zugang zu den Innereien des OSCARs nur wenigen vorbehalten bleibt. Aber je weniger dabei von Anfang an mitmachen, desto schnell verläuft das ganze auch im Sande.
Patrick Weinberger schrieb: > Ich würd da eher die Luminary bevorzugen, sind etwas schneller. Hmmm, Luminary wird auch gerne zusammen mit dem VLSI eingesetzt :) http://www.watterott.net/projects/webradio-arm
>Man kann sich das ein oder andere Aus den AppNotes von Renesas >zusammen bauen, aber ein eigenes System mit TaskSwitching aufzusetzen, >heißt wirklich ganz unten anfangen. Es gibt doch verschiedene RTOS's, bsp RTEMS, UCOS... , die mit den meisten 32 Bitern gehen. (und das meiste (nicht Scheduler) von RTOS's ist auch meistens in C) ----------------- Bei Coldfire gibts auch Controller mit Audio-Schnittstellen, zB MCF5249 (kostet ca 12eu bei EBV, ist aber kleiner als der SH2A..., ca 125 MIPS, ca 100kB SRAM). Manche Coldfire's werden oft auch im ConsumerMarkt eingesetzt, sind auch alle langfristig verfügbar, ähnlich den legendären 68K-CPUs.
@Ulrich brauch ich bei Nut/OS wirklich dieses ominöse nutconf, wenn ich die libs im Eclipse verwenden will? Auf meinem 64bit-System bekomm ich nämlich einen Segfault. Wenn ich das richtig seh, sollen die doch nur den Input für autoconf und automake generieren. Harry
@Harald: Nein, Du kanst das nuconfigure auch so laufen lassen, oder Dir das qnutconf über Qt generieren. Das NutConf ist schon sehr alt und wird wohl durch qnutconf abgelöst. Traditionell war der code für nutconf immer dabei und man hat es sich selbst generiert. Das ist auch bei qnutconf so. Ich werde mich mal dafür einsetzen, dass es qnutconf auch als binary irgendwo gibt. Ich kann es aktuell aber nur für 32bit win anbieten. Ich habe kein 64bit System.
> Trotzdem gibt es dafür, gerade von NXP, ausgezeichnete Chips. Die > beherrschen dann auch das Mischen und Überblenden von Kanälen, wenn es > um die Freispreche oder das Navi geht. TI (auch NAT,AD) haben da auch CoDecs.
Ulrich P. schrieb: > @Harald: > Nein, Du kanst das nuconfigure auch so laufen lassen, oder Dir das > qnutconf über Qt generieren. Das NutConf ist schon sehr alt und wird > wohl durch qnutconf abgelöst. Traditionell war der code für nutconf > immer dabei und man hat es sich selbst generiert. Das ist auch bei > qnutconf so. Ich werde mich mal dafür einsetzen, dass es qnutconf auch > als binary irgendwo gibt. Ich kann es aktuell aber nur für 32bit win > anbieten. Ich habe kein 64bit System. ahh...ok...ich wollte eigentlich für Nut/OS ganz auf dieses autoconf/automake verzichten. Ich mach mir Eclipse-Projekte da raus. So langsam seh ich da auch schon ein wenig durch. Ethernet-Hardware hab ich zwar nicht hier rumliegen, aber das Multithreading will ich mal testen. Das scheint mir doch sehr spannend zu sein. Aber das qnutconf werd ich mir dann auch mal beschaffen. Achso....das ist übrigens 64bit-Linux ;) Harry
Das ist ja das Problem, wenn man einen allgemeinen Configurator bauen will. Java scheidet aus, weil das ein riesiger Ballast ist, den man dann immer mit sich herum schleppt. Aber wenn man dann einen Installer oder Konfigurator haben will, dann muss man ihn für 4..6 Systeme kompilieren, die man auch erst mal haben muss. Du kannst auch die nutconfigure Datei manuell anpassen und dann das make abfahren. Die Brücke zischen den Einsteigern und den Profis ist halt immer ein architektonisches Meisterwerk :) Da das Nut/OS Modular ist, kannst Du natürlich auch das nutnet raus lassen, wenn Du kein Ethernet hast oder brauchst. Auf einem Treffen der Nut/OS Gruppe nach der letzten Embedded nannte jemand irgendwas um 1.5k für den Kernel des Nut/OS auf den er es geschrumpft hatte. Finde ich beachtlich, repräsentiert aber eben die Idee hinter dem System. So, ich mach mich mal auf in die Horizontale... Bis Morgen!
Ulrich P. schrieb: > Das ist ja das Problem, wenn man einen allgemeinen Configurator bauen > will. Java scheidet aus, weil das ein riesiger Ballast ist, den man dann > immer mit sich herum schleppt. Aber wenn man dann einen Installer oder > Konfigurator haben will, dann muss man ihn für 4..6 Systeme kompilieren, > die man auch erst mal haben muss. > Du kannst auch die nutconfigure Datei manuell anpassen und dann das make > abfahren. > ich hab die Win-Version unter Wine laufen.....sehr fein! Da werd ich mich eingehender mit beschäftigen. Danke für den Tip! Und JA!...das ist auch für unser Autoradio interessant! Harry
Ist ja schön das wir jetzt ein Betriebssystem haben (auch wenn ich den ganzen Ethernet kram lieber draussen sehen wollte), aber das war doch erstmal nicht das kernproblem, oder? Ich habe das Gefühl das wir das System künstlich mehr und mehr vergrößern und nachher entweder eine Platine erhalten mit 10 großen ICs die sich fast nicht mehr routen lässt und man womöglich auf >= 4 LAyer gehen muss, oder wir kriegen zig einzelplatinen und für ein Grundsystem braucht man schon 4 oder 5 Platinen.
Kai G. schrieb: > Christian H. schrieb: >>> Heißt frei denn das es der GCC sein muss? >> nein, ich nehme auch andere, für die ich nichts bezahlen muss. >> Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch >> unter Mac OS-X) verwenden kann. > > <ironie>und noch Amiga-OS (ab Kickstart/Workbench 1.4) und CPM</ironie> > > *SCNR* Das war kein Scherz. Ich habe zuhause drei Systeme, die ich wechselseitig nutze. Hauptsächlich aber Linux und Mac OS-X. Ok, wenn es nur unter Windows funktioniert, muss halt VirtualBox herhalten. Mein Amiga steht noch bei meinen Eltern auf dem Dachboden. Workbench 1.2, wenn ich mich recht erinnere. CPM geht nicht mehr, da ich meinen Commodore 128D vor langer Zeit verkauft hatte ;-) Wäre auch zu viel verlangt.
Harald L. schrieb: > Du verwechselst Open-Source mit kostenlos!!!! Nein, ich spreche in diesem Satz speziell von kostenlosen Programmen; ob Open-Source oder nicht. > Und zu einem Open-Source-Autoradio gehört auch, daß die verwendeten > Toolchains Open-Source und frei verfügbar sind! Da bin ich ja beruhigt ;-)
Ulrich P. schrieb: > Das ist falsch, sorry: > http://www.vlsi.fi/en/products/vs1053.html > Ogg Vorbis > MP3 = MPEG 1 & 2 audio layer III (CBR+VBR+ABR) > MP1 & MP2 = MPEG 1 & 2 audio layers I & II optional > MPEG4 / 2 AAC-LC(+PNS), HE-AAC v2 (Level 3) (SBR + PS) > WMA4.0/4.1/7/8/9 all profiles (5-384 kbps) > FLAC lossless audio with software plugin (upto 24 bits, 48 kHz) > WAV (PCM + IMA ADPCM) > General MIDI 1 / SP-MIDI format 0 Wie sieht es denn aus? Ist MP3 (und Konsorten; ich spreche im Folgenden der einfachheit halber von MP3) wirklich für jeden ein Muss? Gehört ja eigentlich nicht direkt zu einem Radio, da kein Sender in MP3 sendet. Wenn der Prozessor, der die Grundfunktionen des Radios behandelt, auch MP3 (und Zugriff auf die benötigten Speichermedien) beherrscht, ist es ja in Ordnung. Es ist aber für die Grundfunktion nicht notwendig. Reicht der oben genannte Codes denn nicht aus? Ich bin eher für diesen Bausteil, da man den Prozessor dadurch klein halten kann. Auch ist das Basisboard dann wirklich nur ein Radiomodul mit Komfortfunktion. Das muss dann auch kein Autoradio mehr werden. Ich bin da eher für Modularisierung. 1. Ein kleines Board, welches nur das Radio beinhaltet und per RS232 komplett fernbedienbar ist. 2. Ein zweites Board, welches die Audio-Verarbeitung (Filter, MP3, ...) macht. 3. Ein drittes Board, welches die Nutzerschnittstellen behandelt. Dies kann dann auch ein großer, fetter Prozessor mit Linux, Amiga-OS oder CPM sein. > Außerdem kann man sich recht schnell auf die eigentliche Sache, das > Radio, konzentrieren. > > Also, nicht übel nehmen, ich kann nachvollziehen, dass man das ganze in > einer schnellen großen CPU verarbeiten möchte. Aber ich fürchte, dass > die Nachbaubarkeit und die Verstehbarkeit darunter leidet und der Zugang > zu den Innereien des OSCARs nur wenigen vorbehalten bleibt. Aber je > weniger dabei von Anfang an mitmachen, desto schnell verläuft das ganze > auch im Sande. Full ACK.
Christian H. schrieb: > Wie sieht es denn aus? Ist MP3 (und Konsorten; ich spreche im Folgenden > der einfachheit halber von MP3) wirklich für jeden ein Muss? Also für mich definitiv 100%ig! OGG und co. brauche ich nicht, wäre für mich also nicht 100% erforderlich. Weiss nicht wie es bei anderen aussieht. Also ein MP3 decoder in einem µC würde voll und ganz reichen => Ein Lieferant für ein Bauteil weniger. > Reicht der oben genannte Codes denn nicht aus? Ich bin eher für diesen > Bausteil, da man den Prozessor dadurch klein halten kann. Das muss kein 200 MHz x86 sein, es reicht etwas in der ARM7 gegend. Da gibt es bei NXP bestimmt 10 verschiedene die in Frage kommen die alle Lötbar sind. > 1. Ein kleines Board, welches nur das Radio beinhaltet und per RS232 > komplett fernbedienbar ist. > 2. Ein zweites Board, welches die Audio-Verarbeitung (Filter, MP3, ...) > macht. > 3. Ein drittes Board, welches die Nutzerschnittstellen behandelt. Dies > kann dann auch ein großer, fetter Prozessor mit Linux, Amiga-OS oder CPM > sein. Hätte ich mal nicht AMIGA-OS gesagt, das hab ich jetzt davon ;-) >> Also, nicht übel nehmen, ich kann nachvollziehen, dass man das ganze in >> einer schnellen großen CPU verarbeiten möchte. Aber ich fürchte, dass >> die Nachbaubarkeit und die Verstehbarkeit darunter leidet und der Zugang >> zu den Innereien des OSCARs nur wenigen vorbehalten bleibt. Aber je >> weniger dabei von Anfang an mitmachen, desto schnell verläuft das ganze >> auch im Sande. Ja, ich finde auch wir sollten uns bald auf eine Architektur geeinigt haben, andernfalls wird es müßig... Vorschlag: Das mit dem Forum wird für die Diskussion etwas unübersichtlich. Jeder der einen alternativen Vorschlag hat macht eine art Blockdiagram und packt es mit etwas text ins Wiki [1] (Vor/Nachteile Erläuterungstext) und dann stimmen wir ab. Jeder sollte das hier grob ankündigen das er was vorbereiten, andernfalls machen 3 Leute dasselbe. Abstimmung dann am Montag abend (Vorschlag, es sei denn jemand sagt vorher er braucht länger für die Ausarbeitung seines Vorschlags) Was haltet ihr davon? [1] http://osar.it-livetalk.de/ ...man kann es nicht oft genug posten :-) PS: Ich würde dann das System mit 1 großem µC (2 Tuner, RDS, analogem Audio und software MP3 decoder vertreten) und 1 kleinen Frontpanel µC (AtMega Liga).
Olaf Kaluza schrieb: > Ich weiss nicht ob man von uns aus in > Japan bei Amazon bestellen kann. Vielleicht will das mal einer > ausprobieren? Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, probiere ich es sofort aus ;)
Benjamin Maresch schrieb: > Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, > probiere ich es sofort aus ;) Stand oben, aber hier nochmal: http://www.amazon.co.jp/Interface-%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9-2010%E5%B9%B4-06%E6%9C%88%E5%8F%B7-%E9%9B%91%E8%AA%8C/dp/B003D7CGYA
Kai G. schrieb: > Benjamin Maresch schrieb: >> Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, >> probiere ich es sofort aus ;) > > Stand oben, aber hier nochmal: > http://www.amazon.co.jp/Interface-%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9-2010%E5%B9%B4-06%E6%9C%88%E5%8F%B7-%E9%9B%91%E8%AA%8C/dp/B003D7CGYA Habe eines bestellt... Anscheinend ist es möglich.
Benjamin Maresch schrieb: > Kai G. schrieb: >> Benjamin Maresch schrieb: >>> Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, >>> probiere ich es sofort aus ;) >> >> Stand oben, aber hier nochmal: >> > http://www.amazon.co.jp/Interface-%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9-2010%E5%B9%B4-06%E6%9C%88%E5%8F%B7-%E9%9B%91%E8%AA%8C/dp/B003D7CGYA > > Habe eines bestellt... > Anscheinend ist es möglich. Wie teuer ist es (Versandkosten) und WIE um Himmels willen hast Du den Weg durch den Bestellvorgang gefunden? ---- @All: Bitte nicht "überlesen": Beitrag "Re: Open source Autoradio"
Kai das mit dem Tuner-Modul ist schon geklärt. Es muss nur noch gklärt werden wieviel verantwortung 2. µC bekommt und wie das decodieren von MP3 und co geschieht. Mfg Patrick
>> Habe eines bestellt... >> Anscheinend ist es möglich. > > Wie teuer ist es (Versandkosten) und WIE um Himmels willen hast Du den > Weg durch den Bestellvorgang gefunden? Das mit dem Bestellvorgang ist doch einfach, da identisch mit Amazon.de Ich habs soweit versucht, bis Mail-Adresse/PW abgefragt werden, meinen amazon.de-Account nehmen die nicht :)
Kai G. schrieb: > Benjamin Maresch schrieb: >> Kai G. schrieb: >>> Benjamin Maresch schrieb: >>>> Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, >>>> probiere ich es sofort aus ;) >>> >>> Stand oben, aber hier nochmal: >>> >> > http://www.amazon.co.jp/Interface-%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9-2010%E5%B9%B4-06%E6%9C%88%E5%8F%B7-%E9%9B%91%E8%AA%8C/dp/B003D7CGYA >> >> Habe eines bestellt... >> Anscheinend ist es möglich. > > Wie teuer ist es (Versandkosten) und WIE um Himmels willen hast Du den > Weg durch den Bestellvorgang gefunden? > > ---- > @All: Bitte nicht "überlesen": > Beitrag "Re: Open source Autoradio" Das ist ganz einfach... ich habe den Link aufgerufen, dann rechts den Bestellen Button auf Japanisch und dann den Warenkorb aufrufen... Das solltest du noch schaffen ohne Japanisch zu können (ist identisch mit Amazon de) Dann fragt er nach dem Login -> Anmeldung mit Amazon de daten nicht möglich => Neuanmelden (TIPP: oben ist ein Link: "Click here to see in English") -) Email adressse eingeben -) "I am a new customer" auswählen -) Auf der nächsten seite alles Ausfüllen und weiter -) Auf der nächsten Seite ist oben ein Link (International (outside japan)) den anklicken -) Versandadresse ausfüllen -) Zahlungsart ausfüllen -) Bestellen & Fertig TIPP: Das Interface kostet 2200Yen ~ 20 Euro Die Versandkosten 3700Yen ~ 33 Euro Daher würde ich raten gleich eine sammelbestellung für alle machen. Wenn ihr wollt kann ich das Übernehmen.
Angehängte Dateien:
-
Cascade.jpg
740 KB
Ok, um noch mal auf die Basis-Plattform zurück zu kommen: Der/die Tuner brauchen keinen ARM o.Ä Kaliber, um sie zu steuern. Auch die Auswertung welcher Tuner nun sein Audio wegen besserem Empfang auf den Mixer geben kann, braucht keinen ARM. Auch das Auslesen von SD-Cards oder USB-Stick braucht keinen ARM, wenn man das Decoding einem VLSI überlässt. Er muss ja nur alle paar ms ein Paket von 32 Bytes an den VLSI senden. Auch für die Grafik auf einem breiten Farb-LCD braucht es keinen ARM. Ich glaube, die Fähigkeiten eines 8-Bitters mit effektiver Programmierung ( und ich meine damit nicht den Massiven Einsatz von Assembler) werden deutlich unterschätzt. Nur mal als Beispiel: Ich steuere 3 PWM-Lüfter mit PI-Reglern, einen 120W DC/DC Wandler in Software über Highspeed PWM, zwei LEDs, eine RS422, lese 4 Temperatursensoren stelle über USB eine Konfigurationsschnittstelle zur Verfügung. Das alles auf einem ATmega32U4 mit 8MHz. Und es ist trotz USB-Bootloader noch über 1k frei. Trotzdem ist es ratsamer, auf ein 32-Bit System zu gehen, weil - Grafiken sich darin besser verwalten lassen (18-Bit RGB bei LCD/OLED) - Pakete an den VLSI nur 4 Speicherzugriffe brauchen - 32-Bitter DMA/PDC haben - STM32 mit mehr Fähigkeiten weniger/gleichviel kosten wie ein ATmega - I2S Interfaces praktisch sind, um doch noch mehr machen zu können - OnChip Debugging via JTAG praktisch und möglich ist ohne ~250€ für ein spezielles Dongle - System-Timer und andere Features ein Multitasking besser unterstützen ... Wenn man meine Postings verfolgt hat, kann man leicht erkennen, dass die CPU eigentlich nur wenige Pinne benötigt, denn es werden für eine Basisversion des Radios nur 3..4 Bussysteme benötigt: SPI: SD-Card, Serial-Flash I2C: Tuner, Mixer/ Audio-Controller, CD/DVD Drives, Tasten USB: Speichersticks und Software-Update Optional: I2S: Optional, wenn MP3-Decoding per Software oder System-Sounds RS422: Eigene Erweiterungen (von RS232 rate ich eigentlich ab) CAN: für die Anbindung an vorhandene PKW-Features wie Display oder LFB. Der Vorteil der STM32 ist dabei, dass es sie, wie die Atmel Chips, in einer großen 2D-Matrix gibt. Man kann ein und den selben Core sowohl mit wenig oder vielen Pinnen und Features bekommen als auch mit wenig oder viel Speicher. Wer also viele Dinge machen will, kann die OSCAR Software auf einen großen 100-Pinner mit 512kB Flash packen und loslegen, wer nur ein kleines Radio ohne alles will, packt die Software auf einen 32-Pinner mit 128k Flash. Andererseits kann es auch einfach eine Platine geben, die einen 64-Pinner unterstützt und der Nachbauer kann entscheiden, ob er einen mit 64k oder 512k Flash einsetzt. Aus diesen Fakten ergibt sich auch, dass das Layout garnicht so komplex ist, denn alle Teilnehmer hängen mehr oder weniger an 3..4 seriellen Bussen. Sollte zusätzlicher paralleler Speicher erforderlich sein, so kann und muss dieser lokal dicht an der CPU platziert werden. Das halte ich bei den bislang angesprochenen Features für überflüssig. Ob es im Auto nicht ohnehin ratsam ist, ein Layout als 4-Layer zu machen und die Außenseiten hauptsächlich für Masse und Power zu nehmen ist eine andere Diskussion. Man kann durch Beachtung von Abständen auch bei 2-Lagen Audio- und Datenbusse gut nebeneinander führen. Kostet halt ein paar Ferrite mehr. Wir haben bei einem PKW-Radio nicht das Problem, dass da zu viele Käfer auf der Platine sitzen, sondern dass es einiges an Entstörmaßnahmen erfordert. Außerdem werden ein paar DC/DC Wandler benötigt. Wenn der Chip USB ab Haus unterstützt, ist die dafür notwendige Fläche minimal. Ein Power-Controller für die +5V, zwei Induktivitäten und 3 Widerstände. Das passt auf 10x5mm. Es führt kein Weg an 0603 und 0402 SMD vorbei, nur um das gleich fest zu stellen. Aber das ist nichts, was man nicht von Hand löten kann. BGA ist zum Glück nicht erforderlich. Nur um mal zu verdeutlichen wovon wir reden, ein Bild der Becker Cascade Plattform im Anhang.
> Der/die Tuner brauchen keinen ARM o.Ä Kaliber, um sie zu steuern. Auch > die Auswertung welcher Tuner nun sein Audio wegen besserem Empfang auf > den Mixer geben kann, braucht keinen ARM. Es geht sicher auch mit etwas kleinerem weil man nicht viel rechenleistung benötigt, aber für eine gute RDS follow-me und EON implementation braucht es relativ viel Ram. Da ich wirklich Frequency diversity machen will, so wie es Dein Radio von dem Photo übrigens auch macht, zumindest tun es die GrandPrixe von Becker, hätte ich gerne eine große CPU für den Tuner. Wir können ja gerne mal eine Diskussion über RDS starten wenn Du es nicht glaubst, aber dann lieber per PM :-) > Nur mal als Beispiel: > Ich steuere 3 PWM-Lüfter mit PI-Reglern, einen 120W DC/DC Wandler in > Software über Highspeed PWM, zwei LEDs, eine RS422, lese 4 > Temperatursensoren stelle über USB eine Konfigurationsschnittstelle zur > Verfügung. Das alles auf einem ATmega32U4 mit 8MHz. Und es ist trotz > USB-Bootloader noch über 1k frei. Das sollte auch mit etwas kleinerem als einem ATMega gehen :-) Die EINZELLÖSUNGEN brauchen keine großen CPU, aber die gesamtlösung schon. Ich bau Dir auch ein komplettes Autoradio um einen AtMega8 mit akzeptablen RDS, MP3 decoding mit externem decoder und SD Karten support, aber da braucht es halt einige unschöne Konstrukte. ...Hab auch schon z.B. ein komplettes Filesystem für einen AT90S1200 (hat KEIN RAM!!!) programmiert, FAT12/16/32 support, natürlich in assembler, read only, long filename support, directory lesen, ... Aber schön, transparent und übersichtlich ist halt anders. > Wenn man meine Postings verfolgt hat, kann man leicht erkennen, dass die > CPU eigentlich nur wenige Pinne benötigt, denn es werden für eine > Basisversion des Radios nur 3..4 Bussysteme benötigt: > SPI: SD-Card, Serial-Flash > I2C: Tuner, Mixer/ Audio-Controller, CD/DVD Drives, Tasten > USB: Speichersticks und Software-Update > Optional: > I2S: Optional, wenn MP3-Decoding per Software oder System-Sounds > RS422: Eigene Erweiterungen (von RS232 rate ich eigentlich ab) > CAN: für die Anbindung an vorhandene PKW-Features wie Display oder LFB. Das mit den wenig Pinnen ist so ne Sache, such mal die CPU die genau nur Deine Busse zur Verfügung stellt. > Der Vorteil der STM32 ist dabei, dass es sie, wie die Atmel Chips, in > einer großen 2D-Matrix gibt. Man kann ein und den selben Core sowohl mit > wenig oder vielen Pinnen und Features bekommen als auch mit wenig oder > viel Speicher. Wir brauchen uns ja nur auf eine CPU einigen, ich hab nicht vor alle 2 Wochen eine andere zu benutzen. > Wer also viele Dinge machen will, kann die OSCAR Software > auf einen großen 100-Pinner mit 512kB Flash packen und loslegen, wer nur > ein kleines Radio ohne alles will, packt die Software auf einen > 32-Pinner mit 128k Flash. Andererseits kann es auch einfach eine Platine > geben, die einen 64-Pinner unterstützt und der Nachbauer kann > entscheiden, ob er einen mit 64k oder 512k Flash einsetzt. Und jeder Nachbauer macht seine eigene Platine? > Ob es im Auto nicht ohnehin ratsam ist, ein Layout als 4-Layer zu machen > und die Außenseiten hauptsächlich für Masse und Power zu nehmen ist eine > andere Diskussion. Man kann durch Beachtung von Abständen auch bei > 2-Lagen Audio- und Datenbusse gut nebeneinander führen. Kostet halt ein > paar Ferrite mehr. Aus kostengründen, gerade für Prototypen und weil die Platine so groß ist, würde ich stark für 2 Layer plädieren. Das ist auch machbar. Das entstören ist erfahrungsgemäß auch in den Griff zu kriegen. > Wir haben bei einem PKW-Radio nicht das Problem, dass da zu viele Käfer > auf der Platine sitzen, sondern dass es einiges an Entstörmaßnahmen > erfordert. Das sind Äpfel mit Birnen verglichen. Die Käfer STÖREN nicht unbedingt, aber sie machen das Layout komplizierter. > Wenn der Chip USB ab Haus unterstützt, ist die dafür notwendige Fläche > minimal. Das tun ja mittlerweile die meisten. > Ein Power-Controller für die +5V, zwei Induktivitäten und 3 > Widerstände. Das passt auf 10x5mm. Es führt kein Weg an 0603 und 0402 > SMD vorbei, nur um das gleich fest zu stellen. Ich sehe jetzt nicht warum 0402 für ein Schaltnetzteil nötig sein sollten (bzw. warum es so klein sein muss), HF geeignete Schaltnetzteile sind auch schon mit größeren Bauformen realisiert worden. Es gibt übrigens auch seit Jahren integrierte 4 Kanal Verstärker mit integrierten Spannungswandlern für genau diese Applikationen...
Hallo, Kai G. schrieb: > Mathias A. schrieb: >> Auf die Tunerplatine dann nur einen kleinen Controller setzen, der z.B. >> die RDS-Dekodierung, Abfragen von Tasten/Drehgebern etc. übernimmt. Das >> hätte auch den Vorteil, diese (zeitkritischen) Steuerungsaufgaben von >> dem Controller der die Signalverarbeitung macht abzukoppeln (Olaf hatte >> ja auch bereits angesprochen, dass das eine Herausforderung werden >> könnte). > > RDS braucht -wenn man es gut machen will- relativ viel Speicher. Das > Basisfeature follow me (beste Frequenz finden) an sich ist schon echt > nicht ohne und nicht schnell nebenbei am Schreibtisch designed. > Ein AtMega dürfte da aufgrund des geringen RAMs überfordert sein. Wenn > man Frequency diversity zur Empfangsverbesserung einsetzen will braucht > man sogar noch deutlich mehr Ressourcen. hmm ok ein ATmega ist also vielleicht wirklich etwas klein. Aber so eine "Monster-CPU" die es schafft nebenbei noch MP3 zu dekodieren dürfte doch vermutlich auch hoffnungslos überdimensioniert sein (wohlgemerkt wenn es wirklich nur um die Steuerung des Tuners geht). Was heißt eigentlich "relativ viel Speicher" - schätze mal dass einige kB ausreichen dürften, oder? Christian H. schrieb: > Wie sieht es denn aus? Ist MP3 (und Konsorten; ich spreche im Folgenden > der einfachheit halber von MP3) wirklich für jeden ein Muss? also für mich wäre es das nicht, d.h. ich persönlich würde das gerne aus dem Basissystem raushalten. Ich hoffe nämlich (falls es denn dazu kommen sollte dass es zustandekommt ;) ) das Radio über Jahre zu verwenden, und wer weiß was da an Codecs und Speichermedien noch so alles kommt... Könnte mir daher (für mich!) auch vorstellen ein Handy, iPod o.ä. als Zuspieler zu verwenden, der dem Radio direkt Audiosignale liefert, sei es per Kabel (Autohalterung) oder per Bluetooth (A2DP). Entsprechende Adapter gibts ja auch schon fertig. Nett wäre dabei eine Fernsteuermöglichkeit (z.B. per AVRCP). Das eigentliche Radio müsste dafür nur einen Line-In haben; die Fernsteuerung kann ja direkt ans Bedienteil gekoppelt werden. Im Prinzip hätte ich nichts gegen eine "viel zu große" CPU, wenn sie a) mit Hausmitteln lötbar b) vom Layout her noch beherrschbar ohne zig Prototypen anfertigen zu müssen bis alle Entstörungen usw. passen c) gut verfügbar und möglichst mit freien Mitteln programmierbar ist. Der Preis der CPU wäre mir nicht so wichtig, die o.g. 15-20 € für den Renesas wären jedenfalls noch ok; zumindest Punkt a+b scheint er mir aber nicht so ganz zu erfüllen...(oder?) > Ich bin da eher für Modularisierung. > > 1. Ein kleines Board, welches nur das Radio beinhaltet und per RS232 > komplett fernbedienbar ist. > 2. Ein zweites Board, welches die Audio-Verarbeitung (Filter, MP3, ...) > macht. > 3. Ein drittes Board, welches die Nutzerschnittstellen behandelt. Dies > kann dann auch ein großer, fetter Prozessor mit Linux, Amiga-OS oder CPM > sein. hört sich für mich gut an. Wobei man evtl auch 2 und 3 noch zu einem Teil zusammenfassen könnte. > >> Außerdem kann man sich recht schnell auf die eigentliche Sache, das >> Radio, konzentrieren. >> >> Also, nicht übel nehmen, ich kann nachvollziehen, dass man das ganze in >> einer schnellen großen CPU verarbeiten möchte. Aber ich fürchte, dass >> die Nachbaubarkeit und die Verstehbarkeit darunter leidet und der Zugang >> zu den Innereien des OSCARs nur wenigen vorbehalten bleibt. Aber je >> weniger dabei von Anfang an mitmachen, desto schnell verläuft das ganze >> auch im Sande. sehe ich auch so... Mathias
> hmm ok ein ATmega ist also vielleicht wirklich etwas klein. Aber so eine > "Monster-CPU" die es schafft nebenbei noch MP3 zu dekodieren dürfte doch > vermutlich auch hoffnungslos überdimensioniert sein (wohlgemerkt wenn es > wirklich nur um die Steuerung des Tuners geht). Was heißt eigentlich > "relativ viel Speicher" - schätze mal dass einige kB ausreichen dürften, > oder? So überschlagsmäßig würde ich sagen das ca. 32 KB für RDS + Frequency diversity genug sind.
Dann möchte ich nochmal meine Vorstellungen zusammenfassen. Das Mainboard sollte sich als reines Peripheriegerät mit klar definierten Schnittstellen zur Außenwelt präsentieren. Irgendwelche Codes haben m.M.n. auf dem Mainboard nichts verloren, da die Anforderungen (mp3,og,flac,wma....etc) viel zu unterschiedlich sind, und weitere Formate mit ziemlicher Sicherheit in Zukunft dazu kommen werden. Es wäre allerdings sinnvoll, einen I²S Eingang incl. D/A vorzusehen, um hier einen Zuspieler anzuschließen. Ein I2S-Ausgang zum Aufzeichen wäre sicher auch eine sinnvolle Option Auf diese Weise kann der gesamte Analog-Audio-Pfad auf dem Mainboard bleiben, und entsprechend gut vor externen Störungen bewahrt werden. Für die, die das Radio mit allen möglichen Codecs usw. aufmotzen wollen, sollte ein Steckplatz vorgesehen werden, auf den das (optionale) Multimedia-Modul aufgesetzt werden kann. Hier kann man einen grossen Prozessor mit Linux und allen möglichen Codecs unterbringen. Die Bedienlogik kann dann wahlweise im Bedienteil oder Multimedia-Board stecken. Natürlich sollten alle Radio-relevanten Dinge innerhalb der Mainboard-Cpu erledigt werden(Tuning, Diversity, RDS Audio-Regelung und Distribution). Harry
Harald L. schrieb: > Dann möchte ich nochmal meine Vorstellungen zusammenfassen. > Das Mainboard sollte sich als reines Peripheriegerät mit klar > definierten Schnittstellen zur Außenwelt präsentieren. Leute, wir drehen uns im Kreis!!!!!! Und landen im Endeffekt immer beim dem selben System das Harry hier auch umreißt. Ich hab noch niemanden gehört der einen anderen codec haben wollte und es spricht nichts dagegen MP3 im Radio selber zu implementieren. MP3/OGG/AAC/XYZ kann trotzdem auch noch mit Linux abgespielt werden. Den Haupt µC muss man sonst ziemlich leistungsstark wählen und dann ist noch die Frage ob überhaupt irgendwann mal jemand den gewünschten Codec für die gewählte Plattform implementiert (Portieren kann aufwändig werden wenn ASM Hilfsroutinen im codec sind). > Es wäre allerdings sinnvoll, einen I²S Eingang incl. D/A vorzusehen, um > hier einen Zuspieler anzuschließen. Ein I2S-Ausgang zum Aufzeichen wäre > sicher auch eine sinnvolle Option Klar, hatten wir ja schon vorgesehen. > Für die, die das Radio mit allen möglichen Codecs usw. aufmotzen wollen, > sollte ein Steckplatz vorgesehen werden, auf den das (optionale) > Multimedia-Modul aufgesetzt werden kann. > Hier kann man einen grossen Prozessor mit Linux und allen möglichen > Codecs unterbringen. Ja, genau!!! > Die Bedienlogik kann dann wahlweise im Bedienteil oder Multimedia-Board > stecken. Ja. Tastenpolling und co. lieber in einem kleinen µC der dann mittels interrupt/"Data available signal" an den Haupt-µC signalisiert das sich was getan hat. > Natürlich sollten alle Radio-relevanten Dinge innerhalb der > Mainboard-Cpu erledigt werden(Tuning, Diversity, RDS Audio-Regelung und > Distribution). Mein Reden! Kai
@Kai scheint ja, als würden wir uns doch noch einigen können ;) Also gut!...von mir aus ein mp3-Codec mit rein... Daran solls dann auch nicht scheitern! Harry
Na da sind wir ja doch wieder bei der dicken CPU beim Tuner. Bin dann mal weg.
So langsam scheint sich ja eine Einigung zu finden -- bzw. die Missverständnisse aufzuklären da ohnehin bisher schon jeder das selbe gemeint hatte? ;-) Kai G. schrieb: > So überschlagsmäßig würde ich sagen das ca. 32 KB für RDS + Frequency > diversity genug sind. danke, das ist ja schonmal ein guter Wert zur weiteren Planung. Kai G. schrieb: > Harald L. schrieb: >> Dann möchte ich nochmal meine Vorstellungen zusammenfassen. >> Das Mainboard sollte sich als reines Peripheriegerät mit klar >> definierten Schnittstellen zur Außenwelt präsentieren. > > Leute, wir drehen uns im Kreis!!!!!! Und landen im Endeffekt immer beim > dem selben System das Harry hier auch umreißt. > > Ich hab noch niemanden gehört der einen anderen codec haben wollte und > es spricht nichts dagegen MP3 im Radio selber zu implementieren. Aus Softwaresicht klar, man muss es ja nicht verwenden wenn man es nicht braucht. Insofern stimme ich Dir da zu. Dass ich bisher gegen MP3 im Hauptsystem war lag daran, dass ich den Eindruck hatte dass die dafür geplante CPU recht aufwändig und speziell ist was das Löten und die Entwicklungswerkzeuge angeht. Wenn ich z.B. die CPU auf dem Becker Cascade anschaue, also ich hätte schon etwas Respekt davor sowas von Hand zu löten...oder bin ich da die Ausnahme? Zumal wenn man diese CPU dann zu geschätzten 10% auslastet fragt sich schon ob es den ganzen Aufwand wert ist... Wenn nun aber dafür anscheinend auch etwas "hobby-freundlicheres" ;) ausreicht (so habe ich zumindest einige der neueren Posts verstanden, bitte korrigiert mich wenn ich falsch liege) habe ich auch kein Problem damit MP3 ins Mainboard zu integrieren. Mathias
Wenn ich das richtig sehe, bewegen wir uns jetzt wieder in der ARM7-Liga. Ist mir sehr sympatisch! Wir sollten dieses Design jetzt aber auch mal langsam festschreiben, sonst diskutieren wir nächstes Jahr noch Harry
> Ich verfolge diesen Thread schon eine Weile und bin verblüfft > wie hier im Handstreich eigene Meinungen durchgesetzt werden. Welche Meinung meinst du denn? Ich habe eigentlich gedacht das ich etwas (SH7262) zur Diskussion gestellt habe von dessen Eignung ich selber fuer dieses Project ueberzeugt bin. Aber natuerlich bin ich auch immer fuer Gegenvorschlaege offen solange sie begruendet werden. > Der Renesas mag technisch toll sein, aber das er hierzulande > kein Exot ist halte ich für eine ziemlich isolierte Meinung. Dieser Prozessor ist mir sicherheit ein Exot. Sowohl hier wie auch in Japan. Einfach deshalb weil er speziell fuer Audiogeraete enwickelt wurde und darum keine grosse Verbreitung haben kann. Und nun? > Sicher gibt es Leute die damit arbeiten, aber verglichen mit > ARM ist die Verfügbarkeit von Tools jeder Art recht bescheiden. Sowohl der Compiler von Renesas selber wie auch der gcc lassen sich problemlos kostenlos runterladen. Welches tool brauchst du sonst noch? Es gehoert mit zu den bemerksenwerten Besonderheiten dieses Prozessors das man eben nur ein USB-Kabel braucht um den brennen zu koennen und einen Debugger auf Assemblerlevel, C-sourcecode-Level mit Breakpoint, Watchpoints usw zu betreiben. Mit anderen Worten wirklich jeder kann das Teil benutzen. Man brauch eben keine extra Hardware zum brennen anzuschaffen. > Der SuperH ist eine der besten Lösungen wenn man mal von diversen ARMs > im BGA absieht. Außerdem der Olaf spielt schon mit dennen. Wer eine bessere Loesung kennt soll sie doch einfach mal nennen. Ich lese mir gerne das Datenblatt durch! > Ich würd ned immer alles über UART machen wollen es gibt ja auch noch > SPDIF usw. Eben, welcher ARM hat denn z.B SPDIF eingebaut? > Ja, ich bin auch immer noch für den/die SuperHs. Ich nutz zwar Linux, > aber programmieren tu ich meist unter Windows, insofern würde mich der > fehlende GCC nicht stören. Der gcc fehlt nicht. Ich habe den hier bei mir in der compilierten Version fuer Windows auf der Platte liegen! Es gibt nur keinen Grund ihn zu verwenden. Nur wenn man Code groesser als 256k erzeugt wird man das tun muessen. Ansonsten kann man zumindest vermuten das der Compiler von Renesas deutlich effizienter ist. Aber wer langeweilse hat darf gerne auch mal den gcc ausprobieren. > Wenn Arm und BGA wär ich eindeutig für den LPC2888 von NXP. Aber leider > nichtmal nur ein BGA, sondern sogar ein FBGA... Nicht nur BGA ist schlimm. Egal von welchem Hersteller der Prozessor letztlich ist, er sollte schon ohne externe Buszugriffe auskommen. > - Für einen Hobbyelektroniker mit beschränktem Werkzeugpool noch > lötbar; > kein BGA und QFN - Finepitch ist aber kein Problem (sollte halt > herausragende Pins haben, die man mit dem Lötkolben erfassen kann). Nicht nur das. BGA ist mit einer gewissen Wahrscheinlichkeit sogar noch loetbar, springen vielleicht mal 10% der Nachbauer ueber die Klippe. Aber wieviel Testboards mit 4 oder 6Lagen koennen wir uns leisten bis die Platine laeuft? Und wenn die Kiste dann noch externes Ram braucht, dann empfaengt Kais Empfaenger vermutlich in den ersten Versionen ausschliesslich den Ramzugriff und kein Radio. :-) > Optional: > - Gerne auch kostenlosen oder kostengünstigen Debugger. Ohne eine Moeglichkeit zu debuggen kannst du nicht vernuenftig arbeiten! Die Qualitaet des Renesas-Debuggers war fuer mich vor Jahren der Grund warum och von den AVRs weg gegangen bin. > Heißt frei denn das es der GCC sein muss? Eben! Mir reichen die Beschraenkungen des Renesas erstmal aus. Aber es gibt ja den gcc. Es ist also keine Sackgasse! > Zum Debugger: > Der Olaf hat einen Debugger, mit dem kann man sich sicher zusammen > reden. Mit mir oder dem Debugger? :-) Nochmal zur Erklaerung. Die Oberflaeche von Renesas (HEW) enthaelt einen Debugger. Der ist SEHR leistungsfaehig. Der laesst wirklich keine Wuensche offen. Dieser Debugger benoetigt eine Anbindung an den Controller. Dies kann ueber eine Hardware geschehen. Diese heisst z.B E8 (R8C/M16C), E8a (R32), E10(SuperH). Bei den kleinen Prozessoren (R8c/M16C) konnte die Anbindung aber auch ueber eine RS232 geschehen. Hat halt den Nachteil das dies eine der seriellen Schnittstellen gekostet hat. Beim SH7262 kann die Anbindung auch noch ueber USB2.0 geschehen. Ich habe damit jetzt ein paar Stunden rumgespielt und konnte keine Einschraenkung feststellen. Die einzige Einschraenkung die es gibt, solange USB fuers Debuggen genutzt wird kann man da offensichtlich keinen USB-Stick dran haengen. Fuer diese spezielle Anwendung waere ein E10 sicherlich schoen. Und den hat mir Renesas/Glyn netterweise geschenkt. Genauer gesagt der ist heute eingetroffen und steht jetzt hier auf den Schreibtisch. Und nochmal, sollte irgendjemand waerend der Programmierung wirklich den E10 brauchen dann verleihen wie den einfach untereinander. > Renesas spielt weltweit in den obersten Rängen der > Mikrocontroller-Firmen. Naja, in Bastlerkreisen sind sie sicher nicht so verbreitet. Ich verstehe zwar nicht ganz wieso, aber das ist ja erstmal unerheblich. Wichtig ist doch nur das man einen Prozessor nach bestimmten Kriterien aussucht und wenn ein Prozessor sie erfuellt dann nimmt man den. Mir fallen auch eine Menge Anwendungen ein wo ich den SH7262 niemals nehmen wuerde. In einer Firma waere zum Beispiel haeufig ein Problem das man seinen Code nicht vor auslesen schuetzen kann wenn er in einem exteren Flashrom ist. Aber da kann uns ja egal sein. > Man muss sagen das für den AVR, PIC oder vielleicht noch ARM User ein > gewahltiger Sprung ist wenn man auf zB die SuperH Serie umsteigt. Ich weiss nicht ob ich da zustimmen kann. Jedenfalls schwierig zu beantworten. Auf der einen Seite wenn man einen AVR in C programmiert hat dann programmiert man den SuperH genauso in C. Ich habe viel Programmcode den ich beliebig zwischen AVR, R8C, M16C, 68332 und Dragonball ohne Aenderungen hin und hergeschoben habe. Andererseits wenn man eher, wie soll man sagen provienziell(?) programmiert hat dann kann das stimmen. (z.B Intel/Motorola Reihenfolge der Bytes) Einige Dinge werden schwerer werden. Das Datenblatt ist nicht umsonst so dick, andere Sachen werden aber auch einfacher! Schwieriger wird es sicherlich wegen anderer notwendiger Konzepte weil im Hintergrund des Prozessor staendig Daten bewegt werden muessen. Da darf es niemals irgendwelche Probleme geben weil man die sofort als Knackser aus dem Lautsprecher hoert. Aber das liegt bei diesem Project in der Natur der Sache. > *kein offizieller GCC...etc Ich weiss nicht was Offiziell fuer dich ist. Reicht das nicht: http://de.wikipedia.org/wiki/T2_SDE http://www.t2-project.org/packages/gcc.html > sag mal Olaf!....arbeitest du bei Renases in der Marketing-Abteilung? Nein. Ich benutze nur M16C seit vielen Jahren privat weil ich sie gut fand und seid etwas weniger Jahren in der Firma und habe gute Erfahrungen gemacht. Sollte mich aber Renesas abwerben werde ich es euch wissen lassen. :-) Den hier angesprochenen Prozessor und ueberhaubt die SuperH Familie kenne ich noch garnicht! Wenn man mal davon absieht das ich auf einem Testboard eine LED habe blinken lassen und die Datenblaetter gelesen habe. Ich bin nur durch Zufall auf den SH7262 gestossen und fand ihn sehr interessant. Und wenn du ausser zu mosern einen besseren Prozessor aus dem Hut zaubern kannst dann koennen wir den auch gerne nehmen! Mir fallen auch andere Projecte ein die ich alleine mit dem SH7262 durchziehen kann. (Man ueberlege nur mal, SPDIF Eingang und Ausgang und viel Rechenleistung dazwischen. Da faellt mir doch als erstes ein Sampleratenwandler fuer meine DATs mit integrierten AD-DA Teil, Lautstaerkeanpassung, Expander/Kompander usw ein) > ich würde eher eine CPU wählen, die vieleicht auch GeneralPurpose'd > besser aufgestellt ist, (wäre dann universeller), Was versprichst du dir davon? Glaubst du wirklich es werden jemals mehr als 10-20Radios gebaut? Es ist ja nicht so das wir den als Firma mit 10Jahren garantierter Produktlaufzeit einsetzen. Da haette ich dann auch bedenken. > Da würd ich mir den RX noch ansehen . Das Problem das ich mit dem RX haette ist das die halt noch sehr neu sind. Da wuerde ich Probleme mit irgenwelchen Bugs im Prozessor geradezu erwarten. Ausserdem, jedesmal wenn man etwas spezielles aus dem SH7262 bei einem anderen Prozessor durch externe Hardware ersetzen muss dann steigt das Risiko. Ueberleg mal, hier waren doch sogar Leute die wollten einen FPGA einbauen. Also geradezu die Garantie das man so ein Teil nach kurzer Zeit nicht mehr bekommt. > Wenn es nach mir ging würd ich am Liebsten einen ARM Cortex A5 > verwenden, leider ist der noch nirgends zu bekommen Mal abgesehen davon das mein einen Prozessor den man nicht kaufen kann offensichtlich nicht verwenden kann. WARUM bitte soll man einen bestimmten ARM nehmen? Was kann er was ein anderer Prozessor nicht kann, das aber fuer dieses Project wichtig waer? Ich habe manchmal den Eindruck das manche Leute hier bloss das essen wollen was sie schon immer gegessen haben und ihnen der Brei anderer Leute Angst macht weil er die falsche Farbe haben koennte. Soll ich genauso denken? Ich habe noch nie etwas mit ARM gemacht. Sind die deshalb automatisch schlecht? > Wozu überhaupt so eine "fette CPU" auf dem Mainboard? Weil die Alternative ein Autoradio auf dem Level von 1985 ist. Das bekommt man mit einem R8C (oder Mega8) hin der alles ueber I2C steuert. Ich hoffe es macht dir dann nichts aus wieder Musik ueber Kassette zu hoeren. :-) > Und nochmal: der Renases ist alles andere als offen, solange Renases > selbst der einzige Lieferant von Software ist. Sag mal, leidest du unter Paranoia? Glaubst du Renesas loescht dir nachts deine Platte oder so? Ausserdem STIMMT DAS NICHT. Read my lips, es gibt einen gcc! > Selbstbauprojekte mit den Dingern findet man im Netz auch so gut wie > nicht. Weisst du, wenn der Selbstbau bei einem Prozessor darin besteht die Betriebspannung anzulegen dann ist das erstmal nicht so die Herausforderung. > Wir wären also echte Pioniere, und auf uns selbst gestellt. Was denn? Weil du einen neuen Prozessor aus dem fernen boesen Japan kennenlernen musst? Manchmal frag ich mich wie die Wikinger Amerika entdeckt haben oder warum unserer Vorfahren das Feuer kultiviert haben. Und das so ganz ohne Internet.... > Och Leute, seid doch nett zueinander. Geht raus, tankt ein bißchen > Sonnenstrahlen (=Glückshormone) und kommt zurück ;-) Grillen war gestern. Heute ist ernst. :-) [ploep] <---Das war ein Flens! > Wow, das ist schon mächtig. Normalerweise sollten für mittlere Lasten > auch 100n und 10n parallel reichen Ich vermute mal das war eher Angst beim Entwickler. Wichtiger als die Kapazitaet ist IMHO die Baugroesse. > Generell sollten alle keramischen im Auto >100°C abkönnen. Was den Punkt angeht macht mir das Display die meisten Sorgen. > Außerdem ist X7R bei vielen Bestückern vorrätig. Bestueckern? Ich dachte bei diesem Project ist es eher wichtiger was bei Reichel vorraetig ist. :-) BTW: Ich hab noch ein Reel mit 100nF rumliegen. Ich koennte euch sponsern. Und die sind auch nicht von Renesas. :) Loesung1: > Der 'äußere' Controller steuert > dann das Bedieninterface, andere Komponenten des Radios > und übernimmt wenn er üppig dimensioniert ist evtl. > auch gleich die MP3-Dekodierung. Wo bekommt dein aeusser Controller seine Daten her. Ich haette doch gerne die SD-Karte im Radio stecken. Willst du alles zweimal hin und herschubsen? > 2) Dann gibt es die Variante wo der Controller den Tuner > steuert und gleichzeitig die MP3-Funktionen und warscheinlich > auch noch die Signalverarbeitung (Klangregelung usw.) Das wird von mir favorisiert. Das ist StateOftheArt. Ausserdem wuerde da zumindest fuer mich der Spass drin liegen. Man koennte sozusagen mal wieder das was man im NT-Studium gelernt hat zur Anwendung bringen. Loesung 1 ist fuer mich langweiliger Alltagskram. Das habe ich jeden Tag in der Firma. Warum sollte ich mir das auch noch privat geben? > Ich finde der Tuner sollte nicht nur die Daten durchschicken, sondern > auch dekodieren und interpretieren. Dann ist etwas größeres als ein > Atmega schon hilfreich. Nicht nur hilfreich. Warum soll man wegen ein paar Euro mehr sich irgendwelche Zwaenge auferlegen. Wir arbeiten doch nicht bei Blaupunkt wo jeder gesparte Euro bei grossen Stueckzahlen wichtig ist. > nein, ich nehme auch andere, für die ich nichts bezahlen muss. > Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch > unter Mac OS-X) verwenden kann. Seufz! Und nochmal. Es gibt einen GCC und es gibt ihn im Source. Und der SH7262 ist im Gegensatz zu anderen Prozessoren sogar besonders frei. Sein Programm befindet sich naemlich in einem externen SPI-Flash das du immer brennen kannst. Aber all das ist fuer so ein Project UNWICHTIG! Es geht hier um die Zusammenarbeit von hoffentlich vielen Leuten. Es ist notwendig das die dann dieselbe Programmierplatform nutzen. Und damit ist es sehr wahrscheinlich das nicht unter Linux entwickelt wird. > <ironie>und noch Amiga-OS (ab Kickstart/Workbench 1.4) und CPM</ironie> Und PalmOS! Ich mag PalmOS....also das bitte auchnoch. :-) <ironie> Manchmal warte ich darauf das in der naechsten News hier einer unbedingt den 6502 als Steuerprozessor haben will weil er den ersten Sex mit der Zeropage hatte und das so romantisch war. </off> > Allerdings besteht bei den Nicht-O/S Toolchains immer die Gefahr, dass > sie limitiert ist ( nur xxkB Code), dass sie mit der Plattform stirbt, > wenn die Nachfrage nicht hoch genug ist oder dass sie nicht auf allen > Plattformen einsetzbar ist. Renesas ist mittlerweile der weltgroesste IC-Hersteller. Bevor die zumachen hat AVR lange ausgeschissen^W aeh..sind nicht mehr... :-D > Wenn GCC läuft, dann kann ich meinen Source-Insight einsetzen und ein > anderer Eclipse. Sicher, und ich setze dann Makefiles ein. Sagt mal, noch ganz wach? Es kann doch nicht jeder was anderes einsetzen. wie soll da eine Zusammenarbeit erfolgen? > Daher fehlt es an vielen Dingen, die alle erst einmal neu > gemacht werden müssten. Nicht lamentieren! Sag doch einfach mal was genau dir fehlt! > Man kann sich das ein oder andere Aus den > AppNotes von Renesas zusammen bauen, aber ein eigenes System mit > TaskSwitching aufzusetzen, heißt wirklich ganz unten anfangen. Das wuerde ich auch nicht haben wollen. Ich bin mir fuer ein Event-gesteuertes System mit IRQs fuer die schnellen Dinge im Hintergrund. > Außerdem kann es sein, dass außer uns keiner das Teil kauft, also > stampft NXP das Teil wieder ein, Das Risiko halte ich fuer relativ gering und tolerabel. Es wird schliesslich nie eine grosse Produktion sondern nur wenige Teile geben. Da kann man sich die paar Teile doch wohl besorgen. > Ist ja schön das wir jetzt ein Betriebssystem haben (auch wenn ich den > ganzen Ethernet kram lieber draussen sehen wollte), aber das war doch > erstmal nicht das kernproblem, oder? Ich bin gegen die Verwendung eines Betriebssystems. Das kostet nur unoetig Rechenzeit und macht das Zeitverhalten sagen wir mal arbeitsintensiv. Und es bringt keinen Vorteil solange ein Betriebsystem nicht das macht fuer das es erfunden wurde, naemlich unterschiedliche Anwendungen zu starten. [MP3] > Also für mich definitiv 100%ig! DAs sehe ich auch so. MP3 ist durchgesetzer Standard. Entweder das geht oder die Sache ist gestorben. Sonst kann mir doch gleich wie meine altes Kasettenradio einbauen. > OGG und co. brauche ich nicht, wäre für mich also nicht 100% > erforderlich. Weiss nicht wie es bei anderen aussieht. Noe, brauch ich auch nicht. Aber wenn das per Software gemacht wird kann es doch jemand fuer den das wichtig ist einfach programmieren. [Amazon] > Wennst mir den Link zu dem Board gibst, und mir den Euro Preis sagst, > probiere ich es sofort aus ;) Ich glaub das mit dem link reinkopieren klappt hier nicht. Dabei werden irgenwelche Zeichen zerstoert. Geh einfach mal nach Amazon-Japan und Tipp das "Interface" ein. Gleich der erste Treffer ist die Ausgabe 6/2010 fuer 2310Yen. BTW: Die haben echt japanische Zeichen in der URL. Wusste garnicht das dies geht. > Wie teuer ist es (Versandkosten) und WIE um Himmels willen hast Du den > Weg durch den Bestellvorgang gefunden? Das koennte in der Tat interessant sein. :-D Noch was fuer die eventuell anderen Besteller.... Man benoetig zur Benutzung noch einen Treiber den man kostenlos auf der Homepage der Zeitschrift runterladen kann. Dazu muss man sich aber auf dieser Homepage registrieren: http://cc.cqpub.co.jp/system/document/keyword=IF201006SH2A http://www.kumikomi.net/interface/editors/2010/04/sh-2a_1.php Zur Registrierung ist es unbedingt erforderlich das man die Aussprache seines Namens in Hiragana/Katakana angibt. Und es reicht auch nicht wenn man da irgendwelche Japanische Zeichen von woanders reinkopiert. <seufz> Ich hatte aber vor diese Files zur Verfuegung zu stellen und habe auch eine Installationsanleitung in Deutsch geschrieben.... Notfalls mir also eine Mail schicken. > Die Versandkosten 3700Yen ~ 33 Euro Aechz! > ...Hab auch schon z.B. ein komplettes Filesystem für einen AT90S1200 > (hat KEIN RAM!!!) programmiert, FAT12/16/32 support, natürlich in > assembler, read only, long filename support, directory lesen, ... Aber > schön, transparent und übersichtlich ist halt anders. Du arme Sau. :-) Wie hast du das den in das Flashrom der ollen Kiste bekommen? Olaf p.s: War die Laenge der News jetzt neuer Record? Sorry, war gestern den ganzen Tag mit dem Motorad unterwegs und danach grillen. Deshalb heute der Rundumschlag weil es soviele neue News gab.
@Olaf Ok!....es gibt also eine freie Toolchain, und ich hab auch verstanden, daß ich meinen Code via Bootloader in den Chip bekomm; -soweit so gut- Wie debug ich das dann, wenn ich keinen (teuren) E10 hab? (wobei die Debug/Trace-Funktion ja extra kostet, wenn ich die Webseite richtig interprettier) Den Einsatz von GCC/GDB betrachte ich bei einem OpenSource-Projekt als obligatorisch – ganz egal, wie toll der Debugger von Renasis ist! Der andere Punkt: was genau möchtest du denn in der Audio-Signalverarbeitung durch diesen Prozessor gewinnen? Wenn ich das richtig seh, müsste man doch bei einer echten digitalen Signalverarbeitung bereits die ZF digitalisieren, und das Signal per Software demodulieren. Da kann ich mir auch echte Vorteile vorstellen, nur überschreitet das den Horizont meiner (derzeitigen) Fähigkeiten. (und wohl auch den der meisten anderen hier) Außerdem – wenn du anprangerst, daß unser Konzept ein Autoradio der 80er beschreibt, muss ich dich wohl mal daran erinnern, daß der analoge Rundfunk in seiner jetzigen Form deutlich älter ist. Wenn ich die Beschreibung des Tuner-Chip richtig verstanden habe, erledigt der doch bereits den Signal-verarbeitungs/-verbesserungs-Teil....das dekodieren der RDS-Daten sowieso....“so what?“ Wozu brauch ich jetzt unbedingt die tollen Audio-Features des SH?....der wichtigste Teil unserer Signalverarbeitung bei dem Radio ist nunmal analog. Harry
Ach ja....und noch etwas: es wird einen digitalen Ein- und Ausgang in Form einer I²S-Schnittstelle zum Multimedia-Modul geben. Was hindert dich daran, einen SH auf den Erweiterungsslot zu stecken? Harry
@darkover wenn ich was lesen will geh ich in eine Bibliothek Naja ich wär auch für einen SuperH. Wenn man schon digital arbeitet dann gscheid. MFg
Olaf Kaluza schrieb: > Nochmal zur Erklaerung. Die Oberflaeche von Renesas (HEW) enthaelt > einen Debugger. Der ist SEHR leistungsfaehig. Der laesst wirklich > keine Wuensche offen. > > Dieser Debugger benoetigt eine Anbindung an den Controller. Dies kann > ueber eine Hardware geschehen. Diese heisst z.B E8 (R8C/M16C), E8a > (R32), E10(SuperH). > Bei den kleinen Prozessoren (R8c/M16C) konnte die Anbindung aber auch > ueber eine RS232 geschehen. Hat halt den Nachteil das dies eine der > seriellen Schnittstellen gekostet hat. > Beim SH7262 kann die Anbindung auch noch ueber USB2.0 geschehen. Ich > habe damit jetzt ein paar Stunden rumgespielt und konnte keine > Einschraenkung feststellen. Damit ich das jetzt auch verstehe: Bedeutet das, der SH7262 kann komplett über USB2.0 debuggt werden? Ich brauche also nicht zwingend einen E10? >> nein, ich nehme auch andere, für die ich nichts bezahlen muss. >> Wäre aber schön, wenn ich diese unter Windows und Linux (ideal auch >> unter Mac OS-X) verwenden kann. > > Seufz! Und nochmal. Es gibt einen GCC und es gibt ihn im Source. Und > der SH7262 ist im Gegensatz zu anderen Prozessoren sogar besonders > frei. Sein Programm befindet sich naemlich in einem externen SPI-Flash > das du immer brennen kannst. Ja, danke, das habe ich auch bereits erfahren. Außerdem ging es bei meiner Bemerkung nicht um den SH7262, sondern allgemein. Mir bringt kein Prozessor etwas, den ich nur mit teurer Hard- und Software programmieren kann (auch das ist allgemein zu verstehen). > Aber all das ist fuer so ein Project UNWICHTIG! Es geht hier um die > Zusammenarbeit von hoffentlich vielen Leuten. Für dieses Projekt ja. Ich schneide mir aber gerne ein Stück von dem Kuchen ab und esse es woanders auf. Sprich, ich würde den Prozessor, wenn ich ihn schon kennengelernt habe, eventuell auch für etwas anderes einsetzen wollen. Dann setze ich vielleicht lieber eine andere Programmierplattform ein. Der Prozessor (oder zumindest die Famile) muss auch das hergeben. > Es ist notwendig das die > dann dieselbe Programmierplatform nutzen. Und damit ist es sehr > wahrscheinlich das nicht unter Linux entwickelt wird. Da ich unter Windows nur arbeite (beruflich, bin Admin) und privat nur spiele, bin ich dann wohl raus. Es kommt aber auf das Projekt drauf an - ist es interessant genug, wäre ich auch bereit, eine Programmierumgebung als VM aufzusetzen. Lieber ist es mir aber, wenn ich unter Linux arbeiten kann - da fühle ich mich zuhause, denn damit bin ich groß geworden. PS: Ich bin trotzdem immer noch der Meinung, nicht alles in einen großen Prozessor zu stecken. Ich wäre mit dem VS1053 zufrieden; gerne auch als optionales Modul.
Christian H. schrieb: > Da ich unter Windows nur arbeite (beruflich, bin Admin) und privat nur > spiele, bin ich dann wohl raus. Es kommt aber auf das Projekt drauf an - > ist es interessant genug, wäre ich auch bereit, eine Programmierumgebung > als VM aufzusetzen. Lieber ist es mir aber, wenn ich unter Linux > arbeiten kann - da fühle ich mich zuhause, denn damit bin ich groß > geworden. Ich seh GCC/GDB als obligatorisch an, und da es sich um Open-Source handelt, geht auch die komplette Entwicklung unter Linux! Ich verwende ebenfalls ausschließlich Linux, und der kleinste gemeinsame Nenner ist da GCC&Co. > > PS: Ich bin trotzdem immer noch der Meinung, nicht alles in einen großen > Prozessor zu stecken. Ich wäre mit dem VS1053 zufrieden; gerne auch als > optionales Modul. Seh ich genauso....für die mp3-only-Fraktion könnte der als lowcost-Lösung auf dem Multimedia-Port stecken. Harry
Mit GeneralPurpose'd hatte gemeint, dass man mit RX evtl mehr machen kann, ausserdem hat der JETZT SCHON Flash bis zu 100MHz !, max 2MB (und zukünft sogar bis 200MHz!!!, 4MB) (bei zB STM32 kannste das vergessen!!!!, der ist 5..6x langsamer!!) Mit GeneralPurpose'd wars auch so gemeint, dass sich der Einarbeitungs-aufwand in den RX M-E-H-R rentiert, eben weil auch später noch für andere Proj gut benutzbar. (Man wird wohl nicht einen SH-Audio-Proz für allgem. Aufgaben wählen) Das RX ist zwar rel neu, aber die Chips wurden bereits seit 2 Jahren getestet, Fehler sind da eher nicht zu erwarten. CPU-Error schon gar nicht. Die Dinger werden ja schon zuhaufe verkauft. Ausserdem: der SH7262 ist AUCH neu, im Catalog von 2009 stand er noch als "Under Development". (gebe allerdings zu, dass der RX (momentan) kein I2S hat , ist aber rel. wenig Aufwand das mit PLD/FPGA zu machen (dann könnte man sogar den Durchsatz im Vergleich zur eingebauten I2S im SH steigern, und wenn nötig auch die Anzahl der Kanäle erhöhen, und wenn nötig sogar ein spez. Audio-Protokoll machen, und wäre so viel flexibler)) ...und hätte halt eine sehr gute GP'd CPU
Harald L. schrieb: > Seh ich genauso....für die mp3-only-Fraktion könnte der als > lowcost-Lösung auf dem Multimedia-Port stecken. Anmerkung: die anderen stecken einen Linux-Rechner auf den Multimedia-Port, und dekodieren mp3 & co eben per Software Harry
Harald L. schrieb: > Den Einsatz von GCC/GDB betrachte ich bei einem OpenSource-Projekt als > obligatorisch – ganz egal, wie toll der Debugger von Renasis ist! Ack > Der andere Punkt: was genau möchtest du denn in der > Audio-Signalverarbeitung durch diesen Prozessor gewinnen? Das möchte ich auch mal erklärt bekommen. > Wenn ich das > richtig seh, müsste man doch bei einer echten digitalen > Signalverarbeitung bereits die ZF digitalisieren, und das Signal per > Software demodulieren. Da kann ich mir auch echte Vorteile vorstellen, Sorry, ich sehe hier gerade keine Vorteile, außer dass die Geschichte in Software abgeglichen wird und nicht mehr über Trimmkonndensatoren und Spulen. > nur überschreitet das den Horizont meiner (derzeitigen) Fähigkeiten. > (und wohl auch den der meisten anderen hier) Zu diesen gehöre ich auch, lerne aber gerne dazu. > Außerdem – wenn du anprangerst, daß unser Konzept ein Autoradio der 80er > beschreibt Hmm, dies soll doch ein Radio werden, oder? Gut, eines, was Features bietet, welche nur von teuren und vergoldeten High-Dollar-Modellen geboten werden. Trotzdem bleibt es ein Autoradio. Mir reicht mein Radio eigentlich aus. Abgesehen von einigen Features, die komplett fehlen (eine Senderdurchstimmung über Drehregler vermisse ich schon seit Ewigkeiten). Wenn ich mich diesem Projekt anschließe, möchte ich ein Radio, welches mir das Radiohören noch besser gestalten lässt. 1. Weniger Störungen -> Diversity 2. Auf welcher Frequenz ist mein aktueller Sender besser zu empfangen? Wenn möglich, automatisch wechseln. 3. Auch wenn ich gerade einen Sender ohne Verkehrsfunk höre, wäre es gut, wenn das Radio die stärksten Nachbarsender kennt und im Bedarfsfall meinen Sender kurz unterbricht (spontane Idee: Time-Shift für Radio-Hörspiele). 4. RDS (TMC) 5. MP3-Karte anstatt Kassette oder CD-Player: gerne 6. Auch hilfreich: Aufzeichnung aller Verkehrsfunkmeldungen, die das Gerät habhaft werden kann. Abspielen auf Knopfdruck mit Navigation zwischen den Aufzeichnungen (zum Beispiel auch eine Meldung einfach nochmal hören, da während der Nennung der Autobahnnummer mein Sohn lauthals los geschrien hat). DVD/Video/Schlagzeug/Kaffeemaschine: Nein, danke.
Frage: wer weiss etwas über "Standalone AD/DA Wandler mit I²S Schnittstelle" ??? Wenn wir die hätten, wären wir wieder beim guten, alten 8bit-AVR....was ich nicht für die schlechteste Lösung halte! Harry
Christian H. schrieb: > Wenn ich mich diesem Projekt anschließe, möchte ich ein Radio, welches > mir das Radiohören noch besser gestalten lässt. > > > DVD/Video/Schlagzeug/Kaffeemaschine: Nein, danke. in allen Punkten: FULL ACK!!!! Harry
Ich werd jetzt einfach Jura oder Medizin studieren und die Technik hinter mir lassen. Es geht nimmer .
Patrick Weinberger schrieb: > Ich werd jetzt einfach Jura oder Medizin studieren und die Technik > hinter mir lassen. > Es geht nimmer . ahja....beruhigt mich, daß deine Argumentation nichts mit unserem Projekt zu tun hat :D Harry
Naja das mit dem im Kreis drehen geht mir auch schön langsam auf die nerven
Patrick Weinberger schrieb: > Naja das mit dem im Kreis drehen geht mir auch schön langsam auf die > nerven ACK aber ein SH muss es nun wirklich nicht sein ;) HArry
Nein von mir aus kanns auch ein 8051er sein. Aber es geht eher darum wie es jetzt mit den Modulen ist. Alle wollen was ähnliches aber jeder einen anderen Controller oder ....
Ich plädier dafür, das ganze "as simple as possible" zu machen. Über den angestrebten Mulitimedia-Slot kann jeder dann treiben was er/sie möchte. Wichtig ist mir, daß dabei am Ende ein wirklich tolles Radio rauskommt. Daß es auf dem Weg dorthin unterschiedliche Meinungen, und auch Konflikte gibt, ist völlig normal. Nur die Open-Source-Projekte, die das aushalten haben eine Chance, irgendwann etwas benutzbares hervor zu bringen. Das bei so einem (nicht gerade simplen Projekt) eine ausführliche/kontroverse Diskussion entsteht, nützt dem Projekt, und schadet ihm nicht! Wir sollten allerdings langsam mal einen Endpunkt finden, und die Features festschreiben. Harry
Aber noch schlimmer sind die immer sagen ich will das und das. Dann will aber niemand was dafür machen. Hab das beim letzten Projekt gehabt wo ich ein paar Mitschüler unterstützt hab. Zum Schluss soll man alles machen wenn man es ned macht, dann jammern sie dahin und werden beleidigend. Mfg Patrick
Patrick Weinberger schrieb: > Aber noch schlimmer sind die immer sagen ich will das und das. Dann will > aber niemand was dafür machen. > Hab das beim letzten Projekt gehabt wo ich ein paar Mitschüler > unterstützt hab. Zum Schluss soll man alles machen wenn man es ned > macht, dann jammern sie dahin und werden beleidigend. > > Mfg Patrick Wart mal ab!...es gibt immer die, die rummeckern, aber sonst nix beitragen...lass die mal machen!....lass dich nicht frustrieren!....im Lauf des Projekt zeigt sich dann ganz klar, wer ernsthaft an dem Radio interessiert ist. Du scheinst mir recht jung zu sein..lerne Geduld! ;) ;) lieben Gruss! Harry
Harald L. schrieb: > Frage: > wer weiss etwas über "Standalone AD/DA Wandler mit I²S Schnittstelle" > ??? > Wenn wir die hätten, wären wir wieder beim guten, alten 8bit-AVR....was > ich nicht für die schlechteste Lösung halte! Ahhhhhhhhhhhhhhhhh!!!!!!!!! Zum Thema RDS hab ich schon was geschrieben, oder? Und zu freq. diversity?!? Oh man, da schläft man mal ein paar stündchen und schwups... 17 neue Nachrichten... und man ist quasi wieder am Anfang angelangt :-( Wir können auch ein Intel 4040 einsetzen. Also auf minimum Arm7 werden wir uns doch einigen können, oder? Damit sollte doch keiner Probleme haben.
Ist ja ein feines Projekt! Ich bin auch an einem qualitativ ansprechendem Radioempfänger für's Auto interessiert. Jedoch hab auf die schnelle noch keinen Anbieter für TEF6616 gefunden... "Sollte recht preisgünstig sein " ist im Wiki zu lesen. Doch bevor ich keinen Lieferant und keinen Preis für ein Bauteil habe, beginne ich persönlich nicht, dieses ernsthaft in ein Projekt zu integrieren. Hab ich mich da nicht genug umgesehen? Weis da jemand mehr? LG Gabriel
Hallo, Wollte auch mal kurz mein Interesse an diesem Radio kundtun. Habe mir schon mehr Gedanken über ein eigenes Projekt gemacht, aber wegen fehlendem Elektronikwissen (und Zeit) bis jetzt verschoben. Meine Anforderungen: - Dual RDS Tuner (Followme oder wie heisst das ?). Damit ich meinen Lieblingssender hören kann. Höre sowieso immer denselben Sender... - 16GB oder besser 32GB SD Kartenanbindung für meine Musiksammlung Wichtig für mich, OGG oder Flac Codec, und nicht nur MP3. Bitte jetzt keine Diskussion über MP3 Qualität ;-) Meine Idee wäre gewesen, ein Board mit einem Cortex-M3, einem VLSI VS1053 für MP3 (und OGG !!), und einem qualitativ guten RDS Tuner zu nehmen. Dazu ein SD-Slot, ein Display und ein paar Knöpfe. Ein grosser Teil des Codes (ohne RDS Anbindung) wäre bereits vorhanden siehe (http://www.watterott.net/projects/webradio-arm). Leider kann ich aus beruflichen Gründen nicht allzuviel mithelfen. Wäre aber sicher bereit in der einen oder anderen Form einen Obolus zu leisten, wenn ich dafür eine Hardwarplattform bekäme. Gruss Daniel
hab hier mal ein paar interessante CODECs: TLV320AIC3254 Very Low-Power Stereo Audio CODEC with miniDSP and Power TuneTM Technology 6 analIns (+MIC) / 4 analOuts (-6..+29dB Gain (step 1dB)) "with miniDSP" also auch Klangregel usw machbar ..sehr hohe Integration [zw. ADC-DAC ist kein I2S(oder sonst) nötig] PCM3168A : 24-bit Multi-channel Audio CODEC 6ch-in/8ch-out with 96/192kHz sampling rate (kein miniDSP) (Outs haben 0 dB to –100 dB in 0.5-dB steps) [zw. ADC-DAC ist I2S(oder sonst) nötig] AD1937: Four ADCs/Eight DACs with PLL, 192 kHz, 24-Bit Codec (Outs haben ATT mit 255 steps a 0,375dB)) (bzw AD1936..39) [zw. ADC-DAC ist I2S(oder sonst) nötig] bei National gibts unter LM49xx auch einige, aber sind glaub nicht so hoch integriert und haben meist ClassD-Output (!) [zw. ADC-DAC ist kein I2S(oder sonst) nötig] weiter gibts von AD noch SigmaDSP, hat mit SigmaStudio graph. Oberflache zum generieren des Audio-Verhaltens , ohne ASM oder C. die SigmaDSPs könnte man als extrem hoch integrierte Codecs ansehen (weiss aber nicht ob SigmaStudio gratis, die SigmaDSPs sind nicht so teuer, haben aber wahrsch. BGA-Geh.(!)) [zw. ADC-DAC ist kein I2S(oder sonst) nötig]
Es gibt auch noch die C54/C55xx Serie von TI die das gleiche kann und trotzdem TQFP haben oder Blackfin, ADS21xx usw Man kann aber auch gleich eine FPGA oder so nehmen....
So viel Text... Wow! Ok, nur um mal einem Missverständnis vor zu beugen. Ich möchte nicht das ganze Radio auf einem ATmega8 laufen lassen, ich wollte nur darstellen, was auf einem kleinen Proz schon möglich ist. Natürlich macht es, allein vom Preis her, keinen Sinn solch einen kleinen Zwerg zu nehmen. Ich dachte eher an einen STM32F103RE. 512kB Flash, 64kB RAM. Das sollte genug sein, um Playlisten, RDS, TMC und weiteres zu verarbeiten. Die Becker Cascade Plattform (Richtig geraten, Kai) macht das alles ebenfalls und hat deutlich weniger RAM und Flash. Das Verlöten eines 64-Pinner ist von Hand kein Problem, und ebenso ist es von Hand kein Problem 0402er Kondensatoren zu verlöten. Ob es 0402er sein müssen oder 0603er reichen, wird das Layout zeigen. Ich bin aber sehr unglücklich mit der Lösung, jede Funktion auf eine Aufsteckplatine zu verbannen. Diese müssten entweder als Sandwich gestapelt werden, was zu enormen Temperaturproblemen führen wird, oder als vertiakel Options-Boards. Letzteres erfordert vernünftige Steckverbinder, die mächtig viel Platz benötigen und sehr teuer sind, weil Wetterfest, temperaturstabil und Vibrationsfest. Außerdem wird damit der Bauraum auch in der Höhe zugepflastert, was das Einbauen einer kleinen Festplatte oder eines CD/DVD Drives unmöglich macht. Der Kompromiss wäre allerdings, dass man es macht, wie die Cascade auf meinem Bild oben. Die Platine beinhaltet alle Funktionen für den gemeinsamen Nenner aller darauf basierenden Geräte. Unten links ist vermutlich der BlueTooth Chipsatz nicht bestückt, weil das Radio nur das Indianapolis, aber nicht das Indi-Pro ist. Das Mexico müsste auch auf diesem Board aufsetzen, da ist dann das Navi (liks) nicht bestückt. Mein Vorschlag wäre also ein Kompromiss der folgenden Art: Basis-Funktionen on Board Optionen als Plugin. Ich persönlich halte es für unsinnig bei einem Radio den Tuner als Plugin zu machen. Der Tuner braucht, gerade bei Dual-Tuner mit Diversity, eine sehr enge Auslegung und räumliche Anpassung. Dagegen ist es sehr leicht, einfach einen Tuner weg zu lassen, wenn man es nicht möchte. Der VLSI-Chip benötigt nur sehr wenig Fläche und kann gleich neben den Ausio-Mux plaziert werden. Es ging in der Aufgabenstellung zu diesem Thread um ein Auto-Radio mit MP3 Fähigkeit. Wenn wir nun jede Aufgabe als Plugin konzipieren, reichen die Steckerleisten bis in den Motorraum oder Leute, die mehr haben wollen müssen auf Doppel-DIN oder auf Eigenentwicklungen zurückgreifen, wo ein Plugin eben neben 2xTuner auch noch MP3 enthält, damit sie noch ein BlueTooth Board, ein Navi-Board, ein Video-Board... Unterbringen. Wir bekommen in dem kleinen MP3-Decoder doch schon viele weitere Formate mit. Leider hat der STM32F103 kein Host-USB/OTG aber auch da gibt es zwei Möglichkeiten. Entweder eine größere CPU ala STM32F107, da wäre dann Ethernet auch gleich mit drinn, oder eben einen Chip, wie den Vinculum, für WLAN ein Modul von Atmel. Allerdings führen bei diesen Chips lange Leiterbahnen und Steckverbinder gleich zu Problemen. Ein 25MHz SPI-Bus ist schon fast HF-Technik. Also lassen wir doch einfach mal abstimmen, wer sich was in der Grundausstattung wünscht. Man muss ja auch beachten, dass eine Platine grundsätzlich erst einmal Kosten verursacht, egal, ob sie klein oder groß ist. Sinken tut der Preis dann nur über die Stückzahl. Es ist viel billiger einfach ein paar unnötige Bauteile weg zu lassen. Gruß, Ulrich
Gabriel Wegscheider schrieb: > Ich bin auch an einem qualitativ ansprechendem Radioempfänger für's Auto > interessiert. Jep, auf jeden Fall und damit bleibt nur NXP für den Tuner übrig :) > Jedoch hab auf die schnelle noch keinen Anbieter für TEF6616 gefunden... > "Sollte recht preisgünstig sein " ist im Wiki zu lesen. Doch bevor ich Das ist auch nicht möglich, denn NXP sagt auf seiner Webseite ja, dass der Chip im Sample-State ist. Ausgesuchte Interessenten bekommen davon Muster, in Stückzahlen kaufen kann man ihn noch nicht.
Ulrich P. schrieb: > Ich bin aber sehr unglücklich mit der Lösung, jede Funktion auf eine > Aufsteckplatine zu verbannen. Diese müssten entweder als Sandwich > gestapelt werden, was zu enormen Temperaturproblemen führen wird, oder > als vertiakel Options-Boards. Letzteres erfordert vernünftige > Steckverbinder, die mächtig viel Platz benötigen und sehr teuer sind, > weil Wetterfest, temperaturstabil und Vibrationsfest. Außerdem wird Es soll nicht alles modularisiert werden, sondern es ist genau 1 Multimedia-Steckplatz vorgesehen, um dort ggf. einen leistungsfähigeren (Linux-)Rechner unterbringen zu können. Ansonsten gibt es nur das Mainboard und das Bedienteil. > damit der Bauraum auch in der Höhe zugepflastert, was das Einbauen einer > kleinen Festplatte oder eines CD/DVD Drives unmöglich macht. CD und/oder Festplatte war nie vorgesehen! > Mein Vorschlag wäre also ein Kompromiss der folgenden Art: > Basis-Funktionen on Board > Optionen als Plugin. > Ich persönlich halte es für unsinnig bei einem Radio den Tuner als > Plugin zu machen. Der Tuner braucht, gerade bei Dual-Tuner mit > Diversity, eine sehr enge Auslegung und räumliche Anpassung. Dagegen ist > es sehr leicht, einfach einen Tuner weg zu lassen, wenn man es nicht > möchte. ACK s.o. > > Der VLSI-Chip benötigt nur sehr wenig Fläche und kann gleich neben den > Ausio-Mux plaziert werden. Es ging in der Aufgabenstellung zu diesem > Thread um ein Auto-Radio mit MP3 Fähigkeit. Wenn wir nun jede Aufgabe > als Plugin konzipieren, reichen die Steckerleisten bis in den Motorraum Entweder die Mainboard-CPU macht das mp3-Decoding (wie von Kai vorgeschlagen), oder der VLSI sitzt als Minimal-Lösung auf dem Multimedia-Board. Die, die dort Linux einsetzen wollen, brauchen den VLSI ja nicht, und setzen eben ein anderes Board ein. > für WLAN ein Modul von Atmel. Sicher nicht Atmel!...wenn dann Atheros! Der kann dann nämlich auch AP-Mode, und ist ordentllich dokumentiert. Steht allerdings im Augenblick auch gar nicht zur Debatte. Wenn WLAN, dann via USB angebunden. Nur so kann man die Antenne an einen sinvollen Ort bauen. Harry
Ulrich P. schrieb: > Gabriel Wegscheider schrieb: >> Ich bin auch an einem qualitativ ansprechendem Radioempfänger für's Auto >> interessiert. > Jep, auf jeden Fall und damit bleibt nur NXP für den Tuner übrig :) > >> Jedoch hab auf die schnelle noch keinen Anbieter für TEF6616 gefunden... >> "Sollte recht preisgünstig sein " ist im Wiki zu lesen. Doch bevor ich > > Das ist auch nicht möglich, denn NXP sagt auf seiner Webseite ja, dass > der Chip im Sample-State ist. Ausgesuchte Interessenten bekommen davon > Muster, in Stückzahlen kaufen kann man ihn noch nicht. Wollen wir WIRKLICH ein Teil einplanen, das noch nicht kommerziell zu beschaffen ist? Irgentwie bin ich offenbar zu ungeschickt, aber ich hab's noch nicht geschafft, Samples von NXP zu bekommen... Wie soll das dann gehen? Jeder interessierte Mitgestalter sampled dann einen TEFxy? Ich weis nicht... Gibt's da nicht gute Chips, die normal via Farnell/Digikey/RS/... für Privatpersonen in Stückzahlen unter 10.000 zu einem fairen Preis zu haben sind? LG Gabriel
Patrick Weinberger schrieb: > Aber noch schlimmer sind die immer sagen ich will das und das. Ja, ich gehöre zu diesen Leuten. Was ist dagegen auszusetzen? > Dann will aber niemand was dafür machen. Bis jetzt kann auch niemand was anderes machen, als Vorschläge machen. > Hab das beim letzten Projekt gehabt wo ich ein paar Mitschüler > unterstützt hab. Zum Schluss soll man alles machen wenn man es ned > macht, dann jammern sie dahin und werden beleidigend. Wer hat gesagt, dass Du das alleine machen sollst? War das Projekt Deine Idee? -------------------------------------------------------------- Im Moment geht es um die Frage, ob MP3 der Hauptprozessor machen, oder ob hierzu vielleicht eher ein IC verwendet werden soll. Ich bin hierbei für das IC. Die Möglichkeit, das IC einfach nicht zu bestücken, sondern MP3 einem dickeren Prozessor zu überlassen, finde ich gut. Modularisierung um jeden Preis, ist nicht gut. Ich wäre für genau drei Module. Das Radio alleine (ohne GUI/MP3), sollte ein Modul sein. Zusätzliche Audioquellen sollten natürlich einspeisbar sein (CD/DVD/Navi/Mobiltelefon/MP3). Das Modul muss dies dann natürlich handeln können. Dieses Modul soll auch schon in dieser Bauform vollständig lauffähig sein (also inklusive Verstärker). Zur Bedienung muss dann halt ein Terminalprogramm verwendet werden. Als zweites Modul kommt für mich die MP3-Geschichte in Frage. Entweder mit Codec-IC (mein Favorit) und/oder in Software. Da MP3 Pflicht zu sein scheint (ist für mich ok), muss dieses Modul auch einen Kartenslot haben. Das bedeutet, es müssen Dateisysteme lesbar sein. Auch USB wäre hier sinnvoll, denn man möchte vielleicht auch einen USB-Stick als Datenlieferant einsetzen. Wenn USB-Sticks möglich wären, sollte eine Festplatte auch kein Problem mehr sein (hoffe ich zumindest). Achtung Idee: An meinem Rechner habe ich einen Mehrformat-Kartenleser. Dieser meldet sich unter Windows mit mehreren Laufwerksbuchstaben. Es können dadurch auch verschiedene Karten gleichzeitig verwendet werden. Das wäre auch für das Radio interessant. Auch dieses Modul soll alleine Lauffähig sein (ok, Verstärker und Terminal müssen noch dran). Dieses Modul würde es wohl in zwei (bzw drei) Varianten geben: a) kleinerer Prozessor und MP3 als IC b) größerer Prozessor und MP3 in Software c) entfällt, da MP3 in der GUI (zB Linux) abgehandelt wird => Car-PC Das dritte Modul wäre die GUI. Dazu gehört auch die optionale Bedienung eines optionalen CD/DVD-Laufwerkes. Wer Videos abspielen möchte, kann das auch in diesem Modul abhandeln. Dieses Modul kann es auch in mehreren Varianten geben: a) kleinerer Prozessor, der nur Tastendrücke auswertet und ein LCD bedient b) größerer Prozessor mit grafischer GUI und Touch-Panel. c) Linux d) ... Dieses Modul könnte auch das zweite beinhalten. Vorteil dieser Aufteilung wäre, dass jeder "sein" Radio so zusammenstellen kann, wie er es braucht. Auch die Verwendung des MP3-Moduls in einem anderen Projekt, wäre denkbar.
Christian H. schrieb: > Ich wäre für genau drei Module. > > > Das Radio alleine (ohne GUI/MP3), sollte ein Modul sein. > > Zusätzliche Audioquellen sollten natürlich einspeisbar sein > (CD/DVD/Navi/Mobiltelefon/MP3). Das Modul muss dies dann natürlich > handeln können. > > Dieses Modul soll auch schon in dieser Bauform vollständig lauffähig > sein (also inklusive Verstärker). Zur Bedienung muss dann halt ein > Terminalprogramm verwendet werden. > Entspricht exakt der bisherigen Planung > > Als zweites Modul kommt für mich die MP3-Geschichte in Frage. > Entweder mit Codec-IC (mein Favorit) und/oder in Software. > > Da MP3 Pflicht zu sein scheint (ist für mich ok), muss dieses Modul auch > einen Kartenslot haben. Das bedeutet, es müssen Dateisysteme lesbar > sein. > Auch USB wäre hier sinnvoll, denn man möchte vielleicht auch einen > USB-Stick als Datenlieferant einsetzen. Das Motherboard selbst hat kein USB. > > Wenn USB-Sticks möglich wären, sollte eine Festplatte auch kein Problem > mehr sein (hoffe ich zumindest). > und wie lange soll die im Auto halten? > Achtung Idee: > An meinem Rechner habe ich einen Mehrformat-Kartenleser. Dieser meldet > sich unter Windows mit mehreren Laufwerksbuchstaben. Es können dadurch > auch verschiedene Karten gleichzeitig verwendet werden. Das wäre auch > für das Radio interessant. s.o. Kein USB – kein USB-Kartenleser > > Auch dieses Modul soll alleine Lauffähig sein (ok, Verstärker und > Terminal müssen noch dran). > > Dieses Modul würde es wohl in zwei (bzw drei) Varianten geben: du meinst das (optionale) Multimedia-Modul? Das läuft auf 3 Varianten hinaus: * mp3-Only (decodierung via Mainboard-CPU) - Multimediamodul wird nicht eingebaut. * mp3 plus weitere Formate per Chip als Multimedia-light Board * kompl. Linux-Rechner incl. Decodierung als Multimediaboard. > > Das dritte Modul wäre die GUI. Dazu gehört auch die optionale > Bedienung eines optionalen CD/DVD-Laufwerkes. Wo und wie willst du das anschliessen? Aber vor allem warum? > > Wer Videos abspielen möchte, kann das auch in diesem Modul abhandeln. Steht derzeit nicht zur Debatte. Das wird ein Autoradio und kein TV-Gerät. > > Dieses Modul kann es auch in mehreren Varianten geben: Nein! Genau ein Bedienteil mit klar definierter Schnittstelle. Kein Linux - kein Schnickschnack Variieren kann man bei dem Multimediamodul. Harry
Hmmm... Lassen wir uns dieses Design mal durch den Kopf gehen: Wenn man Tuner und Verstärker auf ein Modul kleben will und die Basisplatine nur die CPU beinhaltet, dann passt das ganze nicht wirklich in einen DIN-Schacht. Wenn man 4 Class-D Amps zusammen mit zwei Tunern und mind. einem Sound-Controller IC auf eine Platine klebt, dann nimmt diese schon die Breite eines Radios und knapp die Hälfte seiner Tiefe ein. Es wird mechanisch auch interessant die nötigen Kühlflächen an einem Addon-Board zu platzieren. Ebenfalls interessant werden die verwendeten PKW-Stecker, denn die haben bereits die Höhe eines Radios und sind für TH oder SMD Montage auf dem Basis-Board vorgesehen. Es läuft also auf 6..8 Befestigungsbolzen hinaus um das Platinchen sicher und vibrationsarm aufzuhängen. Dazu kommen Steckverbinder, die auf 8..12V fröhliche 6..10A Peak verkraften können. Daneben aber auch welche, die sauber getrennt digitale und analoge Signale übertragen können. Eventuell kann man das Design so auslegen, dass die CPU-Platine unten und die Tuner/Class-D Platine Überkopf als Deckel darüber sitzt. Dazwischen können dann noch andere Boards platziert werden. Wird ebenfalls mechanisch interessant, da damit der Kühlkörper von der oberen Platine getragen wird und alles andere dazwischen sitzen muss. Die Abwärme wird in die Platinenfläche übertragen, die sehr schlecht selbige leitet. Also schauen wir mal weiter. Die CPU Platine wird neben selbiger auch mind. mal folgende DC/DC Wandler beinhalten: 8.5V Tuner, 3.3V Digital, 3.3V Analog, 8.5V oder gefilterte 12V Class-D, 1.8V CPU Core, eventuell noch 10..15V Buck/Boost für OLED oder LCD. Also eigentlich ist das Board nur zu einem Drittel, vielleicht der Hälfte gefüllt. Hinten ist kein Platz mehr, da sitzen der Kühlkörper, der von oben kommt. Bleibt also noch Platz für eine 1.5" oder eine 2" HDD, nur so zum Größenvergleich. Das ist, mit Verlaub gesagt, kein guter Ansatz. Können wir nicht einfach abstimmen, welche Features diejenigen haben wollen, die aktiv zu dem Projekt beitragen wollen? Diese kommen auf die Basisplatine. Alles andere kann dann immer noch in senkrecht einschiebbaren Karten untergebracht werden. Wenn man sich das Becker oben ansieht, wäre es möglich links locker mal zwei Steckkarten unter zu bringen, auch wenn das Laufwerk drin sitzt. Den Bauraum vom Laufwerk könnte man für weitere Karten nutzen oder eben für eine HDD oder Kartenleser oder was auch immer. Gehen wir das ganze Konzept mal von der anderen Seite an: Der VLSI wird in kleinen Häppchen von 32 Bytes bei ca. 1Mbit gefüttert. Kein Problem, der kann auch ins Handschuhfach vom Bus her. Aber, er nimmt kaum Platz weg und würde auf dem Mainboard in der Nähe des Audio-Controllers auch bei FLAC guten Klang bringen, wenn er nicht über weite Leitungen sein Audio zum MUX bringen müsste. Über Stecker und etliche cm Leitung ( ein Stecker sind auch 'nur' ein paar cm Leitung) kann die Qualität leiden und das obige Design würde ja bedeuten, dass es vom MP3-Board erst mal auf das Mainboard und von da aus wieder auf das Tuner/Class-D Board hoch... Das gleiche gilt im Grunde auch für Netzwerk und USB oder SD. Jaja, lasst mich mal zu Ende denken... Ein Host-USB-Bus muss sauber geführt werden, sonst gibt es Probleme beim Verbinden und Daten übertragen. Da die CPU bereits USB hat (haben kann) müsste man also eine eigene Steckkarte für lediglich 6 SMD Bauteile 0603 und einen SO8 Chip machen, die aber mind. 500mA bei 5V zur Verfügung stellt, obwohl man wahrscheinlich schon einen DC/DC für 5V auf dem Mainboard hat, der nur ein paar mm größer ausfallen würde, wenn er die 500mA (oder 1A bei zwei Slots) gleich mitliefern sollte. Auch wenn man USB einfach machen will und einen FTDI Vinculum einsetzt, würde das lediglich ~7x7mm mehr bedeuten, der SPI-Bus muss aber dann wieder ordentlich Speed bringen. Also sollte der nicht zu lang sein, sonst geht er nicht, oder man hört ihn in den Boxen? SD-Card wäre ein Steckboard mit nicht einmal 6 Bauteilen, denn die karte muss lediglich an einen SD- oder auch nur an einen SPI-Bus angeschlossen werden. Allerdings gebe ich zu, dass die SD-Card besser auf einem kleinen Platinchen sitzt, damit man sie nach eigenen Vorstellungen in der Front platzieren kann. Aber auch hier bedeutet ein ungeschicktes Layout und zu viele Stecker das Problem, dass die Busgeschwindigkeit einbricht. Also wenn das Konzept, die Basisfunktionen bereits auf ein Addon Board zu setzen sich durchsetzt, dann steige ich aus. D.h. nicht, das ich garnicht mehr mitmache, aber ich werde dann bei der Hardware eigene Wege gehen. Eventuell gleiche Chips, gleiche CPU aber anderer Aufbau. Wenn es jetzt schon um die Basisplatine und Basis-Features so ein gerangel gibt, bin ich mal auf die Gestaltung der Frontblende gespannt :) OLED mit Capacitive-Touch ganz ohne sichtbare Tasten? Oder doch ein LCD mit ein paar Knöppen darunter? Frontblende als Klappe damit USB und SD dahinter passen, oder USB und SD als Schlitz? Ich persönlich bin gegen Geschosse im PKW, die auch noch leicht abbrechen, wenn man mal nicht aufpasst, also USB lieber hinten raus und als kleines Döschen im Handschuhfach oder in der Mittelkonsole. SD-Card ist ne gut Idee, aber MicroSD und MiniSD sind für PKW ungeeignet, denn sie können in Schlitze fallen aus denen man sie nie wieder befreien kann ohne das Interieur zu zerlegen. Lenkt auch ganz schön ab das fummelige Zeug. Trotzdem ist es praktisch und mit SDHC endlich auch groß genug. Also rein damit. Eventuell SD als Tray-Loader? Einfach 6 Kärtchen auf die Lade legen und dann zufahren lassen. Ist mechanisch aber sehr anspruchsvoll, wenn man keinen Kunststoff-Rapid-Prototyper hat. Ok, genug Ideen ausgeplaudert :) Bin mal gespannt, wie das nun weiter geht. Gruß, Ulrich
@Ulrich das (vorläufige) Blockschaltbild kennst du? http://osar.it-livetalk.de/index.php/Blockschaltbild Das Mainboard beinhaltet Tuner, Verstärker, Stromversorgung eine angemessene CPU und den Multimediaslot auf EINEM Board. Das steht aber auch alles bereits im Wiki, und hier im Forum wurde das auch gefühlte 100mal erklärt. Harry
Hi Harry, sorry, aber die Diskussion oben liest sich anders als es das Blockschaltbild beschreibt. Bin trotzdem verwirrt, wie Du das Audio-Signal aus dem uC in die AMPs bekommen möchtest. Gruß, Ulrich
Harald L. schrieb: > Das Motherboard selbst hat kein USB. Schade, dann fallen USB-Sticks weg. >> Wenn USB-Sticks möglich wären, sollte eine Festplatte auch kein Problem >> mehr sein (hoffe ich zumindest). >> > und wie lange soll die im Auto halten? Muss ja nicht unbedingt im Auto verbaut sein. >> Das dritte Modul wäre die GUI. Dazu gehört auch die optionale >> Bedienung eines optionalen CD/DVD-Laufwerkes. > > Wo und wie willst du das anschliessen? Wie schon gesagt, stelle ich mir die Hauptkomponenten (Radio/Multimedia) so vor, dass ich diese auch autark laufen lassen kann und bei Bedarf per RS232; I2C (oder ähnliches) bedienen kann. Dafür kann ich mir dann auch eine GUI nach eigener Vorstellung zusammen bauen. > Aber vor allem warum? Warum? Wie bediene ich das Gerät? Durch Gedankenverbindung? > Nein! Genau ein Bedienteil mit klar definierter Schnittstelle. Kein > Linux - kein Schnickschnack Ich kann also kein eigenes Bedienteil verwenden? Ich bin also mit diesem Projekt auf genau dieses Gerät mit genau diesen Funktionen und genau diesem Aussehen (GUI) beschränkt. Das habe ich auch bei den kommerziell verfügbaren Geräten. Hmm, also nichts für mich. Dann lehne ich mich einfach zurück und beobachte die weitere Entwicklung. Mal sehen, ob dann doch noch etwas für mich brauchbares abfällt. Ich hatte ja gehofft, dass man bei diesem Projekt seinen Spieltrieb (eigenes Design, eigene Funktionen) verwirklichen kann.
Soo, ich habe mir das Blockschaltbild nochmal genau angesehen. Es ist doch nicht so weit von meiner Vorstellung entfernt. Mein "GUI"-Modul entspricht dem "Frontpanel PCB". Mein "MP3"-Modul entspricht dem "Car PC"-Modul (Multimedia-Modul) nur das letzteres im Blockschaltbild keine Audio-Daten zum "Main PCB" übertragen kann. Mir fehlt zum glücklich werden also nur noch die USB-Funktion des Basismoduls. Dies könnte ich aber auch im "Car PC"-Modul abhandeln, falls eine Audio-Rückführung existiert. Ansonsten schließe ich mich Ulrich P. an: Ulrich P. schrieb: > D.h. nicht, das ich > garnicht mehr mitmache, aber ich werde dann bei der Hardware eigene Wege > gehen. Eventuell gleiche Chips, gleiche CPU aber anderer Aufbau.
Ich habe ja schon ein wenig Überzeugungsarbeit geleistet, was die Basis angeht. Wenn man sich auf Nut/OS als Betriebssystem einigen kann, dann könnte man natürlich die Bibliotheken nutzen, die für einen Chip bereits geschrieben wurden, und muss sich nur noch auf das Layout konzentrieren. Findet man da Probleme, kann man das OSCAR wissen lassen, ehe sie selber drüber stolpern. Man kann auch alternative Bibliotheken schreiben für andere Bausteine und der nächste mischt kunterbunt. Die GUI ist eine ganz andere Sache. Bei einem Radio ist diese in der Regel schmal und informativ, jedenfalls, wenn man ein gewisses Alter erreicht hat. Bunt darf sie schon sein, aber das bedeutet nicht, dass man massenhaft Daten übertragen muss. Es reicht ein kleine Controller, vielleicht mit QTouch, damit man nicht eine kleine Plexiglas-Scheibe mit 40 schiefen Löchern versehen muss. Außerdem wäre das Radio im abgeschalteten Zustand fast unsichtbar. Der kleine Controller bekommt ein mittleres Serial-Flash zur Seite und kann daraus Unmengen an bunten Icons schaufeln und darstellen. Per I2C bekommt er aus dem Audio-Proz noch ein paar EQ/FFT Daten, damit auch ein Spekki dargestellt werden kann. Alles kein Problem. Für die vielen bunten Symbole ist es wirklich billiger einen ATmega8 zu nehmen und ein 512kB Serial-Flash als einen CortexM3 mit 128k Flash. Ist also alles machbar. Momentan ist das Mainboard nach dem Blockschaltbild noch ziemlich leer. Ich denke fast, dass ein VLSI oder FTDI noch dazu kommen, allein um das Board voll zu bekommen. Ich meine, eine Prototypen-Platine kostet ca. 70€. Ich würde mich echt ärgern, wenn ich die berappen müsste, obwohl das Main-PCB noch leer ist. ;) Gruß, Ulrich
Christian H. schrieb: > Ich kann also kein eigenes Bedienteil verwenden? Ich bin also mit diesem > Projekt auf genau dieses Gerät mit genau diesen Funktionen und genau > diesem Aussehen (GUI) beschränkt. Das habe ich auch bei den kommerziell > verfügbaren Geräten. > da hab ich mich wohl misverständlich ausgedrückt. Natürlich kannst du da was Eigenes machen. Nur wird im Rahmen dieses Projekt eben nur 1 Bedienteil entwickelt. Das Blockschaltbild hatte ich bewusst als "vorläufig" gekennzeichnet. Ist auch richtig, daß da noch die Audio-Pfade und weitere Anschlüsse zum Multimediaboard etc fehlen. Das war lediglich unser erster Entwurf, der die Verteilung der Komponenten auf die Baugruppen aufzeigen soll. Harry
Ulrich P. schrieb: > Ist also alles machbar. Momentan ist das Mainboard nach dem > Blockschaltbild noch ziemlich leer. Ich denke fast, dass ein VLSI oder > FTDI noch dazu kommen, allein um das Board voll zu bekommen. Mit FTDI meinst Du ein Vinculum (USB-Interface)? Etwa sowas? http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=20659&flv=1&bereich=&marke= Wenn ich damit "MP3" abspielen könnte, wäre ich bedient.
> Mit FTDI meinst Du ein Vinculum (USB-Interface)? Etwa sowas? > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=20659&flv=1&bereich=&marke= > > Wenn ich damit "MP3" abspielen könnte, wäre ich bedient. Ja, das meinte ich. Der VINCULUM ist ein autonomes USB-System, das sich bereits um Dateisystem und ähnliches kümmert. Man muss praktisch nur noch das Verzeichnis auslesen, eine Datei selektieren und dann kommen die Daten. In wie fern die Realität bei diesem Chip hält, was die Werbung verspricht, kann ich aber noch nicht sagen. Hatte so ein Teilchen mal an einem ATmega32 laufen, funktionierte recht einfach, habe es aber nicht auf alle möglichen Dateisysteme und Naming-Konventionen getestet. Damals war der Chip auch noch sehr jung. Wäre interessant zu wissen, ob der Vinculum per USART gesteuert werden kann aber per SPI dann die Daten streamt. Dann könnte man ihn direkt mit einem VLSI Decoder verheiraten und braucht nur noch einen kleinen Controller um die Steuerung zu übernehmen. Aber da hat sich einiges getan: http://www.vinculum.com/prd_vmusic1.html Gruß, Ulrich
Auweia! Kaum ein paar Tage nicht online und schon kommt man nicht mehr mit. :( Wir sind also vom SH7264 wieder weg und stehen wieder ganz am Anfang?
Pezi schrieb: > Auweia! Kaum ein paar Tage nicht online und schon kommt man nicht mehr > mit. :( > Wir sind also vom SH7264 wieder weg und stehen wieder ganz am Anfang? Nein, keine Sorge, es hat sich nicht alles gehändert. Es sieht schlimmer aus als es ist :-) Das Grundkonzept steht. Mehr dazu später.
Ulrich P. schrieb: > [...Vinculum...] Och nö, nicht so ein fertig-dings (kenn den Vinculum auch nicht nur vom sehen)... Aber dann wird es ja GANZ langweilig. Ich wollte sooo gern einen kleinen, kompakten auf USB Mass storage only zugeschnittenen USB Host stack auf dem µC sehen...
Kai G. schrieb: > Och nö, nicht so ein fertig-dings (kenn den Vinculum auch nicht nur vom > sehen)... Aber dann wird es ja GANZ langweilig. So langweilig finde ich das Teil garnicht. Ich habe mir mal einen geordert, um ihn mal genauer anzusehen/auszuprobieren.
Christian H. schrieb: > So langweilig finde ich das Teil garnicht. Ich habe mir mal einen > geordert, um ihn mal genauer anzusehen/auszuprobieren. Klar, für sich genommen ist das schon ziemlich gut und einzigartig, aber in so einem Autoradio-Gesamtsystem find ich es nicht sehr schön wenn der haupt-µC schon einen USB Host port mit sich bringt.
Hallo Kai! LOL! Also ich bin ja auch eher dafür, dass der uC einen OTG-USB Port hat und der MassStorage Host auf dem uC läuft. Es sind ja nur 6 Bauteile dafür notwendig. Aber man muss da auch viel selber machen. Viele Hersteller geben einem ein Software-Paket mit, dass diese Dinge bereits als Demo realisiert. Wenn man sich dann den Disclaimer durchliest, hat man plötzlich ein Problem mit der GPL oder der BSD Lizenz. Da stehen nämlich so kleine Gemeinheiten drin, dass man den Code nutzen aber nicht anderweitig online stellen darf, oder man mit diesem Code an den Hersteller gebunden ist und so weiter. Das ist ein Grund, warum es für Nut/OS noch keine USB-Lib gibt, den Code schreiben wir gerade selber, weil ATMEL nicht bereit ist eine Klausel aus dem Disclaimer zu entfernen. Der Vinculum würde zudem auch das Problem erschlagen, dass man viel RAM für ein großes Directory-Caching bereithalten muss, oder dass man den USB-Bus über lange Wege und Stecker führen muss. Es läuft halt alles über SPI (USART scheidet in unserem Konzept allein wegen der niedrigen Baudrate schon mal aus). Dass man bei dem Teilchen auch noch die Software ändern kann, macht es um so interessanter.
Christian H. schrieb: > Kai G. schrieb: >> Och nö, nicht so ein fertig-dings (kenn den Vinculum auch nicht nur vom >> sehen)... Aber dann wird es ja GANZ langweilig. > > So langweilig finde ich das Teil garnicht. Ich habe mir mal einen > geordert, um ihn mal genauer anzusehen/auszuprobieren. Was heißt langweilig? Selber bauen ist unwirtschaftlich ... Sowohl vom Zeit- als auch vom Geld-Bedarf ... Ihr dürft auch nicht vergessen, dass die Chance immer kleiner wird, dass das Ding jemals fertig wird, je mehr Geld und Zeit investiert werden muss ... Zum Schluss sind es eh nur 2 Leute, die die ganze Arbeit machen ... Dahergeredet ist gleich, etwas zu tun, ist aber etwas ganz anderes ... Wenn ihr was komplett eigenes entwickelt, müsste das schon einzigartig sein, dass sich der Aufwand rechnet ... Grüße, Thomas
Hi Ulrich! Mit USB kenn ich mich zufällig verdammt gut aus. So einen Host stack der nur für Mass storage ist (Also nichtmal HUB-support) trau ich mir zu from scratch in begrenzter Zeit zu schreiben. Zumal USB auch, wie ich bei den meisten hier raushörte eher optional ist und nicht von beginn an dabei sein muss. Es hat auch keinen Sinn das board komplett Zuzukleistern nur weil man Platz hat und dann ein unheimlich kompliziertes Layout zu haben (ZEIT!). Es ist ja auch nicht nur der Platz für den Chip an sich auf dem Board, für die Verbindungen zwischen den ICs braucht man auch Platz, der je nach anzahl der benutzten Layer nicht zu vernachlässigen ist. Das DIR-Caching für MP3 ist unproblematisch, ich hatte relativ am Anfang mal was dazu geschrieben. viele Grüße, Kai
Kai G. schrieb: > Mit USB kenn ich mich zufällig verdammt gut aus. So einen Host stack der > nur für Mass storage ist (Also nichtmal HUB-support) trau ich mir zu > from scratch in begrenzter Zeit zu schreiben. Wenn das stimmt (bezweifle ich nicht), kann man das auch gerne im Hauptprozessor machen. USB finde ich halt sehr interessant, da ein Stick einfach nicht so empfindlich, wie eine SD-Karte ist. Letztere hat meine Frau schonmal abgebrochen - die Karte steckte in einem USB-Adapter und schaute etwas 1cm raus. Sie ist noch verwendbar, aber ich vertraue ihr nur noch Testdaten an.
Christian H. schrieb: > Wenn das stimmt (bezweifle ich nicht), kann man das auch gerne im > Hauptprozessor machen. USB finde ich halt sehr interessant, da ein Stick > einfach nicht so empfindlich, wie eine SD-Karte ist. Letztere hat meine > Frau schonmal abgebrochen - die Karte steckte in einem USB-Adapter und > schaute etwas 1cm raus. Sie ist noch verwendbar, aber ich vertraue ihr > nur noch Testdaten an. OK, neue (mechanische) Design Anforderung: SD Karten dürfen nicht zu weit rausstehen :-) USB steht bei mir zumindest nicht so weit oben auf der Liste weil es mechanisch gesehen nicht so toll ist. Ich will nicht ständig einen USB Stick in der Radio-Front stecken haben (Gefährlich wg. abbrechen wenn man wild um sich fuchtelt weil man sich gerade über den Vordermann aufregt). Höchstens um neue Daten auf die SD/MMC Karten zu packen oder so wär es akzeptabel in der Front zu haben... Andernfalls wäre ein Kabel denkbar das hinten aus dem Radio rauskommt und man irgendwo im Handschuhfach versteckt oder so.
Bzgl. USB sind wir dann schon zwei, obwohl ich mehr auf der Device-Seite arbeite :)
Ulrich P. schrieb: > Bzgl. USB sind wir dann schon zwei, obwohl ich mehr auf der Device-Seite > arbeite :) Astrein, wenn Du die Device-Seite von der Mass-storage Klasse kennst hast Du schon die halbe Miete und ich nicht die ganze Arbeit alleine :-)
Wie ich immer leichtfertig sage, USB ist auch nur ein serieller Bus :) MS-Class habe ich nich nicht gemacht, nur CDC und Vendor-Specific, aber ich habe schon in den Sourcen gestöbert und sehe da kein größeres Problem.
Was haltet ihr von dem Chip? http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT2348_S.pdf oder auch dieser... http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT12311-s.pdf
Benjamin Maresch schrieb: > Was haltet ihr von dem Chip? Genau sowas suchte ich gerade. Ist der irgendwo außerhalb von China zu bekommen? Edit: Sorry, Taiwan nicht China :-)
Ok, dann machen wir den Topf doch mal mit Deckel Anforderung 1: System soll mit einer dokumentierten API existieren, dass Hardware und Steuer-Software voneinander trennt. Dabei gibt es zwei Extrema: 1) Schnelles spezialisiertes System, einfach und Laien-gerecht 2) Linux forever mit Video/CoDecs/QT.... Anforderung 2: Puristische Hardware mit diskreten Chips, die mit wenigen I2C Kommandos das erste Audiosignal vom Tuner in die AMPs schiebt. Aber auch komplexe CoDecs auf Linux-CPU mit Video-Out, Headrest-LCD, Optical SPDIF nach hinten, Remote-Control u.s.w. Und doch soll sich auch alles mit Hausmitteln löten lassen. Das ganze ist machbar. Wir machen ein Audio-Board mit einem CPU-Träger: http://www.ic-board.de/index.php?cat=c25_OEM-Module.html&XTCsid=0fb264979ec45cd8bb932418861f5b93 Die ADB1000 Module bzw deren Hirose-Stecker sind mit den gleichen Tricks Handlötbar, wie man sie auch für vielpinnige SMDs verwendet. Die auf den Modulen verbauten AVR32AP7000 CPUs sind aber sowohl für Linux ( Buildroot) als auch Nut/OS verwendbar. Ja, das kleinste ADB Modul ist schon sehr teuer im vergleich zu einem einfachen Controller, deshalb noch ein etwas erweiterter Kompromiss: Man kann einen AVR32UCxx auf das Mainboard setzen und die Sockel für das ADB1000 drum herum. Könnte passen und dann eine echte Bestückungsalternative werden. Entweder Chip oder Modul. Auf jeden Fall erschlägt diese Option beide Wünsche. Aber es geht noch weiter. Nut/OS setzt auf die std-libraries auf, kennt was von Posix und orientiert sich generell an Linux. Ein Treiber für das eine System kann auch in das andere portiert werden. Eigentlich kann auch das Nut/OS Radio alles, was das Linux Radio kann. Beide spielen alle gängigen Medien ab, außer Video, das bleibt nur denen vorbehalten, die entweder an einen Video-Drive heran kommen ( bei Interesse kann ich mal fragen, ob wir davon welche bekommen) oder Linux einsetzen. Ein weiterer Einwand der Linux-Gemeinde wird noch sein, dass Storage+WLAN darunter einfacher ist. Ja, aber ich möchte keinem Laien raten mit 100mW WLAN direkt unter dem Dashboard herum zu basteln. Natürlich muss im Auto alles gegen alles geschützt sein, aber auch die Hersteller müssen sparen. Also ist die Option das WLAN auf ein Modul hinter dem Himmel zu verbannen und die Dach-Antenne zu patchen besser. Damit ist der Vorteil dahin, dass man ein Atheros Modul in das Radio steckt, man macht TP und leitet das dahin, wo man einen WLAN-Client platzieren kann. Jep, ich weiß, dass es hier einige gibt, die das Modul doch ins Radio bauen können und damit dann auch noch eine Zulassung erhalten könnten, ich vielleicht auch, aber denkt bitte an die Nachbau-Sicherheit. Wenn man aber auf rein RJ45/TP geht, kann Nut/OS das auch. Bluetooth gibt es zum Glück als fertiges Modul inkl. Antenne und Zulassung. Das Teilchen kann direkt hinter der Frontblende sitzen und es ist gut. Das WLAN muss aber nach draußen funken. Ok, nun ist gut, Christian, Kai, Harry, lasst uns einen Deckel drauf machen. Vorschlag: AVR32UC3A1512 (100Pin TQFP) Nut/OS, Rest wie geplant. Wenn es der Platz erlaubt platzieren wir darüber das ICNova Modul AP7000OEM. Beide AVR32 werden mit I2S-In und I2S-Out an den Audio Router angeschlossen. Leider gibt es für meinen Favouriten, den SAA7706H keine Preise oder Lieferdaten. Dieser hätte aber alles, was wir brauchen. Alternative 1: Linuxer gucken in die Röhre, wir nehmen einen verbreiteten SAM7X oder einen SAM9XE, letzterer kann auch wieder Linux, aber nicht ohne externes RAM/FLASH für Nut/OS reichen die internen 128..512kB Alternative 2: AT91SAM9XE128 + externes Flash und Ram und es geht doch wieder alles. Allerdings halte ich die 9XEs nicht für so leistungsfähig in Bezug auf Audio/Video unter Linux, wie die extra dafür beworbenen AVR32. Trotzdem kann man Alternative 1 und 2 auch leicht als Bestückunsoption machen. Für alle genannten CPU stehen mit OpenOCD, gcc, libc, Nut/OS, gdb, buildroot... jeweils komplette CSPs zur Verfügung. Gruß, Ulrich
Benjamin Maresch schrieb: > Was haltet ihr von dem Chip? > > http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT2348_S.pdf > > oder auch dieser... > > http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT12311-s.pdf Hihihi... Hast Du Dir mal die Datenblätter angesehen? Also entweder hat mein Adobe einen an der Waffel oder ich habe es an den Augen, wenn Du mal auf Seite 3 des PT12311-s.pdf schaust.... Wenn der Chip so ist, wie seine Beschreibung... Ich bin ganz strickt gegen Chinakracher in der Kiste, sorry. Gruß, Ulrich
Die stellen die Pinbelegung doch tatsächlich von unten betrachtet dar ROFL.
Ulrich P. schrieb: > Hast Du Dir mal die Datenblätter angesehen? Also entweder hat mein Adobe > einen an der Waffel oder ich habe es an den Augen, wenn Du mal auf Seite > 3 des PT12311-s.pdf schaust.... zeigt mir der Foxit-Reader auch spiegelverkehrt an. gibt wohl auch ne andere richtige Version: http://www.alldatasheet.net/datasheet-pdf/pdf/311275/PTC/PT12311-S.html Nur ausführlich und mit Befehlsatz ist das auch nicht. Gruß Gerd
> Auweia! Kaum ein paar Tage nicht online und schon kommt man nicht mehr > mit. :( Ehrlich gesagt mir wird das hier auch langsam zu unuebersichtlich. Der Thread ist viel zu fett und eine Forumseite zu unleserlich wenn man mal 2-3Tage keine Zeit hatte. > Wir sind also vom SH7264 wieder weg und stehen wieder ganz am Anfang? Wieso? Der ist doch perfekt? Was soll es denn besseres geben? Ich hab uebrigens mal einen an Kai gegeben damit er sich den mal anschauen kann. Olaf
Also die CPU Frage wird sich in den nächsten Tagen klären, eventuell mit einer Überraschung für alle beiden Fronten, die Spartaner und die Linuxer. Aktuell ist eher das Problem, dass es kaum noch analoge Audio-Controller oder Multiplexer gibt. Es gibt sie sicherlich, aber man kommt kaum an die vollständigen Datenblätter und erst recht nicht an die Chips. Auch da gibt es fast nichts rein analoges mehr, sondern die Großen wechseln alle zu integrierten DSPs und das gleich mit voller Kraft. Da ist also noch Arbeit zu leisten. Außerdem wollen wir ja ein paar Class-D Endstufen verbauen. So 4..6 Stück sollten es schon sein. Hier ist TI recht fleißig: http://focus.ti.com/apps/docs/viewdevices.tsp?blockdiagramId=6175&blockId=8151&designOptionId=8793&appId=472 Schön, dass es einige interessante Chips mit gleich vier Class-D AMPs gibt und die Dinger ziemlich ausgefuchst sind was die interne Überwachung angeht. Das steigert die Nachbau- und Experimentier-Sicherheit. Gruß, Ulrich
Oh, noch was gefunden, hat sehr viele analoge Inputs und bereits PWM Outputs. http://focus.tij.co.jp/jp/lit/ds/symlink/tas3308.pdf Naja, suchen wir mal weiter nach einem Audio-Controller.
Ulrich P. schrieb: > Oh, noch was gefunden, hat sehr viele analoge Inputs und bereits PWM > Outputs. > http://focus.tij.co.jp/jp/lit/ds/symlink/tas3308.pdf > Naja, suchen wir mal weiter nach einem Audio-Controller. tda7418 macht genau was wir suchen: http://www.st.com/stonline/books/pdf/docs/13246.pdf Bezugsquelle: ?!? Auf die schnelle nicht gefunden. Wobei bestimmt Blitze überspringen wenn den ST-IC an einen NXP-IC koppelt :-)
> Auch da gibt es fast nichts rein analoges mehr, sondern die Großen > wechseln alle zu integrierten DSPs und das gleich mit voller Kraft. Ist doch kein Problem, koennen wir kleinen doch auch. :) Olaf
Kai G. schrieb: > tda7418 macht genau was wir suchen: > http://www.st.com/stonline/books/pdf/docs/13246.pdf > endlich mal ein sinnvoller Vorschlag! > Bezugsquelle: ?!? Auf die schnelle nicht gefunden. > Nicht nur das!...ich hab auch kein .pdf gefunden, was den Prozessor und die Peripherie beschreibt... > Wobei bestimmt Blitze überspringen wenn den ST-IC an einen NXP-IC > koppelt :-) dann kommt der Blitzableiter auf die Feature-List :-D Harry
Jaja, ich hatte da aber schon was weiter gedacht :) Der TI chip hat neben einigen analogen Eingängen auch 3 digitale und ebenso entsprechende Ausgänge. Der DSP-Core kann die Signale beliebig hin und her routen. So könnte man die beiden Tuner analog einspeisen, der TI digitalisiert sie, sschickt sie an den uC für die Diversity und nimmt sie auf einem I2S wieder entgegen um sie ggf. noch passend zu machen ( Höhen, Bässe...) und dann auf entweder einem PWM oder einen analogen Ausgang zu geben. Der DSP ist mit einer grafischen Suite zu programmieren, die TI kostenfrei zur Verfügung stellt. Man schiebt sich einfach die nötigen DSP Module zwischen die Signale und fertig. Da man auch eigene DSP Module schreiben kann ( groß ist er aber nicht) könnte man auch die Diversity später vielleicht in den DSP verschieben? Damit wären noch 2 I2S Eingänge frei, also für den VLSI perfekt, und dann ist noch einer für einen SPDIF Eingang, oder in meinem Fall ein I2S für das DVD Drive übrig. Ist nur ein Vorschlag und erspart einige externe ADCs/DACs, wäre also auch ein Vorteil für Fläche und Bauteilzahl.
Harald L. schrieb: > Nicht nur das!...ich hab auch kein .pdf gefunden, was den Prozessor und > die Peripherie beschreibt... Das ist das Problem bei ST und NXP, sie machen Werbung für die Systeme wir bekloppt, aber Datenblätter gibt es nur spärlich und Chips keine, jedenfalls nicht an privat mal eben so. Bei TI kenne ich das so nicht, habe aber auch noch keine Samples aus diesem Bereich geordert. Alles andere von TI ist i.d.R. innerhalb von einem Tag da. Der Rekord war eine Sample-Order um 17:35 und der Eingang des Päckchens (Absender Atlanta/USA) um 10:30, dabei kann man getrost noch fast ne Stunde Hauspost abziehen :)
Was auch immer süß ist, ist so eine TI C54/c55xx DSP. http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dsp§ionId=2&tabId=50&familyId=114
Wenn ich das richtig verstanden hab, ist das Ziel doch, ein wirklich gutes Radio zu bauen, und nicht ein DSP-Experimentierboard, das keiner der beteiligten wirklich beherrscht. Ein Audio-DSP ist sicherlich eine tolle Sache, aber kann dann ggf. auch auf dem (optionalen) Multimediamodul sitzen. Wenn wir eine (völlig neue) Baustelle nach der anderen aufmachen, wird das nie was! Was wir brauchen sind Komponenten, die für jeden beteiligten beherrschbar, beschaffbar und lötbar sind! Dazu eine ausreichende, aber nicht völlig überdimensionierte CPU. Klar sind ein paar Reserven wünschenswert, aber mir konnte bisher noch niemand hier erklären, warum ich für die gestellten Anforderungen eine SH-Irgendwas-CPU und wohl möglich noch einen DSP brauch... Klar ist sowas ein "nice-to-have".....aber Leute!....das soll ein Radio werden, kein Experimentier-Brett. Ich bin nach wie vor für ARM7!(bekannt, beherrschbar, beschaffbar, weit verbreite, billig und völlig ausreichend) Macht euch lieber mal ein paar Gedanken über das Gehäuse! Bevor das nicht geklärt ist, braucht man mit einer Platine gar nicht erst anfangen. ...just my 2 cent Harry
Ok warum immer so herum reden ? Wir haben 2 Vorteile Gegenüber Kommerziel: 1. Keine Personalkosten 2. Keinen Zeitdruck Also man kann einen einfachen Tuner mit µC aufbauen und eine Schnittstelle festlegen. Ich will damit sagen ob ein Monat mehr oder weniger is ja wurscht ob die Module einzeln entwickelt werden oder zusammengefasst is ja egal. Warum nicht erst ein Tunermodul und ein anderes Team arbeitet an einem oder mehreren "Mainboards". Man kann ja noch immer sagen ok wir nehmen einen einfachen ARM oder eine DSP + ARM wenn man mal beide Lösung hat. Also mal anfangen statt herumreden !
Seennoob schrieb: > > Also mal anfangen statt herumreden ! die Vorstellung solltest du bei einem Projekt dieser Größe begraben! Exakte Planung ist alles!!! Harry
Harald das ist ned Planung was jetzt gemacht wird sondern mit Verlaub eher eine Sammlung von Gehirn Abfall. Normalerweise fängt mit einem Lastenheft an, darauf erstellt man ein Pflichtenheft. Also auf Deutsch es gehört mal fixiert was rein muss und wie es gemacht werden soll. Also Schreibt mal wer ein Lastenheft (Anforderungen + Randbedingungen) und dies muss ins Wiki. Dann neuen Thread auf wo es ums Pflichtenheft geht. Als externer Vorschlag gg
Seennoob schrieb: > oder mehreren "Mainboards". Man kann ja noch immer sagen ok wir nehmen > einen einfachen ARM oder eine DSP + ARM wenn man mal beide Lösung hat. > Wie stellst du dir das vor? Das Gehäuse gibt die Abmessungen, Lage der der Anschlüsse, Befestigungsmöglichkeiten, Kühlmöglichkeiten etc vor. Bevor das Gehäuse nicht steht, kannst du die Konstruktion des Mainboard komplett vergessen. Allein die Lage der zu kühlenden Bauteile wird mass geblich durch das Gehäuse bestimmt. Das selbe gilt für die Verbindungen zur Aussenwelt. Ich denke, daß wir die Rahmenbedingungen jetzt weitgehend fixiert haben. Jetzt sollte sich mal jemand mit Erfahrungen in Mechanik-Desig ein paar Gedanken zum Gehäuse machen. Ich hab das letztens mit Kai diskutiert, und wir sind bei 5mm dicken Alu-Profilen gelandet. Bei der Stärke kann man auch in die Stirnseite ein Sackloch (M3) bohren. Diese Profile müssen natürlich gefräste Schlitze für Leiterplatten und Deckel und entsprechende Durchbrüche für Anschlüsse enthalten. So, wie wir die brauchen werden, wird es die vermutlich nicht als Meter-Ware geben. D.h.: wir müssten einen Betrieb finden, der bereit ist, uns sowas in Kleinserie bezahlbar zu fertigen. ...aber vielleicht hat ja jemand eine bessere Idee. Ohne das Gehäuse ist das ein Experimentier- aber kein Auto-Radio, daher sollten/müssen wir dieses Problem als eines der Ersten lösen. Harry
Nana, Abfall ist das sicherlich nicht, es sind immerhin mind. zwei Leute aus der Branche dabei, die Tuner, Mixer, Audio/Video DSPs und auch die gerade genannten TiDSP C55xx sehr gut kennen. Der Abfall ist lediglich dadurch hervorgerufen, dass die Hersteller von Chips alles einfach so übers Internet oder Distis verkloppen was sie haben, aber genau diese Chips, die wir brauchen eben nicht. Bei Ti ist das vielleicht noch einfach via eMail zu klären, bei ST und NXP eben nicht, weil die mal eben ganze Abteilungen an einander verkaufen und dann wiederum mit anderen zusammen fassen und wieder verkaufen. Selbst wenn Du von einem ehemaligen Kollegen noch eine VCard hast, kann es sein, dass der schon längst wieder woanders ist oder was anderes macht. Kai's ursprüngliche Anforderung war ein gutes Radio, und dabei ging es nicht darum alles ein zu bauen, was eben noch passt, sondern eben, weil es sein Steckenpferd ist, guten Klang aus der Antenne auf die Boxen zu zaubern. Dadurch, dass nun vielleicht zwei Chips hinzu kommen und beim Prozessor eben nicht der Minimalistischste verwendet wird, gibt es einige, heute übliche, Features 'geschenkt', bzw. es sind für den geneigten Nachbauer noch ein paar Verbindungen, RAM und FLASH übrig um eigene Optionen zu ermöglichen. ARM7 oder ARM9 macht keinen Unterschied, wenn der ARM9 über genug eigenes FLASH verfügt um eine minimalistische Applikation zu bauen. Ich prüfe aber gerade eine Huckepack-Lösung um alternativ einen Controller mit eigenem Flash aufs Mainboard zu packen, alternativ kann man diesen Weg lassen und ein kleines Linux taugliches Board darüber stecken.
Harald L. schrieb: > Bevor das Gehäuse nicht steht, kannst du die Konstruktion des Mainboard > komplett vergessen. Allein die Lage der zu kühlenden Bauteile wird mass > geblich durch das Gehäuse bestimmt. Das selbe gilt für die Verbindungen > zur Aussenwelt. Da kommt noch hinzu, dass nicht jeder bereit ist, den Kabelstrang in seinem Dashboard zu zerrupfen. Also sollten die ISO-Anschlüsse auch da liegen, wo sie hin gehören. ISO Links, Antenne Rechts. Außerdem kommen noch die Befestigungskrallen hinzu, die seitlich vorne liegen sollten. Wird noch ne nette Aufgabe :)
Seennoob schrieb: > Was auch immer süß ist, ist so eine TI C54/c55xx DSP. > http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dsp§ionId=2&tabId=50&familyId=114 Wenn die Preise sich seid etwa 2 Jahren nicht deutlich geändert haben, willst Du die nötige Toolchain (Compiler, IDE und JTAG Adapter) für diese Dinger nicht bezahlen müssen. Da sind schnell 2k€ weg.
schlimmstenfals muss man mit Kabelpeitsche arbeiten, und Adapterkabel aus dem Zubehörhandel anflanschen. Ein Spaß wird das aber auch nicht, bei Strömen im 2stelligen A-Bereich. Passende DIN-Einbaustecker dürften nicht leicht zu finden sein; wer braucht sowas außer die Autoradio-Hersteller? Und da hat auch jeder was eigenes. Vielleicht gibt es ja sowas im Car-PC-Bereich zu kaufen...da hab ich noch nicht geschaut. Harry
Ulrich ich werd ab August beruflich auch Richtung TI DSP gehen die sind da sehr "Günstig" mit der Entwicklungsumgebung im Vergleich zu anderen Herstellern noch eher günstig mit 1600€. Vielleicht kann man da auch noch etwas unterstützung von TI bekommen wegen der Entwicklungsumgebung. Mfg
Ja, 1600€ kommen hin, für eine Einzelplatzlizenz mit JTAG Adapter. Hoffentlich haben die an der IDE fleißig weiter entwickelt. Die CCS war nämlich damals grotten schlecht. Die stürzte ja noch öfter ab als Windows ohnehin schon. Hat aber auch gerne mal das ganze Windows mit sich gerissen. Aber 2 Jahre sind eine lange Zeit und die CCS2 war schon deutlich besser. Ich mach aber jetzt mal Haia! Gn8!
> Ich bin nach wie vor für ARM7!(bekannt, beherrschbar, beschaffbar, weit > verbreite, billig und völlig ausreichend) Also ich kenne keinen ARM7! Ist mir total unbekannt. Da kenne ich meinen SuperH besser, von dem habe ich naemlich schonmal ein Datenblatt gelesen. .-) Und billig, beschaffbar und beherschbar ist er auch. > Normalerweise fängt mit einem Lastenheft an, darauf erstellt man ein > Pflichtenheft. Das ist absolut richtig. Ich glaub ehrlich gesagt mittlerweile nicht mehr das die Sache noch was wird. Das Problem ist das es keine Boss gibt der sagen kann es so gemacht wird oder man soll sich einen anderen Job suchen. Es gibt zu viele unterschiedliche Moeglichkeiten die gleichwertig sind. Und unter Druck setzen kann man ja auch keinen. Ich bin jetzt von dem SuperH so begeistert das ich auf jedenfall etwas damit machen werde. Ob ein Autoradio oder was anderes ist mir relativ egal und davon werde ich mich auch nicht abbringen lassen. Olaf
Ich persönlich bin nach dem ich die Datenblätter gelesen habe, vom Super-H voll begeistert. ABER es gibt leider ein paar mächtige Hacken. - Beschaffung sieht nicht so einfach aus (muss vom anderen Ende der Welt importiertwerden) - IDE scheint nicht frei zu sein sondern nur TRIAL (verstößt gegen die Open-Scource-Regeln) - Am µ-Controller selbst gibt es einige Sachen die unter NDA fallen (verstößt gegen die Open-Scource-Regeln) Daher fällt, meiner Ansicht nach, der Super-H aus dem Rennen. :-( Die Alternative mit dem ARM ist da eher was für uns. > Passende DIN-Einbaustecker dürften nicht leicht zu finden sein; wer > braucht sowas außer die Autoradio-Hersteller? Und da hat auch jeder was > eigenes. Ich denke die Stecker und Buchsen sollten schon zum Auftreiben sein. Wenn es wirklich nicht klappen sollte dann steigen wir einfach auf 16-polige Modul Kupplungen um. Die bekommt man einfach und im Zubehör gibt es für kleines Geld den passenden Adapter. Stecker sind wohl unser gerinstes Problem ;-) > Harald das ist ned Planung was jetzt gemacht wird sondern mit Verlaub > eher eine Sammlung von Gehirn Abfall. Das nennt man Brainstorming und das ist innerhalb von so kurzer Zeit noch ein normales Stadium. ;-) Lg Pezi
> - Beschaffung sieht nicht so einfach aus (muss vom anderen Ende > der Welt importiertwerden) Nein, den kannst du bei Glyn kaufen. Auch in Kleinstueckzahlen von 10-20 Stueck. Ich hab da angerufen! > - IDE scheint nicht frei zu sein sondern nur TRIAL (verstößt gegen die > Open-Scource-Regeln) Die Programmierumgebung ist frei solange du nicht mehr als 256k Code erzeugst. Es gibt aber auch einen gcc und du kannst auch alles mit einem Makefile machen und dann bist ganz frei. Und im Gegensatz zu allen anderen Prozessoren bist du sogar richtig vogelfrei weil der Prozessor sein Programm aus einem externem SPI-Flash zieht das du einfach so programmieren kannst. Du brauchst also noch nichtmal irgendein spezielles Programmiergedoens. > - Am µ-Controller selbst gibt es einige Sachen die unter NDA fallen > (verstößt gegen die Open-Scource-Regeln) Es gibt genau eine Sache die darunter faellt. Das ist das SD-Karteninterface fuer die Anbindung der Karten im 4Bit-Modus. Aber absolut niemand hindert dich daran die Karte einfach an einem 1-Bit SPI-Interface zu haengen wie ihr das vermutlich an jedem anderen Controller auch machen wuerdet. BTW: Koennen eigentlich ARMs ueberhaubt eine Speicherkarte im 4Bit-Modus ansprechen? Und das ist da ohne NDA? > Daher fällt, meiner Ansicht nach, der Super-H aus dem Rennen. :-( Bis jetzt waren das IMHO nur vorgeschobene Argumente ohne Inhalt und Substanz. > Die Alternative mit dem ARM ist da eher was für uns. Ich glaub eher hier wird nach der Methode "Wat de Buer ni kennt dat freet he nie!" verfahren. Bloss mal nicht den eingefahren Weg verlassen.... > Ich denke die Stecker und Buchsen sollten schon zum Auftreiben sein. Nein, ich denke auch das dies ein Problem wird. Natuerlich ist es kein Problem irgendeinen Stecker aufzutreiben, aber es waere schoen wenn man diese genormten Stecker haetten wie sie seit kurzem bei allen Hersteller verwendet werden. Aber ausser durch ausschlachten eines alten Radios wird man da kaum dran kommen. Es waere vielleicht interessant solche Sachen wirklich auszuschlachten. Aus irgendeiner Witzkiste wie sie die Hersteller als Alibiradio in Neuwagen bei VW oder Opel eingebaut haben und die man vermutlich nachgeworfen bekommt. Und dann koennte man von da auch gleich das Blechgehaeuse verwenden. Es sollte halt nur ein gaengiges Modell sein das sich jeder besorgen kann. Olaf
Olaf schrieb: > BTW: Koennen eigentlich ARMs ueberhaubt eine Speicherkarte im 4Bit-Modus > ansprechen? Und das ist da ohne NDA? Ja, alle LPCs mit SD card interface. Ohne NDA. Evtl. setzt der SH da einfach auf einem niedrigeren Level an und man braucht deshalb die NDA. Oder Renesas ist einfach sehr vorsichtig. > Es waere vielleicht interessant solche Sachen wirklich auszuschlachten. > Aus irgendeiner Witzkiste wie sie die Hersteller als Alibiradio in > Neuwagen bei VW oder Opel eingebaut haben und die man vermutlich > nachgeworfen bekommt. Und dann koennte man von da auch gleich das > Blechgehaeuse verwenden. Es sollte halt nur ein gaengiges Modell sein > das sich jeder besorgen kann. Also die VW Dinger (Alpha/Beta/Gamma) sind selbst gebraucht noch relativ teuer, weiss nicht ob es da noch was anderes gibt. Aber da wir eh eine andere Front haben wollen bringt es doch wahrscheinlich eh nicht so viel wie man sich erwünscht. Eine Bezugsquelle für die Radioseitigen stecker für print-montage hab ich leider noch nicht gefunden, aber auch noch nicht besonders intensiv gesucht.
Angehängte Dateien:
-
BlockdiagramV2.png
84 KB
Was die CPU betrifft: Ich finde den SH gut, um nicht zu sagen sehr gut und es würd mich reizen mal eine neue CPU-Architektur zu programmieren (den SH werd ich also so oder so irgendwann mal mit eigener Software füllen)... ...aber aus einem Grund würde ich gerne den ARM7 bevorzugen und das ist einfach das mehr Leute das Ding kennen und für die meisten der Einstieg einfacher ist. Ich glaube auch das die meisten hier eher ARM programmieren. Ich habe mal an dem Blockdiagram weitergearbeitet und upgedated (werde es nachher noch ins WIKI packen). Dort ist ein möglicher ARM7 gelistet. Also, dann "erschiesst" mich mal... Ansonsten was mir noch an offene Punkte auffällt: - Was für ein Frontpanel-Display (Um ein passendes Interface auszuwählen, z.b. SPI oder parallel) - Mechanisches Design, z.B. aluprofile für den Einschub - Bezugsquelle: vom MUX/sound controller. Oder Auswahl eines alternativen. Digikey und co haben den nicht lagernd. ein reiner sound controller würde reichen, den MUX kriegen wir einfach diskret aufgebaut. - Auswahl eines geeigneten I2S ADC/DAC oder CODEC - Auswahl eines Verstärkers. Ulrich hat da z.B. ein paar posts zurück einen geeigneten und beschaffbaren (Farnell) genannt. - Stromversorgung: Abschätzung der Leistungen für die einzelnen Spannungen und Design. Ich könnte mir ein gemischtes Buck converter/LDO Konzept vorstellen (z.B. die 3.3V aus den 5V, die 5V aus einem Schaltwandler, ...). - Bezugsquelle für Print "DIN Radio"-buchsen
> Ich glaub eher hier wird nach der Methode "Wat de Buer ni kennt dat > freet he nie!" verfahren. Bloss mal nicht den eingefahren Weg > verlassen.... Jij bedoeld zeker: "Wat de boer niet kent, dat eet hij niet". Is echt mal wieder faszinierend wie nah Platt an Niederländisch ist ;-)
> Also die VW Dinger (Alpha/Beta/Gamma) sind selbst gebraucht > noch relativ teuer, weiss nicht ob es da noch was anderes > gibt. Hm..haette ich jetzt nicht gedacht. > Aber da wir eh eine andere Front haben wollen bringt es doch > wahrscheinlich eh nicht so viel > wie man sich erwünscht. So eine Vorgehensweise haette den Vorteil das man wirklich die ganzen Blechteile, Seitenteile, Deckel, Klemmen usw verwenden koennte. Klar, niemand will etwas das wie ein VW Alpha aussieht. :-) Da muesste man dann halt das Blech begradigen und dort eine Halterung fuer die eigene Front schaffen. Mir gefaellt die Vorstellung soetwas zu machen auch nicht so ganz wenn man bedenkt das dies ja meherere Leute fuer einige Radios machen sollen/muessen. Aber wenn man so ein Radio fuern fuffi bekommt dann klingt das zwar erstmal nach viel Geld fuer so eine Witzkiste, aber das koennte trotzdem noch billiger sein als Blechteile zusammenzuschrauben und was eigenes zu machen. Noch besser waere es vielleicht soetwas auszuschlachten: http://www.amazon.de/dp/B002MPSTNG?m=A3JWKAKR8XB7XF&tag=idealocom Problem dabei ist natuerlich das man das in einem Jahr kaum noch nachkaufen kann wenn einer spaeter einsteigt. Hm...koennte sogar fast die Frage aufwerfen ob man nicht auch die Front verwenden kann und nur das Gehirn auswechselt. Modell Blaupunkt Frankenstein. :-D > - Auswahl eines geeigneten I2S ADC/DAC oder CODEC Das ist das naechste was ich brauche wenn ich mit der I2C-Programmierung fertig bin. Son mist, ich hab Codecs bis zum abwinken rumliegen, aber alles nur 8Bit. Seufz. Olaf
Olaf schrieb: > Nein, den kannst du bei Glyn kaufen. Auch in Kleinstueckzahlen von 10-20 > > Stueck. Ich hab da angerufen! Ok! Das ist natürlich was anderes. Ich hab halt nix gefunden. > Die Programmierumgebung ist frei solange du nicht mehr als 256k Code > > erzeugst. > > Es gibt aber auch einen gcc und du kannst auch alles mit einem Makefile > > machen und dann bist ganz frei. Und im Gegensatz zu allen anderen > > Prozessoren bist du sogar richtig vogelfrei weil der Prozessor sein > > Programm aus einem externem SPI-Flash zieht das du einfach so > > programmieren kannst. Du brauchst also noch nichtmal irgendein > > spezielles Programmiergedoens. > Es gibt genau eine Sache die darunter faellt. Das ist das > > SD-Karteninterface fuer die Anbindung der Karten im 4Bit-Modus. Aber > > absolut niemand hindert dich daran die Karte einfach an einem 1-Bit > > SPI-Interface zu haengen wie ihr das vermutlich an jedem anderen > > Controller auch machen wuerdet. > > BTW: Koennen eigentlich ARMs ueberhaubt eine Speicherkarte im 4Bit-Modus > > ansprechen? Und das ist da ohne NDA? Aber genau diese Sachen widersprechen den OpenScource-Gedanken. >> Daher fällt, meiner Ansicht nach, der Super-H aus dem Rennen. :-( > > Bis jetzt waren das IMHO nur vorgeschobene Argumente ohne Inhalt und > > Substanz. Ist halt meine Meinung. ;-) > Ich glaub eher hier wird nach der Methode "Wat de Buer ni kennt dat > > freet he nie!" verfahren. Bloss mal nicht den eingefahren Weg > > verlassen.... Wenn man was nicht kennt läuft man schnell in die Gefahr das etwas schief geht. > Es waere vielleicht interessant solche Sachen wirklich auszuschlachten. > > Aus irgendeiner Witzkiste wie sie die Hersteller als Alibiradio in > > Neuwagen bei VW oder Opel eingebaut haben und die man vermutlich > > nachgeworfen bekommt. Und dann koennte man von da auch gleich das > > Blechgehaeuse verwenden. Es sollte halt nur ein gaengiges Modell sein > > das sich jeder besorgen kann. ACK!
Also ich habe schon einige Radios gesehen und muss feststellen, dass die Leiterplatten von den Formaten her sehr dicht bei einander liegen. Das kann man also im Design berücksichtigen und an der Außenkante ein paaar mm Luft lassen. Dann kann man die nötigen Ecken noch rein feilen, bzw. die nötigen Bohrungen anbringen. Zum Thema CPU/TUNER/MIXER: Es ist villeicht möglich, dass man einen Hersteller überredet bekommt auch die guten Bauteile raus zu rücken, wenn man alle Chips aus seinem Haus nutzt, also quasi ein Referenz-Design entwickelt. Es wäre schließlich eine Art Werbung für ihn. Eventuell legt er ja auch etwas Support oder Code-Schnipsel oben drauf. Das ganze wird aber nur dann funktionieren, wenn man es unter BSD, nicht aber unter GPL macht. Sonst hat der Hersteller ja nix davon. Frontpanel Anschluss: 3.3V für Logic 5V od. 8V für LED/OLED/LCD Driver SPI für grafische Displays I2C für Tasten, LED control 2xPWM für Backlight, Contrast GND macht 12 Pinne bei GND auf zwei Pinne Man kann auf die PWM verzichten, wenn man einen I2C Controller oder ein 'intelligentes' Display einsetzt, wo man diese Parameter konfigurieren kann. Mainboard CPU: Wie sieht es mit einem 'Betriebssystem' für die verschiedenen CPUs aus? Wollen wir alles von Hand machen oder lieber auf einen schon mal passenden Rahmen aufsetzen, so dass einige nach unten hin die Treiber programmieren und andere ncoh oben hin die Applikation? Da es zwischen diesen beiden Welten eine recht klar definierte und durch das System vorgegebene Schnittstelle gibt, werden die beiden Welten vermutlich besser zusammen arbeiten. Mein Vorschlage war ja Nut/OS, aber es ist noch nicht auf LPC2xxx portiert, auch wenn etwas passendes bereits seid ein paar Wochen bei mir herum liegt. Was geht ist SAM7-Serie, SAM9-Serie und AVR32-Serie. Was kommen wird ist STM32-Serie und LPC-Serie, ersteres muss ich machen (Brötchen), letzteres möchte ich machen (Spaß). IDE oder nicht IDE, Frei oder Beschränkt. Ich persönlich lege bei dem verwendeten Chip mehr Wert auf gcc, gdb und openocd, als auf eine schöne fette IDE. Ich programmiere ausschließlich mit SourceInsight als Editor, auch mittels Wine unter Linux. Mit einer limitierten IDE kann man in dem Moment schnell nix mehr anfangen, wenn der Code für andere Chips Blobs (Code, der in einen anderen Chip transferiert wird) enthält und damit schnell mal über 256kB anwächst. Dito gilt für Grafiken für das Frontpanel oder Tabellen für Software-Decoder, -Filter. Ja, man kann vermutlich die IDE-Internen Makefiles so drehen, dass die Tabellen und Blobs nachträglich gelinkt werden oder man baut ein Script, dass die HEX files zusammen pfercht. Sicher, aber wer versteht das nach einem Jahr dann noch alles. Gruß, Ulrich
> Aber genau diese Sachen widersprechen den OpenScource-Gedanken. Darf ich daraus schliessen das generell kein Microsoftbetriebsystem fuer die Entwicklung verwendet werden darf weil das nicht Opensource ist? Fuer mich besteht open source darin das du dir spaeter die Sourcefiles downloaden kannst. Und du kannst dir dann sogar aussuchen womit du sie uebersetzt. Und wenn den Leuten hier andauernd einer abgeht vor Angst, warum installieren sie sich dann nicht den gcc? Es gibt ihn ja. Und der laesst sich bestimmt auch mit make benutzen. > Wie sieht es mit einem 'Betriebssystem' für die verschiedenen CPUs aus? Ich hatte mich mit Kai schonmal darueber unterhalten. Ergebnis war wohl in etwa, wir sind uns nicht ganz schluessig. :-) Ich bin auf der einen Seite sehr stark gegen ein Betriebsystem. Es kostet nur unnoetig Resourcen, macht einem Probleme beim Timing und bringt keine Vorteile weil man die Aufgaben die ein Betriebsystem normalerweise erledigt in einer Ein-Programm-Hardware nicht benoetigt. Andererseits leuchten auch mir ein paar kleinere Vorteile, besonders bei der Arbeitsteilung ein. Ich programmiere auf meinem SuperH gerade I2C, und habe bereits RS232 programmiert. Dabei achte ich darauf das die Funktionalitaet versteckt wird und ueber Buffer im Hintergrund in Interrupts laeuft. So sollten beliebige Funktionen ohne Ruecksicht solche Basisfunktionen nutzen koennen. Ich bin mir noch nicht ganz klar ob das klappt, aber so moechte ich vermeiden das man ein Betriebssystem braucht. Die wirklich wichtigen Sachen wie das verschieben der Audiodaten werden ja wohl sowieso von einer DMA Hintergrund gemacht. > Mit einer limitierten IDE kann man in dem Moment schnell nix mehr > anfangen, wenn der Code für andere Chips Blobs (Code, der in einen > anderen Chip transferiert wird) enthält und damit schnell mal über 256kB > anwächst. Nicht das ich es fuer notwendig halte, aber dir ist schon klar das man bei einem Konzept wie dem des SH7262 mit externem SD-Flash und externer SD-Karte und Bootloader im Source, beliebige Anwendungen und Teile jederzeit nachladen kann? Insbesonders das laden von der SD-Karte wuerde mit zu den ersten Sachen gehoeren die ich machen wuerde weil ich nicht immer meinen Laptop ins Auto schleppen moechte. Da waere es doch viel besser wenn ein Fenster aufgeht und man gefragt wird welche der fuenf Firmwareversionen auf der SD-Karte man heute probieren moechte. > Sicher, aber wer versteht das nach einem Jahr dann noch alles. Hm..die Idee von Projecten unter HEW ist es gerade sich solche Sachen zu merken. Und wenn man ueber Makefiles eins sagen kann, dann doch wohl das sie in der automatisierung von Prozessen noch leistungsfaehiger sind. Aber 256kb Code in einem Autoradio? Das bekommt man niemals voll. Jedenfalls nicht bei der Art Radio wie ich es mir vorstelle... Olaf
Für die Arme gibts ne Toolchain komplett kostenlos. Das einzige, was man dann noch kaufen muss ist nen popeliger JTAG Adapter für 25€...
Sven H. schrieb: > Für die Arme gibts ne Toolchain komplett kostenlos. Das einzige, was man > dann noch kaufen muss ist nen popeliger JTAG Adapter für 25€... Auf was beziehst du dich jetzt ?
Olaf schrieb: >> Aber genau diese Sachen widersprechen den OpenScource-Gedanken. > > Darf ich daraus schliessen das generell kein Microsoftbetriebsystem fuer > die Entwicklung verwendet werden darf weil das nicht Opensource ist? > Quatsch! - es geht um die Entwicklungsumgebung/Toolchain. Ob du die unter Linux, Windoof oder Commodore-Basic verwendest spielt keine Rolle > Fuer mich besteht open source darin das du dir spaeter die Sourcefiles > downloaden kannst. Und du kannst dir dann sogar aussuchen womit du sie > uebersetzt. Und wenn den Leuten hier andauernd einer abgeht vor Angst, > warum installieren sie sich dann nicht den gcc? Es gibt ihn ja. Und der > laesst sich bestimmt auch mit make benutzen. > und was ist mit debugging? Ist ja toll, wenn dir Renases einen 1k€ treuren Debugger schenkt – nur wir Anderen haben da leider gar nicht von... > Ich bin auf der einen Seite sehr stark gegen ein Betriebsystem. Es > kostet nur unnoetig Resourcen, macht einem Probleme beim Timing und > bringt keine Vorteile weil man die Aufgaben die ein Betriebsystem > normalerweise erledigt in einer Ein-Programm-Hardware nicht benoetigt. > ...jaja...was der Bauer nicht kennt.... > Andererseits leuchten auch mir ein paar kleinere Vorteile, besonders bei > der Arbeitsteilung ein. > > Ich programmiere auf meinem SuperH gerade I2C, und habe bereits RS232 > programmiert. Dabei achte ich darauf das die Funktionalitaet versteckt > wird und ueber Buffer im Hintergrund in Interrupts laeuft. So sollten > beliebige Funktionen ohne Ruecksicht solche Basisfunktionen nutzen > koennen. Ich bin mir noch nicht ganz klar ob das klappt, aber so moechte > ich vermeiden das man ein Betriebssystem braucht. > Die wirklich wichtigen Sachen wie das verschieben der Audiodaten werden > ja wohl sowieso von einer DMA Hintergrund gemacht. > Und wo ist der Unterschied zu einem Minimal-OS, wenn du ohnehin eine oder mehrere Abstraktionsebenen definierst? Kennst du überhaupt andere Betriebssysteme ausser Windows? Solche "Frameworks" zu benutzen ist "Stand der Technik". Das sollte auch dir klar sein! Ausserdem kann man bei einem solchen Projekt sehr wohl von Dingen wie Task-Scheduler etc profitieren. >> Mit einer limitierten IDE kann man in dem Moment schnell nix mehr >> anfangen, wenn der Code für andere Chips Blobs (Code, der in einen >> anderen Chip transferiert wird) enthält und damit schnell mal über 256kB >> anwächst. > > Nicht das ich es fuer notwendig halte, aber dir ist schon klar das man > bei einem Konzept wie dem des SH7262 mit externem SD-Flash und externer > SD-Karte und Bootloader im Source, beliebige Anwendungen und Teile > jederzeit nachladen kann? s.o.: was ist mit debuggen? > Aber 256kb Code in einem Autoradio? Das bekommt man niemals voll. > Jedenfalls nicht bei der Art Radio wie ich es mir vorstelle... > und wozu dann so eine fette CPU auf dem Mainboard??? Harry
seennoob schrieb: > Sven H. schrieb: >> Für die Arme gibts ne Toolchain komplett kostenlos. Das einzige, was man >> dann noch kaufen muss ist nen popeliger JTAG Adapter für 25€... > > Auf was beziehst du dich jetzt ? Ich hab beim durchlesen des kompletten Threads das ein oder andere Mal Bedenken zu Kosten für die Entwicklungsumgebung gesehen und da dachte ich, wäre es erwähnenswert...
Sven H. schrieb: > seennoob schrieb: >> Sven H. schrieb: >>> Für die Arme gibts ne Toolchain komplett kostenlos. Das einzige, was man >>> dann noch kaufen muss ist nen popeliger JTAG Adapter für 25€... >> >> Auf was beziehst du dich jetzt ? > > Ich hab beim durchlesen des kompletten Threads das ein oder andere Mal > Bedenken zu Kosten für die Entwicklungsumgebung gesehen und da dachte > ich, wäre es erwähnenswert... Billig oder teuer kann man das heut noch so leicht sagen ? Für einen ist eine IDE für 500€ noch billig und ein anderer will alles opensource haben das er ja nix zahlen muss. Wenn man mit neuer HW arbeiten will ist es oft nix mit gcc usw.
seennoob schrieb: > Für einen ist eine IDE für 500€ noch billig und ein anderer will alles > opensource haben das er ja nix zahlen muss. > > Wenn man mit neuer HW arbeiten will ist es oft nix mit gcc usw. Eben!....und dann wäre es kein "OpenSource-Projekt" mehr.... http://de.wikipedia.org/wiki/Open_source Harry
> Quatsch! - es geht um die Entwicklungsumgebung/Toolchain. Ob du die > unter Linux, Windoof oder Commodore-Basic verwendest spielt keine Rolle Aber das Betriebsystem ist doch Teil der Entwicklungsumgebung. Wie kannst du dich daran stoeren das der Compiler von einer kommerziellen Firma ist, aber das Filesystem und die Grafikoberflaeche ist dann auch nicht frei? > s.o.: was ist mit debuggen? Du kannst dir kein USB-KAbel leisten? Mehr brauchst du nicht. Oder bist du lernresistent weil ich das bereits mindestens zweimal in epischer Breite erklaert habe? Olaf
Olaf schrieb: >> Quatsch! - es geht um die Entwicklungsumgebung/Toolchain. Ob du die >> unter Linux, Windoof oder Commodore-Basic verwendest spielt keine Rolle > > Aber das Betriebsystem ist doch Teil der Entwicklungsumgebung. Wie > kannst du dich daran stoeren das der Compiler von einer kommerziellen > Firma ist, aber das Filesystem und die Grafikoberflaeche ist dann auch > nicht frei? > Wenn die Toolchain frei ist, kann ich die auf nahezu beliebige Betriebssysteme portieren. >> s.o.: was ist mit debuggen? > > Du kannst dir kein USB-KAbel leisten? Mehr brauchst du nicht. > > Oder bist du lernresistent weil ich das bereits mindestens zweimal in > epischer Breite erklaert habe? > Ja!...und ich habs auch gefühlte 100mal erklärt: wenn der einzige verfügbare Debugger "closed Source" UND eine "kastrierte Trial-Version" ist, die mir auch noch das OS vorschreibt, ist das eben NICHT offen!!!! Falls du es noch nicht mitbekommen hast...ich arbeite mit Linux!..ausschliesslich mit Linux!!! Entweder, wir benutzen Software, die4 JEDER benutzen kann, egal, ob Windoof MacOS oder Linux, oder wir lassen es....nur ist es dann kein OpenSource mehr, und ich bin raus! Harry
Harald L. schrieb: > und ich bin raus! Du warst noch nie drin. open source deiniert sich nicht über die verwendeten Tools, Prozessoren oder Betriebssysteme oder sonstige Nebensächlichkeiten wie Wunschlisten oder gar Wunschlistenersteller. open source definiert sich über diejenigen, die etwas realsieren und es zur Verfügung stellen. Da gilt die brutale Kraft des Faktischen. Wer etwas tut, setzt die Standards. Und wenn Kai am Ende eine Platine entwirft, nimm sie, wie sie ist, oder mach selber eine neue (wenn du kannst). Wie bei 99,999% aller allen anderen open-source-projekte auch. sourceforge ist voll davon. Die kanpp zwei Dutzend lebdenden Projekte, bei denen das anders ist (linux, gcc, apache, etc.), kann man da vernachlässigen. Oliver
Oliver schrieb: > Harald L. schrieb: >> und ich bin raus! > > Du warst noch nie drin. > Ach?.....aber du?...oder was willst du mir damit sagen? "drin" sind imho die, die sich für das Projekt stark machen, und was dazu beitragen.... > sourceforge ist voll davon. Die kanpp zwei Dutzend lebdenden Projekte, > bei denen das anders ist (linux, gcc, apache, etc.), kann man da > vernachlässigen. Ach!..."vernachlässigen"???....soso! Diese Projekte sind deshalb so erfolgreich, WEIL der OpenSource-Gedanke hier voll zum Tragen kommt! Harry
Ich möchte diese Diskussion aus den letzt paar Posts an dieser Stelle beendet sehen, ich denke das dieser Eingriff in die Diskussion auch im Sinne des Thread-Openers ist, sonst möge er mir verzeihen. Die Plattform wird so ausgelegt, dass gcc verwendet werden kann. Es wird nicht nötig sein, eine IDE vorzuschreiben. Es wird nicht nötig sein mehr als ein paar Euro für einen Programmer/Debugger auszugeben, so er nicht ohnehin schon vorhanden ist. Wenn keine der möglichen Chiplieferanten sich zu einer Art Sponsoring überreden lässt, wird die Plattform selbst ohne Gehäuse bei geschätzten 200..300€ liegen, und da sind wir uns noch nicht mal Sicher, ob da schon ein schönes Display mit drinn ist. Daher wird es ein JTAG ala openocd-usb o.Ä. tun müssen um zum einen die Systemkosten nicht noch weiter explodieren zu lassen und außerdem etwas zu haben, was man später auch für andere Projekte nutzen kann. Wer unter Linux entwickeln will, wird das tun können, wer unter Windows entwickeln will, wird das auch tun können. Unter MAC-OS fehlt mir die Erfahrung um dazu was zu sagen, vermutlich gibt es aber auch eine Lösung dafür, wie es Yagarto für Windows ist. Damit ist dieser Punkt geklärt.
Oliver schrieb: > Harald L. schrieb: >> und ich bin raus! > > Du warst noch nie drin. > Solche Posts sind insgesammt im uc.net nicht gerne gesehen. Bitte ändere Deinen Ton ein wenig. Danke! Deine Ausführungen zur Definition von open-source sind nur teilweise richtig. Es ist entscheidend ob jemand, der den open-source-code nutzen möchte mit vertretbarem Aufwand auch dazu in der Lage ist. Wenn sich bei einem Projekt gleich von Anfang an interessierte und versierte Interessenten finden, die auf unterschiedlichen Plattformen arbeiten, dann ist es billig und recht auf diese Belange einzugehen. In dieser frühen Phase kann man ganz getrost entscheiden, ob eine CPU wegen solcher, in manchen Augen vielleicht banalen, Faktoren wie Betriebssystemvoraussetzung der IDE, drin ist oder raus. Das liegt im Ermessen der Projektbetreiber. In jedem Thread über Linux oder Windows finden sich Leute, die diese Diskussion um der Diskussion willen anstacheln, hier nicht. Siehe Post von vorhin. An sonsten ist open-source eine schwammige Geschichte, auch open-source Code kann mit closed-source code vermischt sein, siehe diverse Treiber unter Linux. Wenn NXP uns zusichert, dass alle, die auf dieses Projekt referenzieren eine kostenlose IDE für irgendwas bekommen, dann ist das für mich auch open-source, wenn nur die vier Initiatoren diesen Luxus erhalten, ist es kein open-source, weil der Quelltext zwar offen wäre, aber niemand mehr ohne Zusatzkapital damit was anfangen kann.
Ulrich P. schrieb: > Solche Posts sind insgesammt im uc.net nicht gerne gesehen. Bitte ändere > Deinen Ton ein wenig. Danke! Ach je, wer wann was in den wilden Weiten des Internets oder auch im uc.net insgesamt oder auch ganz persönlich nicht gerne sieht, ist ziemlich belanglos. Aber um die Sache mal etwas deutlicher auf den Punkt zu bringen: Das hier ist bisher kein open source Projekt, und es wird auch niemals eins werden. Selbst wenn am Ende hier ein, zwei Spezialisten eine funktionsfähige Hardware erstellen, und das Ding auf dem Labortisch tatsächlich Musik empfangen sollte, und alle Unterlagen dazu auch noch unter GPL veröffebtlicht werden, wird es genau das blieben: Eine Bastelübung von ein bis zwei Spezialisten. Solange das alles auf für Privatpersonen nicht beschaffbaren Chips und nicht verfügbaren Entwicklungstools basiert, kann das noch so open source im Sinne von frei nutzbar sein, es wird niemals irgend jemand nachbauen, geschweige denn drann mitentwickeln. Es drängt sich mir eher der Verdacht auf, daß von dem einen oder anderen eine als Bausatz/Fertigplattform vermarktbare Basis für eine (dann vielleicht eher open-source-geeignete) Software geschaffen werden soll. Nun ja, warum nicht. Solange allerdings noch nicht einmal von den (anscheined sich selbst ernennenden) Projektleitern formuliert werden kann, was das Gerät am Ende aus ihrer Sicht besser/schneller/anders/billiger/schöner können kann, als ein Fertiggerät von Feinkost Albrecht-Wühltisch, ist das alles doch völlig zweckfrei. Ausser dem Selbermachen des Selbermachen willens hat so etwas keinen Sinn. In diesem Sinne Oliver
Oliver schrieb: > Ulrich P. schrieb: >> Solche Posts sind insgesammt im uc.net nicht gerne gesehen. Bitte ändere >> Deinen Ton ein wenig. Danke! > > Ach je, wer wann was in den wilden Weiten des Internets oder auch im > uc.net insgesamt oder auch ganz persönlich nicht gerne sieht, ist > ziemlich belanglos. > Genau!....und darum schreibst du hier auch anonym als Gast.. > unter GPL veröffebtlicht werden, wird es genau das blieben: Eine > Bastelübung von ein bis zwei Spezialisten. Solange das alles auf für > Privatpersonen nicht beschaffbaren Chips und nicht verfügbaren > Entwicklungstools basiert, kann das noch so open source im Sinne von > frei nutzbar sein, es wird niemals irgend jemand nachbauen, geschweige > denn drann mitentwickeln. > Wer bist du, daß du das so genau weisst? Du hast ja offensichtlich nichtmal den Tread vollständig gelesen. > Solange allerdings noch nicht einmal von den (anscheined sich selbst > ernennenden) Projektleitern formuliert werden kann, was das Gerät am > Ende aus ihrer Sicht besser/schneller/anders/billiger/schöner können > kann, als ein Fertiggerät von Feinkost Albrecht-Wühltisch, ist das alles > doch völlig zweckfrei. Ausser dem Selbermachen des Selbermachen willens > hat so etwas keinen Sinn. > und warum langweilst du uns mit deinen (anonymen) Posts, wenn dich das Projekt sowieso nicht interessiert? Harry
Es ist wie in der Liebe: Am Anfang schwebt man auf Wolke Sieben aber schon bald kommt das zerdepperte Geschirr ;-)
Das macht die Entfernung wenn man das Projekt zB gestartet hätte mit 2 bekannten oder so dann wären die ganzen anfänglichen Sachen schon ausdiskutiert gg
Sicherlich, aber wo bleibt der ganze Spaß? Ohne Kai wäre ich vermutlich nie auf den Dirana2 Chip gekommen, egal ob NXP ihn jetzt raus rückt, oder nicht. Kai wäre vielleicht nicht auf Nut/OS gekommen, Harald säße vielleicht allein auf einem SuperH, wer weiß. Jedes Projekt beginnt mit der Sammlung von Ideen unterschiedlicher Kompetenzen. Leider scheint das nicht allen klar zu sein und so quasseln sie völlig am Thema vorbei rein und ziehen das ganze in eine persönliche Richtung. Ist wie in einer großen Firma :) Tragen wir das doch einfach mit dem nötigen Humor. Wenn es ein Projekt für ein paar Spezialisten bleibt, was ist daran schlimm? Vielleicht reicht es bei dem einen, den Tuner nebst dessen Software zu verwenden, bei einem anderen hilft die I2C-Bus Implementation, der Dritte ist glücklich, weil er sich einen anderen Teil der Entwicklung zu Nutze machen kann. Ich habe auch mal in einem Thread über PID Regelung viel gelernt ohne mir da besprochene Motorsteuerung nach gebaut zu haben, ich wollte einen Kühler regeln. Ich bin, sobald das OSCAR gewisse Grundformen angenommen hat, diesen Thread zu schließen und einen neuen auf zu machen.
Kai G. schrieb: > Hallo! > > Ich wollte mal vorsichtig fragen ob es Leute gäbe die prinzipiell > Interesse daran hätten an einem noch nicht existierenden Open source > Projekt teilzunehmen bei dem es darum geht ein komplettes Autoradio zu > entwickeln. Sowas in der Richtung baue ich gerade... > Was mir vorschwebt: > - Optik: Das Radio sollte nicht wie ein "Ufo" aussehen Wie dann? > - Größe: Single DIN > - Evtl. eine Gehäusevariante für ein Stand alone radio (AKA > Küchen/Kofferradio) > - Es soll möglich sein eine komplette MP3 Sammlung inkl. Cover zu > speichern Ich verwende SDHC Karten und 32 Gbyte sollten auseichend sein > - Farbdisplay (soll auch MP3 cover anzeigen können) Wo bekomst DU ein TFT mit 8x3cm (mindestens) her? > - 2*Rotary button bedienung (Ähnlich Becker Grandprix) + ein paar feste > Funktionstasten Wo bekommst Du die Rotary buttons? Ich habe nur sockhe wie in den Handies gefunden. > - Radio features: > * FM only (Mittelwelle/Langewelle und co ist denk ich heutzutage nicht > mehr echt interessant) SiLabs Si4735 macht dann alles in einem UKW, KW, MW und LW und hat eine minimale Beschaltung > * Frequency diversity zur Empfangsverbesserung mit einer Antenne wäre > schön > * evtl. DRM (?) Ehm und die Lizenz? Paßt igendwie nicht mit OSS zusammen > * RDS, inkl. Follow me, Radio text (+), TA, EON RDS ist mm SiLabs Si4735 drin > * Evtl. TIM (Aufzeichnung von Verkehrsnachrichten wenn das Radio > eigentlich aus ist und wiedergabe wenn das Auto das nächste mal > gestartet wird). > * search tuning up/down > * automatische Suche nach den aktuell stärksten Sendern (inkl. > Aussortierung von dubletten auf Basis von RDS Infos) Ist ja irgendwie standard oder? > * Der Empfang sollte wirklich sehr gut sein. Gutes Groß- und > Kleinsignalverhalten. > * Abschaltbare Phantomspeisung (wichtig für "moderne" Autos, sonst ist > der Empfang sehr besch§$%) > * nur wenn Platz im Display ist: Senderlogogs sollten angezeigt werden Reine programmiersache > - "MP3"-funktion: > * MP3 Wiedergabe (alle Bitraten/VBR/ID3V1 und ID3V2 support) > * MP3s, evtl. andere codecs (OGG, FLAC, ... ?) VLSI Solutions: VS1053 (MP3 + sonstwas Lizenz bereits im Chip drin) > * Einfache und schnelle (!) Navigation durch große MP3 Sammlungen > (Evtl. Hierachie Artist/Album/Track) > * Datenspeicher: z.B. SDHC Karten. Es wäre auch denkbar mehrere Karten > gleichzeitig zu unterstützen um den Speicher zu erweitern. Alternativ: Ist ja wohl standard... > Ein USB OTG Host mit Mass storage support. Hat ja sowieso jeder Microcontroler bei 200MHz und mehr drin Ich verwende übrigends einen Atmel AT91SAM9263 > - Audio Optionen: > * 4 Kanal Verstärker (Evtl. Class-D) Maxim hat excelente ClassD 25W endstufen > * Fade / Balance > * Einfacher Equalizer Kann jeder I²S AudioCODeC > - Evtl. Bluetooth Hands free option Ich würde aber eine leistungsfähigen BlueTooth LMX9338 chip nehmen, damit man das Radio auch fernbedinen kann > - Design Grundsätze: > * Funktionen sollten leicht erreichbar sein (keine 3 fach > Shiftfunktionen auf Buttons, etc...) > * Die Reaktion auf Benutzerfunktionen sollten schnell erfolgen. Wenn > eine Funktion länger dauert sollte sie vor Beendigung schon eine > Reaktion auf dem Display zeigen. > - Sehr schön wäre auch die Möglichkeit um den CAN Bus von Autos mit > einzubinden um Sonderfunktionen wie z.B. PDC auf dem Radio anzuzeigen. > Sowas ist Herstellerspezifisch, man kann es jedoch in der Hardware > vorsehen und in Software auswählbar gestalten. > - Evtl. Optionen um andere selbst entwickelte Boards einfach in die > Hard- und Softwareumgebung einzubinden, z.B. Amateurfunk transceiver, > Datenlogger, ... > - OBD2 Diagnose Option / Anzeigen oder Loggen von Sensordaten? Hmmm, wennd as alles dazu kommen soll, würde ich einen TI OMAP 3530 empfehlen, allerdings auc nur, wel ich einem GSM/UMTS-Receiver mit drinn habe, der mir Video-Telefonie erlaubt, ein ImageSensoer Interface hat und mit einem ausklappbaren 5"7 Display umgehen kann. > Was haltet Ihr davon? Die Liste ist nur als Vorschlagliste zu verstehen > und natürlich nicht 100% fest. Nach dem heutigen Stand der Technik könnte ich die Liste verdreifachen und aus dem "Autoradio" eine "eierlegende Wollmilchsau" machen... > Das Decoding von MP3 kann man in der CPU machen, da gibt es einige Open > source projekte die fertigen code anbieten der schon auf ARM7 > controllern gut läuft. Vergiß es den streß ist es nicht wert! Einen Treiber für den VS1053 kann man schneller schreiben als die frickeleim mit den Liux Audio-CODECS > Da ich sowas ähnliches schon gemacht habe weiß ich sicher das solch ein > Projekt definitiv auch mit wenig Leuten (2) machbar ist, allerdings > würde ich sowas gerne mit mehreren Leuten zusammen machen. > So kommt man sicher auch noch auf andere gute Ideen und Sachen sind > einfacher zu realisieren weil man einfach nicht auf allen Gebieten ein > Experte ist. ;-) > Ich würde übrigens auch gerne wirklich alles Quelloffen machen, inkl. > der Hardware. Willkommen im Club! > Viele Grüße, > Kai Grüße Michelle
Hörmel schrieb: > Ähm aber hey ich will ja nix miesmachen hier aber wie issn des mitti ABE > bei so selbstbastelkram? > :-/ Also ich habe mittlerweile weit über 200 ABE's hinter mir sowie ein gutes dutzend Serienzlassungen. Für Autoradios sind die absolut nicht relevantund kosten so um die 400-600 Euro. Sollte bei dem Project eine Firma sich beteiligen und eine Serienzulassung für ein besimmtes baumuster beantragen, kostet das auch nur 2000-4500 Euro. Grüße Michelle
Tach Michelle wie gehts deinem Handheld ? Oder bin bin ich grad auf dem Holzweg ? lg Patrick
Michelle Konzack schrieb: > Sowas in der Richtung baue ich gerade... Beruflich oder als privates Projekt? Gibts irgendwo infos? >> Was mir vorschwebt: >> - Optik: Das Radio sollte nicht wie ein "Ufo" aussehen > Wie dann? Halt "Dezent". Siehe z.B. Becker radios. > Ich verwende SDHC Karten und 32 Gbyte sollten auseichend sein 32 GB wäre mir zu wenig. Daher wollte ich mehrere Slots vorsehen. >> - Farbdisplay (soll auch MP3 cover anzeigen können) > Wo bekomst DU ein TFT mit 8x3cm (mindestens) her? Wer hat von 8x3cm geredet? >> - 2*Rotary button bedienung (Ähnlich Becker Grandprix) + ein paar feste >> Funktionstasten > Wo bekommst Du die Rotary buttons? Überall, z.B. Reichelt. >> - Radio features: >> * FM only (Mittelwelle/Langewelle und co ist denk ich heutzutage nicht >> mehr echt interessant) > > SiLabs Si4735 macht dann alles in einem UKW, KW, MW und LW und hat eine > minimale Beschaltung Der Si4735 ist ein reiner Portablechip und erfüllt nicht die Anforderungen die man in einem Autoradio hat. Er ist eher zu vergleichen mit den zuvor schon erwähten TEA5990/1/2. Ich redete über ein qualitativ hochwertiges Radio, daher hatte ich auch echte CAR-tuner vorgeschlagen. >> * Frequency diversity zur Empfangsverbesserung mit einer Antenne wäre >> schön >> * evtl. DRM (?) > Ehm und die Lizenz? Paßt igendwie nicht mit OSS zusammen Mit DRM meinte ich Digital Radio Mondial, nicht das blöde Digital Rights Management. >> * RDS, inkl. Follow me, Radio text (+), TA, EON > RDS ist mm SiLabs Si4735 drin Ja, aber es ist halt ein Portable chip und schon die Anforderungen für einen RDS follow me Algorithmus sind andere als in einem Auto. > Ist ja irgendwie standard oder? Steht auch deshalb in der Featureliste, oder gehören da nur inovative neuigkeiten rein? > Reine programmiersache S.o. > Ist ja wohl standard... S.o. >> Ein USB OTG Host mit Mass storage support. > Hat ja sowieso jeder Microcontroler bei 200MHz und mehr drin > Ich verwende übrigends einen Atmel AT91SAM9263 S.o. > Maxim hat excelente ClassD 25W endstufen Ja, NXP, TI, ST auch, aber muss ja trotzdem in die feature liste :-) > Kann jeder I²S AudioCODeC jup >> Das Decoding von MP3 kann man in der CPU machen, da gibt es einige Open >> source projekte die fertigen code anbieten der schon auf ARM7 >> controllern gut läuft. > Vergiß es den streß ist es nicht wert! Einen Treiber für den VS1053 > kann man schneller schreiben als die frickeleim mit den Liux > Audio-CODECS Hab es schon mehrfach gemacht, streß würd ich es nicht nennen. Aber klar, ein VS1xxx ist einfacher und warum nicht... Kai
Michael B. schrieb: > Also wir setzen Debian Stable in embedded Systeme bei unseren Kunden > ein. Die laufen dort bereits seit Jahren ohne Probleme oder Unterbrüche. Ich bin seit 1999 Debian User und seit gut 2001 Linux Developer verwende ausschließlich Debian GNU/Linux sowie Emdebian. > Eine Instabilität können wir überhaupt nicht feststellen. Das > Basissystem (ohne X-Windows Server) ist extrem stabil und sehr > resourcenschonend. Für meine Embedded Systems verwende ich den GTK-Pixbuf... Eine bessere GUI kannste auf einem Embedded ARM nicht haben. > Zudem setzen wir Asterisk auf eine angepasste Linux-Distro ein. Die > läuft auch schon seit zwei Jahren ohne Unterbruch und steuert alle > unsere Telefonate. Ausserdem laufen bei uns im Unternehmen auch alle > Router und Telefone unter Linux, bisher auch fehlerfrei. Ich verwende auch Asterisk, bin aber dabei, nebenbei noch FreeSWITCH zu testen, weil Asterisk keine GSM-Modems unterstützt oder haste da resource dafür? (Kannst mich per PM konaktieen) > Von Seiten der Wartbarkeit hat sich die Modularität für uns sehr positiv > ausgewirkt. An einer grossen monolythischen Firmware ist die Wartung und > Pflege eine Sache, die zumeist von einem Spezialisten duchgeführt werden > muss, der die gesamte Firmware kennt. Mit modularen Systemen können > unterschiedliche Entwickler an verschiedenen Komponenten arbeiten. > > Aus meiner Sicht spräche aber vor allem der Punkt, dass man auf bereits > entwickelte, sehr stabile Komponenten setzen kann und nicht alles > neuentwickeln muss, für den Einsatz eines embedded Linux. Zudem können > Nutzer recht einfach weitere Komponenten für sich hinzunehmen. > > Just my 2c. ...und meinen 2¢ dazu > Michael Grüße Michelle
Hi Michelle! Nur mal so zusammen fassend: Du steckst gerade in der Entwicklung von solche einem Radio. Fein. Gehen wir es mal durch: SDHC Karten sind auch geplant, dass sie ausreichen stimmt in meinem Fall leider überhaupt nicht, ist aber in diesem Fall meine Sache und fließt deswegen auch nicht übermäßig in das Projekt ein. TFT oder OLEDs mit merkwürdigen Maßen sind nicht so selten wie man denkt. Und da mich die diversen Kollegen der Distis immer gerne besuchen, kann man da was organisieren. Silabs scheidet aus zwei Gründen aus. Zum einen soll ein gutes Diversity eingerichtet werden, da kennt Kai sich mit aus und es ist auch eine Grundlage für das Projekt überhaupt. Der zweite Grund ist die Qualität der Chips... Ist noch nicht so wirklich perfekt. Bin aber später gerne mal bereit einen Silabs gegen einen NXP Tuner antreten zu lassen, der R&S UPD steht hier und wartet auf seinen Einsatz :) Wie Du schon sagt, MP3 und diverse andere CoDecs liefert der kleine VLSI Chip einwandfrei und um die Lizenzen braucht man sich keine Gedanken zu machen. Das wurde in diesem etwas aus den Fugen geratenen Thread auch schon so definiert. Da wir mehr und mehr darüber nachdenken Nut/OS als System einzusetzen, ist der VLSI überhaupt kein Thema, die Treiber existieren schon. Musst ihn nur noch aktivieren und mit Daten füttern. Das mit dem I2S AudioCoDec ist eben so das Problem. Wie zuvor schon geschrieben, gibt es da manchmal tolle Datasheets oder auch Flyer und Versprechen, aber eben keine Chips, wenn man nicht als Bose, Siemens, Delphi oder so anruft. Als Privatmann bekommt man nicht mal ein Sample. Oder man bekommt es als Bekannter eines Angestellten, ehemaliger Mitarbeiter oder so, aber die anderen bekommen es eben nicht. Es gibt eine reihe kleiner CoDecs, die sind aber nicht wirklich dolle. Klanglich gut, aber Featuremäßig eher bescheiden. Da dürfte sich der Chip etwas verloren vorkommen in unserem Design. Bluetooth ist sicherlich eine Idee. A2DP und ähnliche Dinge sind mir ebenso in den Sinn gekommen. Es gibt ja auch die Option ein GSM/UMTS Modul zu integrieren, was die SIM eines Handies via BT übernimmt. So braucht man keine zweite Karte und hat eine Nummer. Das Radio selbst fern zu steuern finde ich jetzt eher weniger witzig, eventuell interessant für Parties im Wald. Ach ja, die OMAPs... Die sind schon sehr mächtig, gar keine Frage. Aber ich sehe nicht, dass man im Auto Video-Fon braucht. Und statt meinem DVD eine Rückfahr-Camera ins LCD einzublenden, das ist kein Akt. Da reicht ein kleiner Video-Switch. Und die Rotary-Encoder... Die gibt es wie Sand am Meer. Schau mal u.A. bei ALPS nach. Aber Vorsicht, da gibt es gute und schlechte. Die Routinen für solch ein Teilchen stehen auch auf der Liste der max-2-abende Projekte für Nut/OS. --- Mehr so an alle dann noch die Info, dass ich heute mal wieder etwas Kernel gebaut habe für den AVR32AP7000 auf einem ADB1000pro DevKit. Der ist in knapp 5s bis auf login. Und da geht auch noch was mehr. Also wenn man das Radio mit der Zündung oder dem Tür öffnen startet, dann sehe ich da auch keine Probleme. Also die Option, einen kleine CPU durch ein Mini-Modul ala AP1000 zu übersteuern, wenn man es möchte, ist auch keine schlechte Idee. Da wäre dann auch Michelles Video-System mit möglich. CU Ulrich
Zum Thema Display: Ich hab mich heute Abend längere Zeit mit Kai via Skype unterhalten, und wir sind zu folgender Lösung gelangt: Wir verwenden 2!!!! S65-Displays, die nebeneinander im Querformat angebracht werden. Der Steg zwischen den beiden Displays wird ca. 8mm breit. Was auf den 1. Blick ein wenig „strange“ aussieht, hat aber durchaus praktische Vorteile: * die Displays sind für jeden verfügbar * die Programmierung ist kein Problem * in Menus sieht man immer die aktuelle und vorherige Ebene * man kann beim Blättern in mp3-Sammlungen immer 2 Hirarchieebenen darstellen * Im reinen Radio-Mode kann eines der Displays das Sender-Logo darstellen Auf diese Weise machen wir aus der Not eine Tugend :) Harry
seennoob schrieb: > Tach Michelle wie gehts deinem Handheld ? > Oder bin bin ich grad auf dem Holzweg ? > > lg Patrick TablePC 1 ========= Ich bin derzeit etwas ausgebremst, denn der TI Sitara AM3517 läßt mich unter Linux nicht für das Display Iterface den FlatLink3D aktiviren, was ich unbedingt benötige, denn wenn ich das 24Bit RGB interface + Steuerleitueg nehme, frißt es ir I/O Leitungen... TabletPC 2 ========== Der TI OMAP 3530 it ein Killer und ich habe hier in 5 Ordnern 7800 Seite Dokumentation... :-/ PanelPC 1 ========= Der Marvel Armada 300 (2000MHz) ist noch gigantischer als der OMAP 3530. Nachdem ich das NDA unterzeichnet hatte, habe ich den Zugriff auf das Extranet bekommen... Argggghhhhh!!!!! 17200 Seiten Dokumentation! Server 1 ======== Wieder Marvel aber diesesmal MV78200 mit 2 GigaEthernet Anschlüssen, SO-Dimm (bis 1 GByte) und mit zwei 8-Port SAS/SATA Raid-1/10/5 Controllern. Den könnte ich in 2-3 Montaten inclusive Zertifikation hinbekommen haben. Fehlt nur noch der Open-Source Linux-Treiber für die SAS Controller... Den lasse ich warscheinlich von jemanden Programmieren, kostet dann aber auch gut 40.000 Euro. Die Hardware selber läuft bereits mit Marves proprietären Closed-Source Treibern Grüße Michelle
achso....noch etwas: der ARM7 steht für das Mainboard fest! Weitere Diskussionen zwecklos!!! Harry
Ulrich P. schrieb: > Hi Michelle! > > Nur mal so zusammen fassend: > Du steckst gerade in der Entwicklung von solche einem Radio. Fein. Nicht direkt Radio, aber ich teste derzeit verschieden ARM9/11 und Cortex für eine "Media und Communication Box". Ein vollständig aufgemozter unscheinbar aussehender Bilderrahmen... > Gehen wir es mal durch: > SDHC Karten sind auch geplant, dass sie ausreichen stimmt in meinem Fall > leider überhaupt nicht, ist aber in diesem Fall meine Sache und fließt > deswegen auch nicht übermäßig in das Projekt ein. 32 GByte mit ner SDHC nicht genug? Der Sitara AM3517 un der OMAP 3530 unterstützen auch SDXC Karten. Dan kannste bis zu 2 TByte haben. > TFT oder OLEDs mit merkwürdigen Maßen sind nicht so selten wie man > denkt. Und da mich die diversen Kollegen der Distis immer gerne > besuchen, kann man da was organisieren. Das Problem ist, das die Displays welche ANSTÄNDIG in ein Car-DIN gehäuse passen alles Custom-Displays sind und nicht normal gekauft werden können. Ich stehe vor dem problem das ich ein Display mit 1024x256/262k (~140x40mm) benötige und die Toolchain dafür kostet bei Formike oder auch AUO mal gute 150.000 US$ was sich dann nur rentiert, wenn ich mindestens 30.000 Displays fertigen lasse, also 6 mal mehr als ich benötige > Silabs scheidet aus zwei Gründen aus. Zum einen soll ein gutes Diversity > eingerichtet werden, da kennt Kai sich mit aus und es ist auch eine > Grundlage für das Projekt überhaupt. Der zweite Grund ist die Qualität > der Chips... Ist noch nicht so wirklich perfekt. Bin aber später gerne > mal bereit einen Silabs gegen einen NXP Tuner antreten zu lassen, der > R&S UPD steht hier und wartet auf seinen Einsatz :) Nagut, ich verwende den SiLabs in meinem prototypen "TabletPC 1" und ich habe excelente ergebnisse. > Da wir mehr und mehr darüber nachdenken Nut/OS als System einzusetzen, > ist der VLSI überhaupt kein Thema, die Treiber existieren schon. Musst > ihn nur noch aktivieren und mit Daten füttern. Weist Du ob es Linux-Treiber (ARMel) dafür gibt? > Das mit dem I2S AudioCoDec ist eben so das Problem. Wie zuvor schon > geschrieben, gibt es da manchmal tolle Datasheets oder auch Flyer und > Versprechen, aber eben keine Chips, wenn man nicht als Bose, Siemens, > Delphi oder so anruft. Als Privatmann bekommt man nicht mal ein Sample. > Oder man bekommt es als Bekannter eines Angestellten, ehemaliger > Mitarbeiter oder so, aber die anderen bekommen es eben nicht. Das mußte mir mal erklären! Also ich habe hier von National, TI, Maxim und ADI und Conexant ohne Schwierigkeiten CODECSs bekommen. Als Samples und gekauft. In meinem PanelPC will ich den AD1989 einsetzen. > Es gibt eine reihe kleiner CoDecs, die sind aber nicht wirklich dolle. > Klanglich gut, aber Featuremäßig eher bescheiden. Da dürfte sich der > Chip etwas verloren vorkommen in unserem Design. Erzähl mal lieber welchen du verwenden möchtest. :-D Ich kann dann zusehen das ich sie bekomme. > Bluetooth ist sicherlich eine Idee. A2DP und ähnliche Dinge sind mir > ebenso in den Sinn gekommen. Es gibt ja auch die Option ein GSM/UMTS > Modul zu integrieren, was die SIM eines Handies via BT übernimmt. So > braucht man keine zweite Karte und hat eine Nummer. Das Radio selbst > fern zu steuern finde ich jetzt eher weniger witzig, eventuell > interessant für Parties im Wald. Nee, eher für die jenigen die fuf der Rücksitzbank MP3 per Kopfhörer hören wofür die IR-Fernbedieneung eigentlich von den CarAudio Herstellern gedacht war. > Ach ja, die OMAPs... Die sind schon sehr mächtig, gar keine Frage. Aber > ich sehe nicht, dass man im Auto Video-Fon braucht. Und statt meinem DVD > eine Rückfahr-Camera ins LCD einzublenden, das ist kein Akt. Da reicht > ein kleiner Video-Switch. Dafür würde ich vm OMAP 3530 das Image-Interface und einen LVDS controller verwenden > Und die Rotary-Encoder... Die gibt es wie Sand am Meer. Schau mal u.A. > bei ALPS nach. Aber Vorsicht, da gibt es gute und schlechte. Die > Routinen für solch ein Teilchen stehen auch auf der Liste der > max-2-abende Projekte für Nut/OS. OK > Mehr so an alle dann noch die Info, dass ich heute mal wieder etwas > Kernel gebaut habe für den AVR32AP7000 auf einem ADB1000pro DevKit. Der > ist in knapp 5s bis auf login. Auch normale Autoradios sind im Bereich von 4-10 sekunden bis alles betriebsbereit ist > Also die Option, einen kleine CPU durch ein Mini-Modul ala AP1000 zu > übersteuern, wenn man es möchte, ist auch keine schlechte Idee. > > Da wäre dann auch Michelles Video-System mit möglich. > > CU Ulrich Grüße Michelle
Hallo Harald und Kai, Harald L. schrieb: > Wir verwenden 2!!!! S65-Displays, die nebeneinander im Querformat > angebracht werden. Der Steg zwischen den beiden Displays wird ca. 8mm > breit. Warum wollt ihr nicht ein Display verwenden, das Serienmäßig garantiert verfügbar ist? Ich hate bei Formike neben den 2"2 auch 3"2, 42 und andere bestellt und beim 3"2 habe ich wenigstens die Garantier, das ich es die nächsten 5 Jahre nachkaufen kann. Es wird auch DAS Display sein, welches ich in meiner "HighPower LiPoly SmartBatterie" (33,3V/90Ah) einsetz. Womit ich ja als Hersteller der SmartBatterie schon garantieren muß, das es als Ersazteil verfügbar sein muß. > Was auf den 1. Blick ein wenig „strange“ aussieht, hat aber durchaus > praktische Vorteile: > > * die Displays sind für jeden verfügbar Wie sehr bist Du sicher, das genau das S65 Display verfügbar sein wird? hast Du Dich mit dem Hersteller abgesprochen? > * die Programmierung ist kein Problem > * in Menus sieht man immer die aktuelle und vorherige Ebene > * man kann beim Blättern in mp3-Sammlungen immer 2 Hirarchieebenen > darstellen > * Im reinen Radio-Mode kann eines der Displays das Sender-Logo > darstellen > > Auf diese Weise machen wir aus der Not eine Tugend :) Fickler :-D Grüße Michelle
Hallo Michelle, natürlich ist das nicht die "optimale" Lösung! Aber, du darfst nicht vergessen, daß das ein Projekt sein soll, das möglichst für jeden nachvollziehbar bleibt. Natürlich kann keiner von uns garantieren, daß diese Displays auch in 5j noch als Ersatzteile verfügbar sind. Im Moment sind sie es, und solange die Nachfrage aus der Selbstbau-Fraktion so bleibt, hab ich gute Hoffnung, daß das es noch eine Weile so bleibt. Durch unser modulares Konzept wollen wir ja eben sicherstellen, daß es zu einem späteren Zeitpunkt möglich ist, ein neues Bedienteil zu entwickeln. Im übrigen werd ich dich in den nächsten Tagen mal wegen eines anderen Projekt kontaktieren, was mich schon länger umtreibt, und wo du mir als geeigneter Gesprächspartner erscheinst. Dazu muss ich das allerdings mal aufschreiben. Sobald das fertig ist, bekommst du Nachricht von mir. Geht in Richtung VoIp und GSM/UMTS....wird dich interessieren. ;) Gruss Harry
Kein Problem, ich bin in alles in richtung VoIP offen. Gute Nacht Michelle
Michelle Konzack schrieb: > Ich verwende auch Asterisk, bin aber dabei, nebenbei noch FreeSWITCH zu > testen, weil Asterisk keine GSM-Modems unterstützt oder haste da > resource dafür? (Kannst mich per PM konaktieen) > FreeSwitch ist auch interessant. Wir haben momentan kein GSM-Modem dran, daher reicht Asterisk, das bei uns seit Ewigkeiten läuft (es ging ja oben um das Thema "Instabilität von Linux"). Aber es gibt ein Projekt, das GSM-Modems in Asterisk 1.6 integriert. Läuft mit Standard UMTS-Modems, zwar nicht allen, aber einigen von Huawei. Einige Infos dazu findest Du hier: http://www.ip-phone-forum.eu/showthread.php?s=ed420b9e23d020ce8e83039511c3cc43&t=207737 Grüsse Michael
Btw: Das ist ein Autoradio, keine Telefonzentrale. Also Diskussionen über Asterisk, GSM, UMTS in einen anderen Thread.
> Ich möchte diese Diskussion aus den letzt paar Posts an dieser Stelle > beendet sehen, Geht es dir noch gut? Du wirst mir sicher nicht erklaeren wann ich ein Thema fuer beendet ansehe oder nicht! > Hab es schon mehrfach gemacht, streß würd ich es nicht nennen. Aber > klar, ein VS1xxx ist einfacher und warum nicht... Das haettest du aber eher sagen koennen, dann haette ich vor zwei Wochen gleich ein paar im Elektronikgeschaeft gekauft. :) BTW: Die hatten in Japan im Laden zwei solche Decoder rumliegen. Einmal den Typen den jeder Bastler an seinen langweiligen AVR klemmt, und einmal einen anderen der wohl mehr kann und etwas teurer war. Leider habe ich mir die Bezeichnung nicht gemerkt...muss nochmal schauen... > Die > Routinen für solch ein Teilchen stehen auch auf der Liste der > max-2-abende Projekte für Nut/OS. Wenn man zwei Abende fuer das Auslesen eines Encoder braucht, was doch eigentlich nur 3-4Zeilen Code sind, dann bestaerkt mich das in meiner Ablehnung eines OS. > Wir verwenden 2!!!! S65-Displays, die nebeneinander im Querformat > angebracht werden. Der Steg zwischen den beiden Displays wird ca. 8mm > breit. Ein akzeptabler Ansatz. Nachteil aber vielleicht das andere Leute sich sehr schwer tun etwas eigenes zu entwickeln weil das ganze Bedienkonzept auf so eine ungewoehnliche Oberflaeche abgestimmt sein wird. Ein weiterer Nachteil, Kai hat bei seinem Radio die Knoepfe neben dem LCD um ihnen verschiedene Bedeutung zuweisen zu koennen und umgeht so sehr elegant das grosse Probleme keine Knoepfe mit einer Beschriftung haben zu koennen. Das kostet aber Platz die bei einem schmalen LCD nur wenig vorhanden ist. Man sollte also am besten die Knopfreihe fuer Senderauswahl und aehnliches unter die LCDs packen. > * in Menus sieht man immer die aktuelle und vorherige Ebene Ich wuerde es fuer sinnvoller halten wenn ein LCD immer den aktuellen Systemstatus anzeigt, also das was gerade abgespielt wird, Sendefrequenz und aehnliches, und das andere fuer die Bedienung verwendet wird. > * die Programmierung ist kein Problem Naja, die Programmierung keines LCD ist ein Problem. Es wundert mich aber wieso ausgerechnet ein HandyLCD ein garant fuer gute Verfuegbarkeit sein soll. Da wechseln doch die Designs schneller wie anderorts die Unterhosen. > * Im reinen Radio-Mode kann eines der Displays das Sender-Logo > darstellen In meinem fork wuerde dann da einfach ein Stinkefinger stehen nach der aktuellen GEZ Unverschaemtheit. > der ARM7 steht für das Mainboard fest! > Weitere Diskussionen zwecklos!!! Dann waere alles weitere ohne mich! Weniger weil ich mich nicht mit einem anderen Prozessor anfreunden kann, sondern weil ich etwas gegen autoritaere Vorscheibetypen haben. > 32 GByte mit ner SDHC nicht genug? Das verstehe ich auch nicht. Da passen doch soviele Mp3 drauf das die CDs dafuer schon ein vielfaches jedes Autoradios kosten duerften. > Auch normale Autoradios sind im Bereich von 4-10 sekunden bis alles > betriebsbereit ist Normale Autoradios spielen in derselben Sekunde los wo man sie einschaltet. Selber bei meinem AutoDAT hat es nicht mehr als 1s gedauert wenn das Band schon drin war. > Wie sehr bist Du sicher, das genau das S65 Display verfügbar sein wird? > hast Du Dich mit dem Hersteller abgesprochen? Man muss sich nicht gross mit irgendwelchen Herstellern absprechen. Von so einem Radio werden hoechstens 10-20Stk gebaut werden. Olaf
Olaf schrieb: > Das haettest du aber eher sagen koennen, dann haette ich vor zwei Wochen > gleich ein paar im Elektronikgeschaeft gekauft. :) > BTW: Die hatten in Japan im Laden zwei solche Decoder rumliegen. Einmal > den Typen den jeder Bastler an seinen langweiligen AVR klemmt, und > einmal einen anderen der wohl mehr kann und etwas teurer war. Leider > habe ich mir die Bezeichnung nicht gemerkt...muss nochmal schauen... Man man man, ich muss unbedingt mal nach Japan... Hier ist es schon schwer CMOS ICs oder mal nen AVR zu bekommen... > Wenn man zwei Abende fuer das Auslesen eines Encoder braucht, was doch > eigentlich nur 3-4Zeilen Code sind, dann bestaerkt mich das in meiner > Ablehnung eines OS. Auch ohne OS kann es länger dauern, weil sich die Eigenschaften von den Teilen imt der Zeit ändern können. Hatte ich schonmal mit welchen die 2 Pulse erzeugten, also nicht diese standard quadratur-encoder teile. Bis das stabil und zuverlässig lief vergingen noch deutlich mehr als 2 Tage. Obwohl das Entprellen und so von anfang an berücksichtigt wurde. > Ein akzeptabler Ansatz. Nachteil aber vielleicht das andere Leute sich > sehr schwer tun etwas eigenes zu entwickeln weil das ganze Bedienkonzept > auf so eine ungewoehnliche Oberflaeche abgestimmt sein wird. Ich find es wirklich gut mal etwas anderes und neues zu machen statt dem Standard zu folgen. Das Konzept mit den 2 Displays kann wenn man darüber nachdenkt und nicht einfach 0815 mässig so tut als ob es 1 wäre interessante neue Konzepte ermöglichen. Man denke da z.B. an den Nintendo DS. Das fanden auch alle erstmal komisch. > Ich wuerde es fuer sinnvoller halten wenn ein LCD immer den aktuellen > Systemstatus anzeigt, also das was gerade abgespielt wird, Sendefrequenz > und aehnliches, und das andere fuer die Bedienung verwendet wird. Auch keine schlechte idee... > In meinem fork wuerde dann da einfach ein Stinkefinger stehen nach der > aktuellen GEZ Unverschaemtheit. Aber bitte einen der ins Radio rein-zeigt, sonst sind Deine Beifahrer beleidigt :-) >> 32 GByte mit ner SDHC nicht genug? > Das verstehe ich auch nicht. Da passen doch soviele Mp3 drauf das die > CDs dafuer schon ein vielfaches jedes Autoradios kosten duerften. Mit 32 GB komm ich leider wirklich nicht aus, das empfinde ich bei meinem Iphone schon immer als sehr störend weil das auf das ich gerade lust habe nicht da ist (Mein Musikgeschmack ist recht Breit)... Kann mir vorstellen auch 1 externe SD Karte zu machen für die Sachen die dynamisch dazu kommen und 1-2 interne hinter dem Frontpanel...
Olaf schrieb: >> der ARM7 steht für das Mainboard fest! >> Weitere Diskussionen zwecklos!!! > > Dann waere alles weitere ohne mich! Weniger weil ich mich nicht mit > einem anderen Prozessor anfreunden kann, sondern weil ich etwas gegen > autoritaere Vorscheibetypen haben. Was ist daran autoritär, wenn der Threadopener / Projektinitiator eine Prozessorauswahl macht? In letzter Zeit streiten sich alle um den Prozessor. Jeder will "seinen" Prozessor haben. Das geht aber nicht, da sonst jeder sein eigenes Board routen und fertigen lassen müsste. Das geht ins Geld. Ich finde es gut, dass endlich der Prozessor (LPC2468?) feststeht. Damit ist endlich dieser nervige Frontenkrig vorbei. Praktisch ist, dass ich bereits zwei LPC2478 (entspricht wohl dem LPC2468 plus zusätzlichem LCD-Controller) incl Experiementierboard vorliegen habe.
> Man man man, ich muss unbedingt mal nach Japan... Hier ist es schon > schwer CMOS ICs oder mal nen AVR zu bekommen... Ich habe gerade mal kurz geschaut. Die haben da den VS1011E fuer 600Yen und den VS1053B fuer 700Yen. Und AVRs bekommt du in Japan eher seltener wie bei uns. Da setzen die Leute viel PICs, H8 oder R8C ein. Manche Leute auch noch Controller auf Z80 Basis weil sie das aus Kindertagen so gewohnt sind. Aber wir kommen vom Thema ab... http://www.vlsi.fi/en/products/vs1053.html Liesst sich so auf anhieb ganz gut. Und kann auch noch OGG. Ist natuerlich ein bisschen geschummelt wenn man sich die fettesten Aufgabe einfach mit 700Yen vom Hals schafft. :-) > Obwohl das Entprellen und so von anfang an berücksichtigt wurde. Hm..ich entprelle da nichts. Ich lese sie einfach nur im TimerIRQ ein. Und hier geht es ja nur um Bedienung. Da haengt kein schnell drehender Motor dran. > Ich find es wirklich gut mal etwas anderes und neues zu machen statt dem > Standard zu folgen. Das finde ich auch. Ich hatte auch schon beim Blick auf dein Radio ueberlegt ob die Encoder links und rechts vom LCD sein muessen. Eigentlich waere es doch sinnvoller beide links neben das LCD zu machen. (optimierung Radioabstand/Armlaengenquotient) Aber dann beschweren sich bestimmt wieder Leute mit Sinn fuer Aesthetik oder Fahrer von Rechtslenkerautos. :-D Jedenfalls empfinde ich zwei LCDs nicht als Notloesung sondern als gute und brauchbare Idee. Sollte man auf jedenfall festhalten. Hat auch fuer die Entwickler grosse Vorteile. Anstatt so einen (IMHO) Unsinn wie Senderlogos auszugeben, koenntest du da ja z.B wichtige Parameter deiner Radioempfaenger ausgeben um so mal beim fahren zu kontrollieren ob alles so laeuft wie man es sich vorstellt. > Kann mir > vorstellen auch 1 externe SD Karte zu machen für die Sachen die > dynamisch dazu kommen und 1-2 interne hinter dem Frontpanel... Hm..ich hatte bis jetzt immer automatisch angenommen das die SD-Karte in die Front reingesteckt wird. Eben weil man mal was neues draufkopiert. > Was ist daran autoritär, wenn der Threadopener / Projektinitiator eine > Prozessorauswahl macht? Hm.. Kai != (andere Leute die was bevormunden) > Jeder will "seinen" Prozessor haben. Das geht aber nicht, da > sonst jeder sein eigenes Board routen und fertigen lassen müsste. Das > geht ins Geld. Das geht schon. Notfalls koennte ich es mir durchaus vorstellen ein eigenes Board zu machen. Ich muss da auch nichts fertigen lassen. Das bekomme ich schon selber hin. .-) > Ich finde es gut, dass endlich der Prozessor (LPC2468?) feststeht. Den Eindruck habe ich nicht. > Damit > ist endlich dieser nervige Frontenkrig vorbei. Praktisch ist, dass ich > bereits zwei LPC2478 (entspricht wohl dem LPC2468 plus zusätzlichem > LCD-Controller) incl Experiementierboard vorliegen habe. Also ich habe keinerlei ARM rumliegen und ich habe auch keinen Debugger/brenner fuer ARMs. Da es also offensichtlich wichtig ist was man schon rumliegen hat, kommt ARM also alleine aufgrund dieser Argumentation schon fuer mich nicht in betracht. Oder kann ich einen ARM auch einfach nur mit einem USB-Kabel brennen und debuggen ohne erstmal zich Kroeten fuer ein Spezialtool auszugeben? Olaf
Olaf schrieb: >> Damit >> ist endlich dieser nervige Frontenkrig vorbei. Praktisch ist, dass ich >> bereits zwei LPC2478 (entspricht wohl dem LPC2468 plus zusätzlichem >> LCD-Controller) incl Experiementierboard vorliegen habe. > > Also ich habe keinerlei ARM rumliegen und ich habe auch keinen > Debugger/brenner fuer ARMs. Da es also offensichtlich wichtig ist was > man schon rumliegen hat, kommt ARM also alleine aufgrund dieser > Argumentation schon fuer mich nicht in betracht. Oder kann ich einen ARM > auch einfach nur mit einem USB-Kabel brennen und debuggen ohne erstmal > zich Kroeten fuer ein Spezialtool auszugeben? 25€ für nen USB-JTAG Adapter sind noch nicht "zich kosten" oder?
Zu Codecs/Klangregelung....... SigmaDSPs bieten extrem viele Möglichkeiten, viel mehr als "normale" Codecs (auch viel mehr als der TDA7418), haben sogar eine spezielle Graf.Entwickl.Umgebung dafür, die zudem UMSONST(!) ist. (man muss zum download nur bei sigmadsp@analog.com einen Softw-Key beantragen). Es dürfte auch kein Problem sein, diese Teile zu beschaffen.
Olaf schrieb: > Ich habe gerade mal kurz geschaut. Die haben da den VS1011E fuer 600Yen > und den VS1053B fuer 700Yen. Ja, preise sind akzeptabel. Wie sieht es mit steuern aus?! Muss man so kleinigkeiten deklarieren? >> Obwohl das Entprellen und so von anfang an berücksichtigt wurde. > Hm..ich entprelle da nichts. Ich lese sie einfach nur im TimerIRQ ein. > Und hier geht es ja nur um Bedienung. Da haengt kein schnell drehender > Motor dran. Ist doch auch eine Form des entprellens wenn du im Timer IRQ abfragst. > Das finde ich auch. Ich hatte auch schon beim Blick auf dein Radio > ueberlegt ob die Encoder links und rechts vom LCD sein muessen. > Eigentlich waere es doch sinnvoller beide links neben das LCD zu machen. > (optimierung Radioabstand/Armlaengenquotient) Aber dann beschweren sich > bestimmt wieder Leute mit Sinn fuer Aesthetik oder Fahrer von > Rechtslenkerautos. :-D Einzige was mir dagegen einfällt: Wenn man den Sender verstellt will man aufs Display gucken und nicht mit Hand/Arm das Display verdecken. Die Einbauposition ist von Auto und Auto unterschiedlich, also bei einigen Autos könnte es OK sein, bei anderen nicht. > Jedenfalls empfinde ich zwei LCDs nicht als Notloesung sondern als gute > und brauchbare Idee. Sollte man auf jedenfall festhalten. Hat auch fuer > die Entwickler grosse Vorteile. Anstatt so einen (IMHO) Unsinn wie > Senderlogos auszugeben, koenntest du da ja z.B wichtige Parameter deiner > Radioempfaenger ausgeben um so mal beim fahren zu kontrollieren ob alles > so laeuft wie man es sich vorstellt. Man kan auch einen schön als Debug Display (in einem speziellen Debugmodus) nehmen um Parameter während der Fahrt umzustellen ohne das Radio selbst aus den Blick zu verlieren. > Hm..ich hatte bis jetzt immer automatisch angenommen das die SD-Karte in > die Front reingesteckt wird. Eben weil man mal was neues draufkopiert. Ja, ich auch... War nur ein Vorschlag falls jemand sagt er will keine 3 SD Karten aus der Front gucken haben. >> Ich finde es gut, dass endlich der Prozessor (LPC2468?) feststeht. Hatte eher den LPC2387 im Auge weil wir kein ext. Memory interface brauchen. > Also ich habe keinerlei ARM rumliegen und ich habe auch keinen > Debugger/brenner fuer ARMs. Da es also offensichtlich wichtig ist was > man schon rumliegen hat, kommt ARM also alleine aufgrund dieser > Argumentation schon fuer mich nicht in betracht. Oder kann ich einen ARM > auch einfach nur mit einem USB-Kabel brennen und debuggen ohne erstmal > zich Kroeten fuer ein Spezialtool auszugeben? Such mal nach "Wiggler", das ist ein 5 Euro Parallelport interface. Oder OpenOCD. Die LPCs kann man aber auch prima über RS232 programmieren.
Warum nicht einfach einen ARM Cortex M3 ? Sind jetzt von der Verfügbarkeit auch ned so schlecht und haben doch mehr Rechenpower im Vergleich zu den ARM7.
> 25€ für nen USB-JTAG Adapter sind noch nicht "zich kosten" oder? Meine Anmerkung war als Ironie gedacht vor dem Hintergrund das man es bei so einer wichtigen Entscheidung wie den Proyessor fuer sinnvoll haelt das man den Controller ja noch rumliegen haette..... > Ist doch auch eine Form des entprellens wenn du im Timer IRQ abfragst. Also ich verstehe es eher so das durch das Funktionsprinzip kein Fehler entstehen kann. Wenn ein Kontakt rumprellt dann bedeutet das ja nur das man maximal zwischen zwei benachbarten Raststellungen wandert, aber trotzdem nie die Position verliert. > Man kan auch einen schön als Debug Display (in einem speziellen > Debugmodus) nehmen um Parameter während der Fahrt umzustellen ohne das > Radio selbst aus den Blick zu verlieren. Dafuer wuerde ich eine RS232 verwenden wollen. Genauer gesagt mache ich das auch schon bei vielen Projecten so. Zusaetzlich hatte ich mal daran gedacht, es aber noch nicht verwirklicht, eine komplette VT102 Emulation zu nutzen. So kann man einen beliebigen Laptop mit Terminalprogramm verwenden und wird seine Messdaten immer korrekt an der richtigen Stelle im Blick haben. > Hatte eher den LPC2387 im Auge Ich habe gerade mal kurz ueberflogen was der koennen soll: http://www.nxp.com/pip/LPC2387_3.html Was mir auffaellt: 1. Sehr wenig Speicher. Aber Okay wenn man sich beschraenkt mag das hinhauen. Macht aber natuerlich weniger Spass ihn yu nutzen. 2. Nur ein I2S Anschluss? Das geht doch garnicht. Wo soll man denn da die Codecs fuer AD-DA anschliessen? Gibt es keinen ARM der fuer Audio optimiert ist? Das Dingen sieht eher so aus als wenn man etwas fuer Netywerksachen bauen sollte. 3. Ich weiss es ist schwer zu vergleichen, aber so mit 72Mhz scheint er mir auch kein Wunder an Geschwindigkeit zu sein, auch wenn es reichen mag wenn man MP3 extern handelt. 4. Die gehen nirgendwo auf die Fliesskommaeinheit ein. Ich meine gut, ich bin bis jetzt auch ohne ausgekommen, aber waer doch mal nett gewesen. 5. Ich lese kein Wort zu SPDIF! Ich meine gut im Autoradio braucht man SPDIF sicher nicht unbedingt, auch wenn es nett waer da mal meinen MP3-Player oder einen DAT anzuschliessen. Aber wenn einer die Hardware auch mal als Heimgeraet verwenden will, war doch auch mal angedacht(?), dann ist das doch ein KO-Kriterium. Niemand will zuhause eine Geraet haben das kein SPDIF hat. Ich habe den Eindruck als wenn das Dingen nur in der Leistungsklasse eines R32C spielt. Irgendwie kommt mir das zu mager vor. BTW: Gibt es eigentlich keinen Microcontroller der ein Codecinterface bietet wie man es auf MainBoards fuer die Audioausgabe verwendet? Die Teile bieten eigentlich alles was man braucht zentriert an einem Punkt. Bloss ihr Interface ist halt etwas heftig. Oder kann man das an ein I2S Interface bringen? Dann wuerde man mit einem I2S auskommen. Ich weiss jetzt aber nicht wie das mit dem internen Buffer im I2S-Interface und dem DMA hinhaut wenn das deutlich mehr Bits verschoben werden. Ich glaube der Sache werde ich am Wochenende fuer den SuperH nachgehen... > Such mal nach "Wiggler", das ist ein 5 Euro Parallelport interface. > Oder OpenOCD. Naja, ich habe zwar sogar noch einen Parallelport am Hauptrechner, aber da wuerde ich doch von weg wollen. Alleine schon wegen der Kabellaenge! Und mein Netbook hat natuerlich nur noch USB und PCI-Express. Da kann ich meine LPT-Karte auch nicht mehr reinstecken, seufz. Olaf
seennoob schrieb: > Warum nicht einfach einen ARM Cortex M3 ? > Sind jetzt von der Verfügbarkeit auch ned so schlecht und haben doch > mehr Rechenpower im Vergleich zu den ARM7. Und für was genau willst du auf dem Mainboard diese Rechenpower einsetzen? Sie ist einfach nicht erforderlich für den anvisierten Zweck. Ein ARM7_Kern ist hier mehr als ausreichend. Der Cortex M3 ist sicherlich interessant, aber eher für das Multimediaboard. Harry
Es ist doch egal ob einen cortex M3 oder einen ARM7. Der M3 ist genau so schlank wie ein ARM7 aber hat durch die kleinen lieben Feautures mehr Potential. Außerdem wenn ein ARM-Anfänger sich das Projekt ansieht wird der sicherlich eher mit M0 oder M3 arbeiten als mit so einem alten ARM7 Kern. M3 ist in meinen Augen mehr die Zukunft als ARM7. Lg Patrick
Als Codec meinte ich im uebrigens soetwas: http://www.realtek.cz/realtek-datasheet.php?datasheet=ALC202 Also muss jetzt nicht unbedingt genau der sein, aber halt mit dieser AC97 Schnittstelle. Damit haette man doch alles was man an Analog-I/O braeuchte in einem IC. > Ja, preise sind akzeptabel. Wie sieht es mit steuern aus?! Muss man so > kleinigkeiten deklarieren? Beim selber rueberfliegen ist alles bis 3xxEuro frei. Wenn du jemanden dort kennst und es dir schicken laesst, musste theoretisch alles ab 20-30 Euro versteuert werden. In der Praxis sind bei so Kleinteilen natuerlich die Portokosten entscheidend. Ausserdem muss es sehr gut verpackt werden. Ich habe mal eine CD bekommen, da wurde das Paket geoeffnet, kontrolliert und dann aussen ein fetter Stempel draufgedonnert: "Von Zollamtlicher Behandlung befreit" Das stempeln hat dann leider die CD-Huelle durchgebrochen und die CD verkratzt. Dafuer aber zollfrei. :-/ Allerdings muessten die MP3 Teile doch auch bei uns zu bekommen sein oder? Aber notfalls besorge ich die schon. .-) Olaf
seennoob schrieb: > M3 ist in meinen Augen mehr die Zukunft als ARM7. Das hab ich auch schon gelesen. Aber wenn man bedenkt, dass es den ARM7 seit 1993 gibt und den Cortex M3 seit 2005 ist die Frage, was sich langfristig durchsetzen wird.
Olaf schrieb: > Meine Anmerkung war als Ironie gedacht vor dem Hintergrund das man es > bei so einer wichtigen Entscheidung wie den Proyessor fuer sinnvoll > haelt das man den Controller ja noch rumliegen haette..... Nein, das erachte ich nicht für sinnvoll. Hatte ich auch nicht gesagt. Ich meinte nur, dass ich mich damit ja schon etwas auskenne. Also kein absolutes Neuland betreten würde. Es war keine Entscheidungsfrage.
Sven H. schrieb: >> M3 ist in meinen Augen mehr die Zukunft als ARM7. > Das hab ich auch schon gelesen. Aber wenn man bedenkt, dass es den ARM7 > seit 1993 gibt und den Cortex M3 seit 2005 ist die Frage, was sich > langfristig durchsetzen wird. Das ist doch völlig egal. Arm7 ist der 8051 der "Zukunft". Ich hab heute noch regelmäßig mit 8051, und ab und zu sogar mit noch Z80 zu tun. Wir entwickeln kein Produkt das einen 50 Jahre Zyklus überstehen muss. Die Arm7 gibt es jetzt, sie sind verfügbar, Ihre Leistung reicht aus und... sie sind mit mehr Ram verfügbar.
Soll es denn dann einer mit EMC werden? Ich würde das für Vorteilhaft halten. Man hat entweder die Möglichkeit externen Speicher anzubinden oder man hat knapp 64 zusätzliche IO Pins ;-) Würde natürlich ausfallen, wenn der viel teurer wäre. Wir benutzten hier in der Firma nen lpc2214 mit 2MB externem Flash und das läuft wunderbar...
Der Cortex M3 ist eigentlich als potentieller Nachfolger vom ARM7-Kern gedacht. Aus diesem Blickwinkel stimme ich auch für den Cortex. ;-) Ausserdem soll er sich, was ich so gelesen habe, einfacher programmieren lassen. Eine gute Idee ist es alle mal.
Man man man. Immer dieses endlose Gequatsche, diskutieren und streiten. Ihr habt hier schon 15000 Zeilen Text abgelassen (habs gezählt). Anstatt das mal jemand ein Projekt aufmacht und die Energie ind Code oder Sheets investiert werden immer wider die gleichen Diskussionen geführt. Das Ding währ schon längst fertig... warscheinlich sogar 2 davon. Und es nervt das hier immer alles gleich maadig gemacht wird... teilweise auch noch von offensichtlich Ahnungslosen. Konstruktive Kritik is ne feine Sache. Aber hier lassen wohl einige ihren Frust aus, aus welchen Gründen auch immer. Bei den agressiven Tönen von manchen könnte man meinen es währen kleine grüne Rumpelstilzchen die in der Arbeit nix zu sagen hat und von der Frau erst mal eine gefeuert bekommt wenn er den Müll ned rausbringt. Aber im Forum dicke Backen machen. Immer der selbe Käs. Egal ob es um Hausbus, Platinenfräßen, Radios, HomeSPS geht. Zerdiskutiert doch nicht immer alles, und einigt euch halt auch mal und legt einfach los. Bei der Frage ob eine Lösung 75%ig oder 90%ig sein soll, is es immer noch besser die 75%ige Lösung zu nehmen anstatt die 0%.
Sven H. schrieb: > Soll es denn dann einer mit EMC werden? Ich würde das für Vorteilhaft > halten. Man hat entweder die Möglichkeit externen Speicher anzubinden > oder man hat knapp 64 zusätzliche IO Pins ;-) Ich bin immer noch gegen ext. RAM. 64 I/Os brauchen wir nicht und wenn wir einen 200 pin IC nehmen werden alle die sowas noch nicht gelötet haben sich beschweren, acuh wenn es eigentlich kein Unterschied ist ob es 200 oder 100 sind.
Kai G. schrieb: > Das ist doch völlig egal. Arm7 ist der 8051 der "Zukunft". Naja als 8051 der Zukunft halt ich etwas übertrieben. Eher der Gegenwart. ;-) Sven H. schrieb: > Soll es denn dann einer mit EMC werden? Ich würde das für Vorteilhaft > halten. EMC? Du meinst EMV oder? Sven H. schrieb: > Wir benutzten hier in der Firma nen lpc2214 mit 2MB externem Flash und > > das läuft wunderbar... In welchen Einsatzgebiet nutzt ihr den?
@Tagg: Auch wenn Du hier anonym rumstänkerst... ...recht hast Du! ...ich seh mich auch schon fast alleine basteln...
Pezi schrieb: > Der Cortex M3 ist eigentlich als potentieller Nachfolger vom ARM7-Kern > gedacht. Aus diesem Blickwinkel stimme ich auch für den Cortex. ;-) Dann nehmen wir halt um himmels willen einen Cortex M3. Such einen raus, poste ihn und ich warte sicher keine 15 minuten ab bis jemand dagegen was einzuwenden hat. Auf wichtigere Sachen, z.B. die Architektur an sich (Blockdiagramm) geht keiner ein. Wir werden das Spiel noch ewig so weiter spielen bis wir im Endeffekt kein Radio haben weil alle einfach nur frustriert sind und keinen Bock mehr auf die Diskussionen & Streitereien haben.
Naja so schlimm find ich es nicht und in der Zeit hätten wir auch nie 2 Geräte fertig. ;-) Wir sind ja eh schon auf nem Guten weg, auch wenn er für manche etwas zäh wirkt. Tagg schrieb: > Bei der Frage ob eine Lösung 75%ig oder > > 90%ig sein soll, is es immer noch besser die 75%ige Lösung zu nehmen > > anstatt die 0%. Naja meiner Meinung nach ist ne 75%ig Lösung auch nicht das richtige, weil man am Schluß einfach nicht zufrieden ist.
Pezi schrieb: > Sven H. schrieb: >> Soll es denn dann einer mit EMC werden? Ich würde das für Vorteilhaft >> halten. Nein. EMC ist der External Memory Controller. Geeignet zum Anschluss externer Speicher oder parallel anzusteuernder Peripherie. Pezi schrieb: > Sven H. schrieb: >> Wir benutzten hier in der Firma nen lpc2214 mit 2MB externem Flash und >> >> das läuft wunderbar... > > In welchen Einsatzgebiet nutzt ihr den? Auf ner Steuerkarte für ein firmeninternes Prüfsystem für Automotiv Elektronik. Mehr darf ich wohl nicht erzählen. Ich würd gern noch was zum Blockdiagramm sagen, aber ich bin irgendwie zu doof, das im Wiki zu finden (zeigt auf mich und lacht)
Kai G. schrieb: > und wenn > wir einen 200 pin IC nehmen werden alle die sowas noch nicht gelötet > haben sich beschweren, acuh wenn es eigentlich kein Unterschied ist ob > es 200 oder 100 sind. Ich fürchte aber, von DIL werden wir uns verabschieden müssen ;-)
> Ich würd gern noch was zum Blockdiagramm sagen, aber ich bin irgendwie > zu doof, das im Wiki zu finden (zeigt auf mich und lacht) Ist hier im Forum (OK, schwer zu finden), oder halt auf der Startseite auf "Blockdiagram" klicken...
Sven H. schrieb: > Ich fürchte aber, von DIL werden wir uns verabschieden müssen ;-) Wie, wir nehmen keinen 68010 im 80 pin DIL-gehäuse?
> Naja so schlimm find ich es nicht und in der Zeit hätten wir auch nie 2 > Geräte fertig. ;-) Mit einem Monat Zeit und 15000 Zeilen Code (alternativ Entwicklungszeit Sheets) haben wir schon ganz andere Sachen gemacht. > Wir sind ja eh schon auf nem Guten weg, auch wenn er für manche etwas > zäh wirkt. Im Gegenteil... is seh das hier wirklich ein paar Leute zusammengetroffen sind die das wirklich reissen könnten. Aber der Thread wurde mit der "ich mach nur mit wenn x/y verwendet wird"-Seuche Infiziert. Auf die Art wurden hier im Forum schon hunderte von Projekten durch möchtegern-Profis abgewürgt. >> Bei der Frage ob eine Lösung 75%ig oder >> 90%ig sein soll, is es immer noch besser die 75%ige Lösung zu nehmen >> anstatt die 0%. > Naja meiner Meinung nach ist ne 75%ig Lösung auch nicht das richtige, > weil man am Schluß einfach nicht zufrieden ist. Es gibt logischerweise NoGo's. Aber inbesondere im Opensourche-Bereich machts nur sinn wenn man sich an der Masse orientiert damit man möglichst viele erreicht. Daraus ergibts sich schon aus der Logik das es immer Unzufriedene gibt. 100% werden nie erreicht. Was hilfts wenn zb. der Prozessor X ganz toll ist, aber nur 1-2 Personen den überhaupt bekommen. Oder wenn Assembler viel schneller ist... aber die meisten nur C können. Etc. Deswegen... einfach mal einen gemeinsamen Nenner finden... und wenn sich alles einig sind "Ja, so ist es machbar (evtl. nicht optimal, aber machbar)" einfach mal loslegen. Wenn man auf das "Ja, das ist jetzt alles Perfekt" wartet... wir man alt und grau. Zieldefinition => Funktionierendes Universelles Gerät, egal wie. Dafür gibts ja dann auch Projektverwaltung, Versionsverwaltung, Modulare Bauweise und saubere Schnittstellendoku. Mit solchen Hilfmittlen kann man dann auch mal einen Baustein wechseln (zb. Prozessor) oder Varianten entwickeln. Nochmal... ein Opensource-Projekt wird NIE perfekt.. insbesondere bei der Komplexität wie hier. Beispiel Display hier im Thread. Da würd ich versuchen die Ansteuerung/Schnittstelle/Aufbau einigermaßen variabel bzw. Modular zu gestalten weil sich schon abzeichnet das es evtl. mal Probleme geben könnte. Damit man im Notfall doch auf ein anderes Wechseln oder Alternativen entwicklen kann. Deswegen... dreht einfach ein paar Dikussionsrunden und legt einfach los. Parameter (Ziele) abstecken, Projektverwaltung aufsetzen und los geht. Agrrr.. ich wollts ned tun. Aber jetzt hab ich selber wieder ein haufen Zeilen Code verschwendet.
Kai G. schrieb: >> Ich würd gern noch was zum Blockdiagramm sagen, aber ich bin irgendwie >> zu doof, das im Wiki zu finden (zeigt auf mich und lacht) > > Ist hier im Forum (OK, schwer zu finden), oder halt auf der Startseite > auf "Blockdiagram" klicken... Hallo Kai, ich empfehle Dir, das Blockschaldbild auf eine breite vonwenoiger als 1024 Pixel zu verkleinern, denn das Bild ist so groß, das ich es nicht mal auf meinem "kleinen "1920x1200" anzeigen kann und scrollen muß. Sag mal, verwendest Du einen Samsung SyncMaster 305T ? So einen habe ich im Büro mit 2500*1900 Pixel Auflösung! Grüße Michelle
> Wie, wir nehmen keinen 68010 im 80 pin DIL-gehäuse?
Fuer die Leute hier nicht in Versuchung. Mich rief gestern noch ein
alter Freund an der bald umzieht und mir einen schwung alter C't Rechner
mit 68020 angeboten hat. Ich hab ihm gesagt in die Tonne mit dem Zeug.
:-)
Aber mal was ganz anderes. Kann man das ganze hier nicht irgendwie in
eine Mailingliste verlagern? Ich verliere auch langsam den Ueberblick
und man koennte das ganze nach Threads sortieren und auch mal etwas
nachlesen.
Meine Idee mit dem AC97 kann man wohl auch vergessen. Es gibt wohl
SuperH mit AC97 Anschluss, aber die arbeiten dann wohl eine Liga hoeher.
(zwei Kerne, 200Mhz) Daraus schliesse ich dann mal das dies bei einer
langsamen 130Mhz CPU zuviel des guten waere.
Olaf
Moin Michelle! > ich empfehle Dir, das Blockschaldbild auf eine breite vonwenoiger als > 1024 Pixel zu verkleinern, denn das Bild ist so groß, das ich es nicht > mal auf meinem "kleinen "1920x1200" anzeigen kann und scrollen muß. Hehe, ich dachte eher an inhaltliche Kommentare :-) > Sag mal, verwendest Du einen Samsung SyncMaster 305T ? > So einen habe ich im Büro mit 2500*1900 Pixel Auflösung! Nö <neidisch werd>, aber meine Auflösung groß genug um nicht zu scrollen.
ich hab mal dafür gesorgt, daß das Blockschaltbild im Wiki leichter aufzufinden ist. Harry
Harald L. schrieb: > ich hab mal dafür gesorgt, daß das Blockschaltbild im Wiki leichter > aufzufinden ist. ...aber die Sache mit dem resizen des PNG mußte nochmal üben. Jetztistallesunleserlich! Warum machste das Blockschaldbild nicht mit Scribus oder ähnlichen? Dann kannste exporieren wie Du willst, ohne das die Lesbarkeit der Schrift abnimmt. Grüße Michelle
@Kai Wie von Ulrich schon erwähnt irgendeinen STM32. Also zb das Topmodel STM32F103xx (72Mhz, 1MB Flash, 96KB RAM). Dann haben wir auch die Freiheit Nut/OS eingesetzt. Mfg Patrick
olaf schrieb: > Meine Idee mit dem AC97 kann man wohl auch vergessen. Es gibt wohl > SuperH mit AC97 Anschluss, aber die arbeiten dann wohl eine Liga hoeher. > (zwei Kerne, 200Mhz) Daraus schliesse ich dann mal das dies bei einer > langsamen 130Mhz CPU zuviel des guten waere. Die PXA vom Marvell können das auch. Dummerweise alles BGA.
michelle, naechstes mal mach ichs in eps... von hand gecoded :-) ooffice kann auch andere file formate...
seennoob schrieb: > @Kai > Wie von Ulrich schon erwähnt irgendeinen STM32. Also zb das Topmodel > STM32F103xx (72Mhz, 1MB Flash, 96KB RAM). Dann haben wir auch die > Freiheit Nut/OS eingesetzt. > > Mfg Patrick Beim STM32 wirste ein problem mit den Temperaturen im Auto haben... Ich bin an der Entwicklung einer "HighPower LiPoly SmartBatetrie" sowie einer "24V DC modular ATX PSU" und da ich nur kleine Stückzahlen SELBER hertelle, muß ich also zusehen woher ich die Microchips billig bekomme. Der STM32 ist eigentlich absolut genial, denn du kannst das eine Interfce entweder als CAN (Smartbatterie) der USB (ATX PSU) configurieren... Damit komme ich bei insgesammt 17 Produkten locker auf ein 2500 Stüch Tape-And-Reel und kriege die Chips für n'Appel und n'Ein... Hahaha, denkste, der Chip ist NICHT automotive tauglich und killt sich selber ab 80°C, was in der Console eines Autos OHNE Schwierigkeiten ereicht wird. Die Chips die in den Marken-Autoradios verbaut werden halten ALLESAMMT -40°C bis +125°C aus. Bitte unbedingt beachten! Grüße Michelle
Frage: Habt ihr bereits eine Mailingliste oder braucht ihr noch eine? Der mein Root-Server für "electronica@tdnet" steht in UK, hat ne schnelle Anbindung, dümpelt vor sich hin und die Liste-Software ist Courier-MLM. Grüße Michelle
Darin liegt das Problem beim Cortex M3 weil max -40 bis 105°C (Luminary) drin sind. @Michelle sowas wie einen OMAP3530 fertig mit RAM usw + 7" LCD + Touchscreen + USB Anschlüsse hast nich grad rein zufällig im Angebot ? MFG Patrick
Der SH7262 sieht -20 bis +85 in der normalen Ausfuehrung vor, und -40 bis +85 in der erweitereten Ausfuehrung. > Die Chips die in den Marken-Autoradios verbaut werden > halten ALLESAMMT -40°C bis +125°C aus. Bist du da sicher? Ich meine das gilt nur fuer Sachen die in den Motorraum kommen. Olaf
seennoob schrieb: > Darin liegt das Problem beim Cortex M3 weil max -40 bis 105°C (Luminary) > drin sind. Und den Cortex M0 (LPC11xx) gibt es NOCH nicht in der gewünschten Ausführung... Soll aber NOCH dieses Jahr geschehen. Klar, warum soll NXP was machen, was nicht von Kunden benötigt wird, aber nun ist es doch der Fall > @Michelle sowas wie einen OMAP3530 fertig mit RAM usw + 7" LCD + > Touchscreen + USB Anschlüsse hast nich grad rein zufällig im Angebot ? Also ich bin dabei, was mit eine Sitara AM3517 und OMAP 3530 für meine Elektro-Fahrzeuge zu bauen. Bedingung ist eben mindestens -40 bis +105°C aber besser +125°C (extended Automotive) Meine idee ist es, ein DIN Gehäuse mit einer "eierlegenden Wollmilchsau" zu bestücken und dann PCI-express connectoren (52polig nach hinten) einzubauen, aber anstatt PCI-Express (was die µC nich haben) werde ich die Connectoren selber belegen mit USB, I2S, I²C, SPI und Versogungsspannung von +12V, +5V und +3,3V. Die Front soll so gestalltet werden wie bei den Autoradios mit abnehmbarer Front, sprich, du kannst einbauen was du willst und wenn es sein muß eine CD-Rom Laufwerk, Card-Reader oder eine Festplatte Der Vorteil des Sitara/OMAP ist,d as Du das 24bit RGB interface (= 29 pins) nicht verwenden mußt, sondern den chip ind en "FlatLink3D" modus versetzen kannst, damit eben nur eine LVDS benötigst und die restlichen PINS für UART und I/O zur verfügung stehen... Nur ist der Sitara derzeit mein erster 500MHz µC und ich muß mich erst Stück für Stück einarbeiten... Sprich: Derzeit ist der "universellen AutoPC" noch ein Traum... Achja so ein Prototypen-PCB kostet mal schlappe 400 Euro... Grüße Michelle
Michelle Konzack schrieb: > Achja so ein Prototypen-PCB kostet mal schlappe 400 Euro... 2 Layer kostet in der Größe gerade mal knapp 20 Euro inkl. Versand nach Deutschland (in Einerstückzahlen!). Ja, ich war auch sehr überrascht. Die Variante im Blockschaltbild sollte in 2 Lagen zu machen sein.
Olaf schrieb: > Der SH7262 sieht -20 bis +85 in der normalen Ausfuehrung vor, > und -40 bis +85 in der erweitereten Ausfuehrung. > >> Die Chips die in den Marken-Autoradios verbaut werden >> halten ALLESAMMT -40°C bis +125°C aus. > > Bist du da sicher? Ich meine das gilt nur fuer Sachen die in den > Motorraum kommen. Genaugenommen sind es im Fahrzeug INNENRAUM -40°C bis +105°C (automotive) und im Motorraum +125°C (extended automotive) Habe leider die bittere Erfahrung mit dem EPSON S1D13781 (SPI-RGB Controller) machen müssen, welcher nicht als automotive existiert hat und ich habe ihn beim Testen hops gehen lassen... 17 Euro für den Eimer Nun habe ich bei Rutronik den S1D23781 in Automotive ausführung nachgeordert und alles funktioniert wie geplant... kostet gerde mal 1 Euro mehr Grüße Michelle
Aber nicht für nen VFBGA wie den Sitara AM3517! Da kommste um 6 Signal-Layer nicht herum Ehm bei welchem anbieter findeste Du 20 Euro? und bei welchen Stückzahlen? Für die "24V DC modular ATX PSU" benötige ich 145x105mm und die kostet bereits 60 Euro bei 35µ und 82 Euro bei 200µ Kupferauflage Grüße Michelle
Michelle Konzack schrieb: > Aber nicht für nen VFBGA wie den Sitara AM3517! > Da kommste um 6 Signal-Layer nicht herum Ja, und auch nicht mit LPC2888, AMD X4, ... Ich sprach ja von dem hier besprochenen Autoradio. > Ehm bei welchem anbieter findeste Du 20 Euro? und bei welchen > Stückzahlen? Bei ein Stück in Polen, mit Versand per DHL. Link kann ich Dir morgen schicken wenn es Dich interessiert.
seennoob schrieb: > @Kai > Wie von Ulrich schon erwähnt irgendeinen STM32. Also zb das Topmodel > STM32F103xx (72Mhz, 1MB Flash, 96KB RAM). Dann haben wir auch die > Freiheit Nut/OS eingesetzt. > > Mfg Patrick Patrick, das Nut/OS schafft es einen Atmega128 mit einer ISA-Karte zusammen in einen WEB-Server zu verwandeln. Der Footprint vom Nut/OS selbst ist nicht so sonderlich groß. Ich habe dem Nut/OS mal einen kompletten Funk-Stack verpasst (proprietäres Protokoll) mit Routing und Sensoren u.s.w. und es sind auf einem AT91SAM7X256 gerade mal 60k Code und 20k RAM, wobei die Protokolle und die Sensorik davon das meiste Fressen. Im Flash liegt aber auch noch ein kompletter Zeichensatz für ein OLED. Das Nut/OS ist auch konfigurierbar, wenn Du kein Netzwerk willst, dann klammer die entsprechende Library aus.
Ulrich P. schrieb: > Das Nut/OS ist auch konfigurierbar, wenn Du kein Netzwerk willst, dann > klammer die entsprechende Library aus. Wenn man nur den Task-Scheduler baucht, geht das auf nem kleinen ATmega unter 4k....habs getestet. Harry
Harry, da ich ein Fan von effektiver Programmierung bin, glaube ich Dir das unbesehen!
Also nachdem ich den gesammten Beitrag nochmal überflogen habe,würde ich
sagen, das das gesammte project besser wegkommt, wenn es gesplitted wird
in:
1) Car DIN-Gehäuse mit ARM9 oder Cortex A8 basierenden CarPC
a) extener Speicher mit Speichergröße auf wunsch
b) 24bit LVDS contoller mit unterstützung für UART, I²S und SPI
c) CAN Controller
d) 4-5 Erweiterungsslots basierend auf Mini-PCI-express connector
mit USB, SPI, I²C, I²S und eventuell AC97
(die habe ich in der "SAMMELBESTELLUN MoreThanAll" drin)
2) Frontpanel
3) Module für Radio
4) Module für Wifi
5) Module für HiFi Endstufe
6) - nnnn) Module für irgendwas
Damit könte das GESAMMTE Project eine nahezu unbescreibbare
Modulatität erreichen. Das ist eben das, was ich mehr oder weniger
professionell mit meiner Firma bauen will, denn ich denke, einen
Leistungsfähigen 720MHz ARM Controller mit bis zu 1 GByte DDR2 Speicher
hat einen absolut universellen einsatz.
Mein problem ist nur, das ich das ganze ALLEINE mache und es dem
entsprechend Zeit und Geld frißt, denn ich muß ja alle Komponenten
einzeln testen.
Grüße
Michelle
@Michelle Dies soll kein CarPC mit Radio-Modul werden, sondern nur ein Radio, welches man auch an einen CarPC anbinden kann, wenn man es denn möchte. In Deinen Post also Modul 2,3 und 5.
OK dann wollen wir mal: AVR32: alle gewünschter Features aber nur -40..+85°C trotz 'automotive' LPC175x: M3, fast alles drin, kann auf die schnelle kein I2S finden. Aber 125°C LPC236x: ARM7, alles drinn inkl. I2S, ethernet, USB/OTG und 125°C Wenn ich mir einen Kandidaten aus der Liste wünschen darf, dann den LPC2368. Man muss bei dieser Aufstellung aber sagen, dass NXP die max. Storage Temp. mit +125°C angibt, aber keine max. operating Temp. Atmel deklariert seine Chips auch als Automotive, gibt eine Storage-Temp von 125°C an, ist aber ehrlich genug die Operting Temp mit 85°C anzugeben. Bei Radios geben z.B. CD/DVD Drives ab +65°C schon einen Alarm und ab 68..70°C schalten sie ab. Es reicht ja, dass die CPU durch die hohe Temperatur nicht zerstört wird. Laufen muss sie bei diesen Temperaturen nicht mehr unbedingt. Gruß, Ulrich
ich zitier mal aus unserem Wiki: "Als Hardware sollen nur Komponenten verwendet werden, die ohne den Abschluss eines NDA verfügbar, und vollständig dokumentiert sind. Wenn möglich, sollen keine schwer, und/oder nur mit speziellem Gerät, lötbaren Bauteile eingesetzt werden (zum Beispiel BGA)." http://osar.it-livetalk.de/ Langsam gewinn ich den Eindruck, daß so ein Wiki doch zu fortschrittlich für die reine "Lötkolben-Fraktion" ist ggg Der Kai und ich sind die Einzigen, die dort auch mal Ideen festhalten.... Harry
Ulrich P. schrieb: > Es reicht ja, dass die CPU durch die hohe Temperatur nicht zerstört > wird. Laufen muss sie bei diesen Temperaturen nicht mehr unbedingt. FULL ACK Harry
Nochmal zur Temperatur: Sämtliche CAR-tuner die ich so auf die schnelle gefunden haben sind für einen Temperaturbereich von -40 bis +85°C spezifiziert (LAgertemperaturbereich -40 - 150 °C) Es würd mich wundern wenn der Mikrocontroller dann einen größeren Bereich unterstützen müßte. Ich würd rein aus Interesse also gerne noch nen Temperatursensor vorsehen. Kann ja ein einfacher DS18?20 sein den nur die bestücken die meinen es zu brauchen.
Kai G. schrieb: > Ich würd rein aus Interesse also gerne noch nen Temperatursensor > vorsehen. Kann ja ein einfacher DS18?20 sein den nur die bestücken die > meinen es zu brauchen. Sehr gute Idee!!! ...und wer trägt das jetzt ins Wiki ein? :-D Harry
Harald L. schrieb: > Langsam gewinn ich den Eindruck, daß so ein Wiki doch zu fortschrittlich > für die reine "Lötkolben-Fraktion" ist *ggg* Jaja, der ewige Streit zwischen Hard- und Softwareleuten. Die HArdwareleute können halt mit so neumodischen Kram nichts anfangen... Ups, ich hasse eigentlich diese blöde Unterscheidung zw. HW und SW Leuten, weil ich mich zu beiden zähle :-)
Harald L. schrieb: >> Ich würd rein aus Interesse also gerne noch nen Temperatursensor >> vorsehen. Kann ja ein einfacher DS18?20 sein den nur die bestücken die >> meinen es zu brauchen. > Sehr gute Idee!!! > ...und wer trägt das jetzt ins Wiki ein? :-D Steht natürlich schon läääääännngst drin :-)
Kai G. schrieb: > Kann ja ein einfacher DS18?20 sein den nur die bestücken die > meinen es zu brauchen. Und wer prüft die dort gemessene Temperatur und schaltet bei Überhöhung den Prozessor, die Tuner und den Rest ab? Das sollte doch eher eine diskrete Schaltung sein und nicht der Prozessor selber. Also kein DS18?20, sondern ein Siliziumsensor mit OP-Amp. Ggf auch ein Betauungssensor für feuchte Autos (meins zum Beispiel). Läuft das Radio gerade und die Temperatur steigt über 70°, so gibt es eine Warnmeldung ("Achtung, ich schalte gleich ab"). Über 80° wird dann abgeschaltet. Einschalten ist nur unter 65° möglich. Ähnliches gilt auch für die Feuchtigkeit. Diese Sicherheitsschaltung muss die Temperatur natürlich meistern können. PS: Habe ich mal so im Wiki vermerkt: http://osar.it-livetalk.de/index.php/Mainboard#Temperatur
Christian H. schrieb: >> Kann ja ein einfacher DS18?20 sein den nur die bestücken die >> meinen es zu brauchen. > Und wer prüft die dort gemessene Temperatur und schaltet bei Überhöhung > den Prozessor, die Tuner und den Rest ab? Es ging mir nicht um eine Sicherheitsschaltung, sondern nur um eine reine Temperaturmessung mit Anzeigemöglichkeit. > Das sollte doch eher eine diskrete Schaltung sein und nicht der > Prozessor selber. Also kein DS18?20, sondern ein Siliziumsensor mit > OP-Amp. Ggf auch ein Betauungssensor für feuchte Autos (meins zum > Beispiel). Ich wollte keine Klimaanlagenregelung bauen :-) Für eine echte Sicherheitsschaltung reicht auch ein NTC + Transistor, die bekommt man leichter für hohe Temperaturen als OPAMPs. Warum soll es gerade am Radio kondensieren? Das Radio an sich wird nicht keine Wahnsinns abwärme entwickeln, bzw. bis die Endstufen heiß werden muss das Radio schon eine ganze zeit an sein (Bei class-D Endstufen), sodass die Umgebung auch schon angewärmt ist und das Radio sicher nicht schneller abkühlt als die Umgebung.
Da gibt es doch kleine T-Sensoren, die man via I2C oder 1Wire programmieren und auslesen kann. Die haben einen oder zwei Ausgänge, die mit programmierbarer Hysterese autark schalten. Außerdem ist das Problem nicht nur die aufgrund der exponierten Stelle eingebrachten Wärme, sondern auch die selbst erzeugte. Wenn die CPU rechtzeitig die AMPS und einiges an der Peripherie abschaltet, wird schon mal ein Teil der selbst erzeugten Wärmelast eingedämmt.
Kai G. schrieb: > Michelle Konzack schrieb: >> Achja so ein Prototypen-PCB kostet mal schlappe 400 Euro... > > 2 Layer kostet in der Größe gerade mal knapp 20 Euro inkl. Versand nach > Deutschland (in Einerstückzahlen!). Ja, ich war auch sehr überrascht. > Die Variante im Blockschaltbild sollte in 2 Lagen zu machen sein. Ist jetzt zwar offtopic, aber WO?
Nach eingehendem Studium der Projektseite sind mir noch ein paar Sachen aufgefallen. Der VLSI ist immer noch als MP3-Modul gelistet. Kai, waren wir nicht überein gekommen, dass der kleine Kerl auf jeden Fall Platz auf dem Mainboard hat? Dann sehe ich, dass CAN optional gelistet ist. Ist sicherlich nichts, das am ersten Tag laufen muss, würde es aber erleichtern vorhandene Lenkrad-Fernbedienungen und externe Displays zu nutzen. Eine andere verbreitet Schaltung für eine LFB ist ein Widerstandsteiler. Ein einfacher 8-Bit ADC reicht dafür aus, bzw. einer meist ohnehin in den CPUs vorhandenen 10..12Bit ADCs. Optional wäre für mich ein 2.CAN, der entweder den 2. vorhandenen CAN vom PKW abgreift um die Geschwindigkeit für eine Leutstärkeanpassung abzugreifen, wenn das Speed-Signal nicht am ISO-Stecker anliegt.
Sven H. schrieb: > Ist jetzt zwar offtopic, aber WO? Muss ich morgen nachgucken, hab ich nicht auf dem rechner, wird definitiv nachgereicht! Die Firma hatte auch einen onlinekalulator...
Da fehlt noch das 'oder' für den 2. CAN Bus. Der Oder sollte lauten, dass es ein optionales zweites System für die Rückbank fernbedienen kann.
Ulrich P. schrieb: > Der VLSI ist immer noch als MP3-Modul gelistet. Kai, waren wir nicht > überein gekommen, dass der kleine Kerl auf jeden Fall Platz auf dem > Mainboard hat? Stimmt, können wir von mir aus noch gerne aufs mainboard ziehen. Es gilt mal wieder: wer ihn nicht haben will, bestückt ihn nicht... > Dann sehe ich, dass CAN optional gelistet ist. Echt? CAN hatte ich eigentlich auch schon fürs Minimalsystem vorgesehen. Möchte meine PDC gerne drin haben, bzw. das Blinker-klacken kommt GLAUBE ICH auch aus dem Radio (kann das sein??), wenigstens klingt es so und wenn sich z.B. mein Telefon an der Auto-Freisprecheinrichtung anmeldet ist das Blinkgeräusch nicht zu hören. > Ein > einfacher 8-Bit ADC reicht dafür aus, bzw. einer meist ohnehin in den > CPUs vorhandenen 10..12Bit ADCs. Ja, ADC hatte ich schon vorgesehen, allerdings erstmal nur für "GALA" und Brightness. Einen weiteren dazuzupacken kostet ja nichts. > Optional wäre für mich ein 2.CAN, der entweder den 2. vorhandenen CAN > vom PKW abgreift um die Geschwindigkeit für eine Leutstärkeanpassung > abzugreifen, wenn das Speed-Signal nicht am ISO-Stecker anliegt. Muss man echt mit 2 CAN-Bussen reden können?
Kai G. schrieb: > Ulrich P. schrieb: >> Der VLSI ist immer noch als MP3-Modul gelistet. Kai, waren wir nicht >> überein gekommen, dass der kleine Kerl auf jeden Fall Platz auf dem >> Mainboard hat? > > Stimmt, können wir von mir aus noch gerne aufs mainboard ziehen. Es gilt > mal wieder: wer ihn nicht haben will, bestückt ihn nicht... ..aber, genau darum soll er doch auf das Multimediaboard! Wer Linux benutzt, setzt da eben ein anderes Board drauf, und man erspart sich einiges an Umschaltlogik auf dem Mainboard....und jetzt kommt mir nicht mit Platinenkosten für die zu erwartenden max 100cm² für das Multimedia-Light-Board! (geht vermutlich sogar einseitig, weil ausser dem VLSI da ja fast nix drauf ist) Harry
Harald L. schrieb: > und man erspart sich > einiges an Umschaltlogik auf dem Mainboard.... um das noch mal kurz zu erklären: wer ein "grosses" CPU-Board auf den Multimediaslot steckt "ersetzt" den vorhandenen Decoder!!! Da muss nix umgeschaltet werden o.ä. Und darin liegt für mich der Reiz, den auf solch ein Light-Board zu packen statt des Mainboards. (vom platz her würde er locker passen) Harry
Hmm, da hatte ich Kai anders verstanden. Aber wundern tut mich dieses Hin und Her nun auch nicht mehr :) Welche CPU nehmen wir denn jetzt? AVR32UC3A0512 oder LPC2368? Oder ( und das ist jetzt nicht wirklich ein Scherz) setzen wir die auch auf eine Kachel? Wenn man das Layout passend zu einem gefälligen Linux-Modul macht, dann gibt es eigentlich für keine der Fraktionen mehr ein Problem. Nachdem das Temperaturproblem geklärt ist, spricht doch nix mehr gegen den AVR32 und auch die Toolchain ist komplett wie beim LPC, aber Nut/OS ist bereits sehr weit bei diesem Chip. Oder machen wir eine Strichliste ins Wiki und wir stimmen über eine der beiden CPUs ab?
Ulrich P. schrieb: > Welche CPU nehmen wir denn jetzt? Bitte nicht wieder die C-Frage!!!! dann drehen wir uns wirklich im Kreis!!! Es geht darum, welches ARM7-Derivat am geeignetsten ist! Harry
Harald, das Austauschen löst das Problem nicht vollständig. Es sind ja auch verschiedene Kombinationen denkbar. Es wird also eher darauf hinauslaufen, dass das Mainboard eher ein Bus-Board + AMPs und DC/DC wird. Alles andere wird dann aufgesteckt. Ob man das als kacheln macht mit jeweils zwei klipsenden verbindern an den langen oder schmalen Seiten, oder stehend ist ein rein mechanisches Problem. Stehend würde Halterungen erfordern, erlaubt es aber mehr Module unter zu bringen. Liegend nimmt mehr Platz weg, lässt aber darüber Raum für Drives / SSDs oder Notebook Platten. Flach zu stapeln hätte auch etwas, wenn das darum geht eine weitere, sehr flache Unit hinten unter zu bringen für die Font Gäste.
> Der Kai und ich sind die Einzigen, die dort auch mal Ideen > festhalten.... Richtig. Das liegt daran das ich das Wikigedoens fuer Quatsch halte. Oder moechtest du das ich da hingehe und es nach meinen Wuenschen zurechtbiege und es dann als Beleg fuer meine Meinung selber zitiere? > Ich würd rein aus Interesse also gerne noch nen Temperatursensor > vorsehen. Aeh..das habe ich als selbstverstaendlich angesehen. Aber wie gesagt ich laber nicht in so einen Wikizeugs rum. Wenn schon dann Mailinglist, die gate ich dann in meinen newsserver und dann hab ich einen vernuenftigen Zugriff auf Informationen. > Kann ja ein einfacher DS18?20 sein den nur die bestücken die > meinen es zu brauchen. Bist du von allen guten Geistern verlassen? 1-Wire Protokoll ist das letzte! Es ist Timingabhaengig und du hast es in keinen Controller eingbaut. Darfst also dafuer extra was mit einem Timer auf hohen IRQ-Level zaubern. (BTW: Koennen ARMs eigentlich IRQ-Level oder sind die genauso strunzdoof wie AVRs?) Der DS1820 hat nur einen einzigen Vorteil der ihn am Leben haelt, er ist ohne Abgleich erstaunlich genau. Aber fuer das innere eines Radio reichen +/-2Grad aus. Als Sensor nimmt man soetwas wie einen LM75, oder falls das Gehaeuse zu gross ist etwas kleines von Maxim. Aber jedenfalls mit I2C-Bus. Da kann man dann alle paar Sekunden mal die Temperatur auslesen und pruefen ob die Enstufen gerade abdampfen. :) Ausserdem wird man wohl mindestens zwei Sensoren brauchen. Einen in der Naehe der Endstufen aus Sicherheitsgruenden und einen in der Naehe des LCDs zur Kontrastregelung. > Ähnliches gilt auch für die Feuchtigkeit. DAs ist quatsch. Wenn du Goldfische in deinem Auto hast dann solltest du es erstmal reparieren. Ein Feuchtigkeitsensor hat nur Sinn gemacht bei Geraeten die darauf sehr sensibel reagiert haben. Also zum Beispiel DATs. Olaf
Olaf schrieb: > Richtig. Das liegt daran das ich das Wikigedoens fuer Quatsch halte. > Oder moechtest du das ich da hingehe und es nach meinen Wuenschen > zurechtbiege und es dann als Beleg fuer meine Meinung selber zitiere? Ist es quatsch Ideen festzuhalten. Man muss ja nicht alles von den Vorgängern löschen/über den Haufen schmeissen. > Bist du von allen guten Geistern verlassen? 1-Wire Protokoll ist das > letzte! Es ist Timingabhaengig und du hast es in keinen Controller > eingbaut. Ich programmier 1-wire nicht zum ersten mal in einem controller. Besonders toll find ich es auch nicht, aber ich komm nicht von los... > (BTW: Koennen ARMs eigentlich IRQ-Level oder sind die > genauso strunzdoof wie AVRs?) Nein, ein ARM ist kein AVR, auch wenn es beides mit einem A anfängt und 3 Buchstaben hat :-) Vectored interrupt controller, prioritäten, nested interrupts, "fast" und "normalen" interrupt, ... > Als Sensor nimmt man soetwas wie einen LM75, oder falls das Gehaeuse zu > gross ist etwas kleines von Maxim. Aber jedenfalls mit I2C-Bus. Da kann > man dann alle paar Sekunden mal die Temperatur auslesen und pruefen ob > die Enstufen gerade abdampfen. :) OK, dann halt nen LM75. Für eine Sicherheitsschaltung (die ich nicht echt für nötig halte) wäre ich aber auch für einen NTC + Transistorbeschaltung und nichts "intelligentes". > Ausserdem wird man wohl mindestens zwei Sensoren brauchen. Einen in der > Naehe der Endstufen aus Sicherheitsgruenden und einen in der Naehe des > LCDs zur Kontrastregelung. Die Endstufen die ich mir so angeschaut habe haben auch I2c busse und geben darüber Statusinformationen zurück (Kurzschluss, ...). Einen extra Sensor brauchen die nicht.
Olaf schrieb: >> Der Kai und ich sind die Einzigen, die dort auch mal Ideen >> festhalten.... > > Richtig. Das liegt daran das ich das Wikigedoens fuer Quatsch halte. > Oder moechtest du das ich da hingehe und es nach meinen Wuenschen > zurechtbiege und es dann als Beleg fuer meine Meinung selber zitiere? Sorry Olaf, aber so langsam verlier ich jegliches Verständnis für deine Haltung! Es geht nicht um „zurechtbiegen“, sondern darum, seine Ideen und Wünsche mit einzubringen. Alles, was im Wiki steht, hat potentiell die Chance verwirklicht zu werden – Alles, was nicht drin steht, wird auch nicht verwirklicht! Ich fass das mal zusammen: Du willst die modernste Hardware verwenden, aber mistraust allem, was nach Betriebssystem riecht, und möchtest alles selber machen. Du hällst eine Mailinglist für geeigneter, um Informationen zusammenzutragen, als ein Wiki wie soll ich sagen?....“Willkommen in der 90er!“? Harry
> Ich programmier 1-wire nicht zum ersten mal in einem controller. > Besonders toll find ich es auch nicht, aber ich komm nicht von los... Ich habe den DS1820 auch in einer Anwendung laufen. Wenn man die Genauigkeit braucht und die Gehaeuseform wichtig ist, dann ist das okay. Ich wuesste jetzt keinen anderen Sensor der absolut auf 0.25Grad genau ist und relativ 1/10 (neue) Version, oder gar 1/100Grad (alte Version) kann. Aber warum willst du dir den antun wenn du sowieso schon I2C nutzen willst? Da ist doch ein LM75 einfach mit an den Bus geklemmt und er wird sofort funktionieren. > Für eine Sicherheitsschaltung (die ich nicht > echt für nötig halte) wäre ich aber auch für einen NTC + > Transistorbeschaltung und nichts "intelligentes". Ich halte die Sicherheitsschaltung auch nicht fuer SOOO wichtig. Genauer gesagt wuerde es IMHO reichen wenn das per Software gemacht wird. Andererseits gibt es Sensoren die haben dafuer extra einen Ausgang und eine EEPROM Zelle um die Grenzwerte einzuprogrammieren. Ich glaube das Teil von Maxim war sogar LM75 kompatibel. Will ich jetzt aber nicht beschwoeren. > Die Endstufen die ich mir so angeschaut habe haben auch I2c busse und > geben darüber Statusinformationen zurück (Kurzschluss, ...). Was du alles fuer Endstufen kennst. :-o Ich geb zu das letzte mal das ich eine Endstufe fuers Auto gebaut habe da war das was mit TDA2030 und externem Booster. Muss sich wohl in den letzten 20Jahren was getan haben.... Olaf
Olaf schrieb: > Ich wuesste jetzt keinen anderen Sensor der absolut auf 0.25Grad genau > ist und relativ 1/10 (neue) Version, oder gar 1/100Grad (alte Version) > kann. Die neue kann auch relativ mehr als 1/10, man muss nur etwas rechnen. Ist im Datenblatt beschrieben. > Aber warum willst du dir den antun wenn du sowieso schon I2C nutzen > willst? Da ist doch ein LM75 einfach mit an den Bus geklemmt und er wird > sofort funktionieren. Ja, ist schon einfacher. Der DS18?20 kommt mir halt immer als erstes in den Sinn wenn ich an temperatur denke. Für mein letzte Projekt wo die drinsassen brauchte ich aber auch echt die Genauigkeit (Selbstgebauter Wärmetauscher für Lüftungsanlage). > Was du alles fuer Endstufen kennst. :-o > Ich geb zu das letzte mal das ich eine Endstufe fuers Auto gebaut habe > da war das was mit TDA2030 und externem Booster. Muss sich wohl in den > letzten 20Jahren was getan haben.... Sind halt Endstufen die für Autoradios gedacht sind und keine General purpose teile. Ulrich hatte mal eine vorgeschlagen die nicht schlecht ist (auch mit I2C). Gibt sogar Endstufen mit integrierten Spannungsreglern, sogar direkt mit den 8,5V die der Tuner braucht... Aber ob man die so einfach bekommt...
> Es geht nicht um „zurechtbiegen“, sondern darum, seine Ideen und Wünsche > mit einzubringen. Mir erscheint Wiki aber eine ziemlich primitive und ungeignete Diskussionsform. Es wuerde mir nicht gefallen wenn andere da einfach etwas aendern was ich eingetragen habe, und umgekehrt wuerde ich auch nichts von anderen Aendern weil ich das als unhoeflich ansehen wuerde. > Alles, was im Wiki steht, hat potentiell die Chance verwirklicht zu > werden – Alles, was nicht drin steht, wird auch nicht verwirklicht! Und das kann ich in keiner Weise nachvollziehen. Was hat eine Seite irgendwo im Internet mit einem Project zutun das man durchziehen will. Das ist doch absolut unerheblich. Ich hab das bestimmt seit einer Woche schon nicht mehr draufgekuckt. Und es wuerde mich auch echt abnerven den selben Text immer wieder und wieder lesen zu muessen bloss um zu erkennen wenn da mal wieder einer irgendwo einen Satz geaendert hat. > Du willst die modernste Hardware verwenden, aber mistraust allem, was > nach Betriebssystem riecht, und möchtest alles selber machen. Falsch, ich will eine Hardware verwenden die bei geringstmoeglichen Aufwand die notwendige Leistung erbringt und ich habe keine Angst vor Betriebsystemen, weshalb ich auch mal unter WinXP entwickeln kann, auch wenn ich sonst Linux nutze. > Du hällst eine Mailinglist für geeigneter, um Informationen > zusammenzutragen, als ein Wiki Selbstverstaendlich. Dann koennte man naemlich etwas nach Themen ordnen und nachvollziehen wie es entstanden ist. Und nebenbei Kai teilt meine Meinung. > wie soll ich sagen?....“Willkommen in der 90er!“? Nana, dann waer ich doch so ein ewig gestriger der unbedingt einen MCS51 im Autoradio haben wollte. Bloss weil etwas neu ist muss es nicht gleich gut sein! Olaf
Also ich werde mich dann mal langsam an die LPC2xxx Implementation für Nut/OS machen. Die beiden Nut/OS Ports von STM32 und LPC2xxx warten schon länger. Kai, ich lass Dir was vom Kuchen USB übrig :) Für LPC habe ich was hier, die STM32 müssen noch warten, bis ein DevKit da ist. Unabhängig davon werde ich mal ein paar Dinge im Nut/OS starten, die dem Projekt zu Gute kommen könnten. Also Encoder, IR-Remote, CAN u.s.w. Wie ich schon mal früher geschrieben habe, ist es egal, ob ich den OSCAR baue oder etwas ähnliches, wenn wir Nut/OS einsetzen, profitieren wir auch alle davon.
Olaf schrieb: > Mir erscheint Wiki aber eine ziemlich primitive und ungeignete > Diskussionsform. Es wuerde mir nicht gefallen wenn andere da einfach > etwas aendern was ich eingetragen habe, und umgekehrt wuerde ich auch > nichts von anderen Aendern weil ich das als unhoeflich ansehen wuerde. Das WIKI ist keine Diskussionsform. Es dient eigentlich mehr dazu Informationen zu sammeln, etwas zu strukturieren, ... In dem Forum, auch in einer schönen Mailingliste findet man halt einfach nicht in begrenzter Zeit die Informationen. Diskutiert wird woanders. Dieser Thread ist auf Dauer sicher nicht die geeignetste Variante.
Ulrich P. schrieb: > Also ich werde mich dann mal langsam an die LPC2xxx Implementation für > Nut/OS machen. Die beiden Nut/OS Ports von STM32 und LPC2xxx warten > schon länger. Kai, ich lass Dir was vom Kuchen USB übrig :) Oh, danke, da freu ich mich aber!! :-) Erlich, eine kleine und minimale USB Host-Implementation wollt ich immer schonmal machen! > Unabhängig davon werde ich mal ein paar Dinge im Nut/OS starten, die dem > Projekt zu Gute kommen könnten. Also Encoder, IR-Remote, CAN u.s.w. > Wie ich schon mal früher geschrieben habe, ist es egal, ob ich den OSCAR > baue oder etwas ähnliches, wenn wir Nut/OS einsetzen, profitieren wir > auch alle davon. Das klingt für mich sehr gut! Nur bitte an den wenigen Speicher denken :-)))
>Ich habe den Eindruck als wenn das Dingen nur in der Leistungsklasse >eines R32C spielt. Irgendwie kommt mir das zu mager vor. Der R32C hat ca die 1,4...2x Rechenleistung eines LPC23..! Der Flash des LPC23.. ist grottenschlecht! läuft mit 20MHz! (Den FlashAccelerator bringt in der Realität nicht viel, da bei realem Code alle ca 4..5 ASM Befehle DOCH ein Sprung-Befehl kommt. Und da geht der FlashAccelerator in "Leere", bzw sind dann etliche Wait-States erforderlich.) Die reale Rechenleistung eines LPC23.., wenn ausm Flash heraus ausgeführt, liegt also nur bei ca 20..35 MIPS, NICHT bei 72, wie im Datasheet angegeben! (NXP traut sich nichtmal die wahre Flash-Geschwindigkeit im Datasheet anzugeben)
Letztendlich hat Jede CPU ihre ganz persönlichen Probleme. Ich denke aber, dass wenn ich Nut/OS für eine CPU portiert habe, eine weitere sicherlich schneller geht. Solange Ihr nicht mit Microchip kommt, mache ich alles mit :) Wegen dem Speicher mache ich mir keine Sorgen. Wie gesagt, die minimalistischste Nut/OS Implementation liegt irgendwo unter 2kByte. So, und nun gute Nacht :)
MCUA schrieb: >>Ich habe den Eindruck als wenn das Dingen nur in der Leistungsklasse >>eines R32C spielt. Irgendwie kommt mir das zu mager vor. > Der R32C hat ca die 1,4...2x Rechenleistung eines LPC23..! > Der Flash des LPC23.. ist grottenschlecht! läuft mit 20MHz! Allerdings bei 128 Bit Bus-breite mit puffer. Und das meiste ist doch linearer code. Wo hast Du das mit den 20 MHz her (glaub ich Dir, aber hab ich noch nie irgendwo gesehen). Wie das Buffering echt klappt ist auch nicht echt erwähnt. Aber wenn es etwas cache artiges ist, kann es doch eigentlich nicht so schlecht sein, selbst bei code mit rel. vielen sprungbefehlen. Im worst-case kann es natürlich auch sein das der erwähnte puffer natürlich nur 128 bit groß ist :-) > (Den FlashAccelerator bringt in der Realität nicht viel, da bei realem > Code alle ca 4..5 ASM Befehle DOCH ein Sprung-Befehl kommt. Das ist das schöne bei ARM, das verdammt oft ein Sprung durch die bedingte Ausführung verhindert werden kann. Wenigstens wenn ich so in meine LIST files sehe. Alle 4-5 ASM Befehle kann passieren, aber halt ich doch für ewas übertrieben :-)
> So, und nun gute Nacht :) Ohayou gozaimasu :) > Wegen dem Speicher mache ich mir keine Sorgen. Wie gesagt, die > minimalistischste Nut/OS Implementation liegt irgendwo unter 2kByte. Nach welchen Kriterien werden da die Prioritaeten fuer einzelne Tasks verteilt? Kann man sicherstellen das bestimmte Dinge immer drankommen wenn es wichtig ist? Wie wird das in C implementiert? Das letztemal das ich etwas mit Multitasking gemacht habe, war das in Pearl unter RTOS/UH. Da konnte man bei den einzelnen Funktionen die Prioritaet angeben. Laeuft das dann in C mit Pragmas? Nebenbei, es gibt fuer den SuperH bereits ein Multitasker der besonder auf Echtzeit fuer Audiokram und Multimedia ausgelegt ist. (Kai: Hast du bereits auf deiner Platte, schau mal in das Verzeichnis wo der gcc-compiler ist) Nebenbei2: Es gibt fuer den SuperH auch einen gdb und einen stub. Allerdings habe ich mir nicht die Muehe gemacht das selber alles auszuprobieren. > Letztendlich hat Jede CPU ihre ganz persönlichen Probleme. Naja, aber eine 20Mhz CPU fuer soetwas ist doch krank. Besonders wenn keine Not besteht und was richtiges billig verfuegbar ist. Ich fahr doch auch nicht mit einem Kaefer auf die Rennstrecke wenn ich eine 1000RX in der Garage habe. :-D Noch eine weitere Sache die mich erstaunt. Auf der Seite fuer den Arm stand 16/32Bit Prozessor. Ist das dann garkein echter 32Bit? Olaf
> Ohayou gozaimasu :) Goede morgen wereld en meneer Olaf ;-) > Nach welchen Kriterien werden da die Prioritaeten fuer einzelne Tasks > verteilt? Kann man sicherstellen das bestimmte Dinge immer drankommen > wenn es wichtig ist? Wie wird das in C implementiert? Das letztemal das > ich etwas mit Multitasking gemacht habe, war das in Pearl unter RTOS/UH. > Da konnte man bei den einzelnen Funktionen die Prioritaet angeben. Ich kenn NUT/OS jetzt nicht im Detail, aber ein Betriebssystem hält einen nicht zwangsweise davon ab "klassisch" zu programmieren wo es nötig ist, d.H. mal einen HW-interrupt mit hoher prio zu benutzen oder so. > Naja, aber eine 20Mhz CPU fuer soetwas ist doch krank. Besonders wenn > keine Not besteht und was richtiges billig verfuegbar ist. Ich fahr doch > auch nicht mit einem Kaefer auf die Rennstrecke wenn ich eine 1000RX in > der Garage habe. :-D Die CPU läuft ja nicht mit 20 MHz, sondern (scheinbar) der Flash. Da aber pro 20 MHz Takt 128 bit gelesen werden können und danach ein puffer sitzt........ Nun gut, eine reine RAM basierte architektur ist da natürlich vom prinzip her schon schneller. > Noch eine weitere Sache die mich erstaunt. Auf der Seite fuer den Arm > stand 16/32Bit Prozessor. Ist das dann garkein echter 32Bit? Doch, man kann aber zwischen 2 Befehlssätzen wählen, Arm thumb (kmopakter und angeblich je nach Aufgabe auch etw. schneller) und den nativen ARM Befehlssatz (32 bit).
Olaf schrieb: > Nach welchen Kriterien werden da die Prioritaeten fuer einzelne Tasks > verteilt? Kann man sicherstellen das bestimmte Dinge immer drankommen > wenn es wichtig ist? Wie wird das in C implementiert? Das letztemal das > ich etwas mit Multitasking gemacht habe, war das in Pearl unter RTOS/UH. > Da konnte man bei den einzelnen Funktionen die Prioritaet angeben. > Laeuft das dann in C mit Pragmas? Also bei MQX ist es so, das D Threads erst mal initialisiere mußt und den frame in milisekundenangibst. Dan erstellst Du Deine Funktion und im Hauptprogramm rufste das ganze mit in main.h: #define TASK1 2 in main.c: void Task1(); TASK_TEMLATE_STRUCT MQX_template_list[] = { {MAIN_TASK, Main_task, 1500, 9, "main", MQX_Auto}, {TASK1, Task1, 1500, 10, "Task1", 0}, }; _task_create(0, TASK1, 0); void Task1() { ... } Also Du gibst zu Beispiel an, das ein Frame 5ms ist, dann kannste aber gewissen Tasks erst mal prioritäte zuweisen also in welcher reihenfolge abgearbeitet wird und dann noch MANUELL bei _task_create() die dauer des frame verändern. Ich denke, das es bei NUTOS nicht anderst sein wird... Unter 8051 geht es ganz genauso... allerdings habe ich den Scheduler vor gut 12 Jahren selber programiert und er ist auf 10 Tasks limitiert. Grüße Michelle
Hallo, ich verfolge den Thread jetzt schon ein ganze Weile. Ich habe mir mal das Blockschaltbild angesehen und hätte einen Vorschlag bezpülich des Frontpanels. Ich würde die Ansteuerung des LCD vom Frontpanel MC machen und nur eine Schnittstelle (UART, SPI) zwischen Frontpanel MC und Haupt µC machen. Zwischen Frontpanel MC und Haupt µC gibt es dann ein universelles Protokoll, der Frontpanel MC setzt dieses dann in die Befehle um, die das dann verbaute LCD benötigt. Damit ist die Frontplatte noch unabhängiger wenn z. B. ein anderes Display eingesetzt wird, da nur der Frontpannel MC neu programmiert werden muß. Außderdem ist man dann unabhängig, ob ein Display oder zwei Displays (wie angedacht) verwendet wird. Aus Sicht des Hauptprozessors gibt es nur ein Display. Gruß Ralf
KAIN_UND_ABEL schrieb: > ich verfolge den Thread jetzt schon ein ganze Weile. Ich > habe mir mal das Blockschaltbild angesehen und hätte einen > Vorschlag bezpülich des Frontpanels. Die letzten Überlegungen gingen sogar noch weiter: Eine API für das RADIO muss sowieso gemacht werden, damit der Linux-rechner das Ding fernbedienen kann. Warum also nicht auch das Frontpanel als "Master" einsetzen und das Menüsystem und co. dort auf einen µC laufen lassen? Etwas in der AtMega klasse sollte reichen da er nicht viel zu tun hat.
> Ich würde die Ansteuerung des LCD vom Frontpanel MC machen > und nur eine Schnittstelle (UART, SPI) zwischen Frontpanel > MC und Haupt µC machen. Zwischen Frontpanel MC und Haupt µC > gibt es dann ein universelles Protokoll, der Frontpanel MC > setzt dieses dann in die Befehle um, die das dann verbaute > LCD benötigt. Hm..das war eigentlich meine Ursprungsueberlegung bei der Sache. Ich wusste noch garnicht das es anders sein sollte. Nur so ist eine komplette Fernsteuerung der Basiseinheit moeglich. Es hat aber auch einen Nachteil. Wenn man durch die MP3 Liste durchscrollt muessen "relativ" viel Daten verschoben werden weil die SD-Karte sicherlich am Hauptprozessor haengen wird. Aber das sollte wohl zu schaffen sein. Ich wuerde empfehlen das ganze mit RS232 (logic, nicht unbedingt auch Pegel) und einem echten BUS-System zu machen. Also die Leitungen dazu auch bei den Steckplaetzen fuer Zusatzmodule vorbeifuehren. So koennte man von der Front auch recht ungewoehnliche Sachen mit ansteuern die man sich selber macht ohne das man etwas an dem sensibleren Hauptsystem aendern muss. Vor dem Hintergrund das jemand das ganze vielleicht aus der Entfernung, also z.b Linuxrechner unter dem Beifahrersitz, fernsteuern moechte, wuerde ich RS485 empfehlen. Pegelwandler vielleicht sowas wie ADM485 oder ahnliches. Olaf
Kai G. (xyphro) schrieb: > Etwas in der AtMega klasse sollte reichen da er nicht viel zu tun hat. Warum nicht auch einen ARM7 (einen kleineren aus der LPC Reihe). Der mag zwar etwas überdimmensioniert sein, hat aber den Vorteil, daß man nur eine Entwicklungsumgebung für das ganze Autoradio braucht. Olaf (Gast) schrieb: > Hm..das war eigentlich meine Ursprungsueberlegung bei der Sache. Ich > wusste noch garnicht das es anders sein sollte. Ich habe mir das Blockschaltbild angesehen, und dort es es halt anderst eingezeichnet. Gruß Ralf
Olaf schrieb: > Hm..das war eigentlich meine Ursprungsueberlegung bei der Sache. Ich > wusste noch garnicht das es anders sein sollte. Nur so ist eine > komplette Fernsteuerung der Basiseinheit moeglich. Na, das ist doch Prima! > Es hat aber auch einen Nachteil. Wenn man durch die MP3 Liste > durchscrollt muessen "relativ" viel Daten verschoben werden weil die > SD-Karte sicherlich am Hauptprozessor haengen wird. Aber das sollte wohl > zu schaffen sein. Klar, man muss sich ja nicht an standard Baudraten halten. > Ich wuerde empfehlen das ganze mit RS232 (logic, nicht unbedingt auch > Pegel) und einem echten BUS-System zu machen. Also die Leitungen dazu > auch bei den Steckplaetzen fuer Zusatzmodule vorbeifuehren. So koennte > man von der Front auch recht ungewoehnliche Sachen mit ansteuern die man > sich selber macht ohne das man etwas an dem sensibleren Hauptsystem > aendern muss. Klingt auf Anhieb nicht schlecht, wobei RS232 dann nicht unbedingt die beste Wahl ist. Muss mal etwas drüber nachdenken. Obwohl sämtliche µCs mehrere UARTS haben, man könnte also das untereinander kommunizieren nicht über den Physikalischen Layer realisieren sondern "weiter oben". Wobei wenn man mehrere Master hat muss man über eine Synchronisation nachdenken, aber dafür findet man eine Lösung. > Vor dem Hintergrund das jemand das ganze vielleicht aus der Entfernung, > also z.b Linuxrechner unter dem Beifahrersitz, fernsteuern moechte, > wuerde ich RS485 empfehlen. Pegelwandler vielleicht sowas wie ADM485 > oder ahnliches. Wenn man den "Bus" nach aussen legt kann man davor ja sowas schalten, also einfach RS232(TTL) nach RS485 wandler. Oder je nachdem was man sonst für einen bus hat...
KAIN_UND_ABEL schrieb: > Kai G. (xyphro) schrieb: > Warum nicht auch einen ARM7 (einen kleineren aus der LPC Reihe). Der > mag zwar etwas überdimmensioniert sein, hat aber den Vorteil, daß man > nur eine Entwicklungsumgebung für das ganze Autoradio braucht. Klar, ich wollt nur nicht schon wieder eine µC Diskussion beschwören :-) Wenn wir Senderlogos haben wollen brauchen wir eh recht viel flash >> Hm..das war eigentlich meine Ursprungsueberlegung bei der Sache. Ich >> wusste noch garnicht das es anders sein sollte. > Ich habe mir das Blockschaltbild angesehen, und dort es es halt > anderst eingezeichnet. Ja, ist noch nicht up to date weil wir da noch nicht explizit drüber gesprochen hatten..
Olaf schrieb: > Es hat aber auch einen Nachteil. Wenn man durch die MP3 Liste > durchscrollt muessen "relativ" viel Daten verschoben werden weil die > SD-Karte sicherlich am Hauptprozessor haengen wird. Aber das sollte wohl > zu schaffen sein. Das muss nur die API entsprechend anbieten (siehe Vinculum). Das Frontpanel ruft dann einen "ls" auf und bekommt die Liste (eventuell auch nur einen Teil dieser, da ja auch nur ein Teil angezeigt werden kann). Viele Daten müssten für die Darstellung eines Spektrums übermittelt werden: Möglichkeiten: * Das Panel holt sich diese Daten ab * Das Panel berechnes selber die Daten, benötigt aber auch Audio-Informationen. * Das Panel wird von der Car-PC-Einheit mit übernommen.
Kai G. schrieb: > Wenn man den "Bus" nach aussen legt kann man davor ja sowas schalten, > also einfach RS232(TTL) nach RS485 wandler. Oder je nachdem was man > sonst für einen bus hat... Als Bus wäre ein Multi-Master-Bus ideal. Dann könnte man sogar das normale Panel verwenden und gleichzeitig sein Laptop anschließen, der temporär als CarPC arbeitet und darüber das Radio steuert (zum Beispiel für Meldungen des Navigationssystems die Lautstärke des Radios herunter dreht). Auch für eine nachträgliche Konfiguration wäre das recht hilfreich.
Christian H. schrieb: > Viele Daten müssten für die Darstellung eines Spektrums übermittelt > werden: Wofür ein Spektrum? Damit das Display während der MP3 Wiedergabe flacker? Hmm, würde viel lieber eine liste mit Ordnuern/songs sehen als nervöses nichtssagendes zumgezappel.
Kai G. (xyphro) schrieb: > Ja, ist noch nicht up to date weil wir da noch nicht explizit drüber > gesprochen hatten.. Ich wollt halt nur mal von der lästigen "Welchen Mikrocontroller verwenden wir" Diskussion ablenken ;-). Außderdem haben sich ja manche schon zu recht beklagt, daß nur Diskutiert wird, und keine konkreten Vorschläge kommen. Standard RS 232, TTL Pegel würde ich auch nicht nehmen, da es wahrscheinlich zu langsam ist. Allerdings können manche Prozessoren auch höhere Baudraten fahren. Nur ein Vorschlag: Da so langsam die Schlüsselbauteile festgelegt sind, würde ich die Diskussion näher anhand des Blockschaltbildes weiterführen. Wenn dann die Schnittstellen und Aufgaben des jweiligen Blocks beschrieben und festgelegt sind, kann man ja immer noch den geeigneten Prozessor auswählen. Gruß Ralf
> Warum nicht auch einen ARM7 (einen kleineren aus der LPC Reihe). Der > mag zwar etwas überdimmensioniert sein, hat aber den Vorteil, daß man > nur eine Entwicklungsumgebung für das ganze Autoradio braucht. Hm...ich wollte einen M16C vorschlagen weil er die selbe Umgebung benutzen kann wie ein SuperH. Aber ich vermute das Thema ist derzeit etwas sensibel. > Klar, man muss sich ja nicht an standard Baudraten halten. Es waer aber schoener weil man dann mit einem PC alles mitloggen oder gar steuern koennte. > Wenn man den "Bus" nach aussen legt kann man davor ja sowas schalten, > also einfach RS232(TTL) nach RS485 wandler. Oder je nachdem was man > sonst für einen bus hat... Okay, geht natuerlich auch. Ich denke wohl normalweise zu industriell und nicht so billig Consumermaessig. :-) > Viele Daten müssten für die Darstellung eines Spektrums übermittelt > werden: Wir erinnern uns, einer der Gruende (zumindest fuer mich) ein Radio selber zubauen das man den kindischen Unsinn nicht mehr ertragen muss der heute ueberrall eingebaut wird. Absolut niemand braucht eine Darstellung eines Spektrum. > Da so langsam die Schlüsselbauteile festgelegt sind, Sie sind? Ich dachte das sollte noch ausdiskutiert werden. Olaf
KAIN_UND_ABEL schrieb: > Ich wollt halt nur mal von der lästigen "Welchen Mikrocontroller > verwenden wir" Diskussion ablenken ;-). > Außderdem haben sich ja manche schon zu recht beklagt, daß > nur Diskutiert wird, und keine konkreten Vorschläge kommen. Das ist sehr nett, danke :-) > Standard RS 232, TTL Pegel würde ich auch nicht nehmen, da > es wahrscheinlich zu langsam ist. Allerdings können manche > Prozessoren auch höhere Baudraten fahren. Klar. Im Moment seh ich nur an einer Stelle die Notwendigkeit für schnelle Übertragung und das ist um durchs (sortierte) directory zu scrollen. Wenn man mal von sagen wir mal 32 Bytes/Eintrag ausgeht und 8 werden gleichzeitig angezeigt und man will in 100ms ein update haben, dann wäre man bei 32*8*10 (wg. 100ms) = 2560 Bytes/s, d.h. 25600 Baud. Das ist sogar noch deutlich geringer als die 115.2 kbaud die ich sonst als höchste Standardbaudrate kenne. Sollte also passen und RS232 kann fast jedes Gerät (PC/µC). > Da so langsam die Schlüsselbauteile festgelegt sind, > würde ich die Diskussion näher anhand des Blockschaltbildes > weiterführen. Wenn dann die Schnittstellen und Aufgaben des > jweiligen Blocks beschrieben und festgelegt sind, kann man > ja immer noch den geeigneten Prozessor auswählen. Ahhh, er hat das P-wort gesagt :-) Aber das weiterdiskutieren macht evtl. mehr sinn in einer andern Form, mehrere Threads, mailingliste/Forum mit threaddarstellung, ... Ich glaube Harry arbeitet da gerade an was.
>> Klar, man muss sich ja nicht an standard Baudraten halten. > Es waer aber schoener weil man dann mit einem PC alles mitloggen oder > gar steuern koennte. Siehe grobe Abschätzung der Baudrate. 115.2 kbaud sollte vermutlich reichen. Aber USB-rs232 adapter können mittlerweile auch "nicht standard" Baudraten. >> Da so langsam die Schlüsselbauteile festgelegt sind, > Sie sind? Ich dachte das sollte noch ausdiskutiert werden. => siehe PM
KAIN_UND_ABEL schrieb: > Kai G. (xyphro) schrieb: >> Etwas in der AtMega klasse sollte reichen da er nicht viel zu tun hat. > > Warum nicht auch einen ARM7 (einen kleineren aus der LPC Reihe). Der > mag zwar etwas überdimmensioniert sein, hat aber den Vorteil, daß man > nur eine Entwicklungsumgebung für das ganze Autoradio braucht. Da würde ich eine Cortex M0 nehmen, denn die kosten unter 2 Euro. Ich habe vor ein paar Minuten eine E-Mail von EBV (meinem NXP Distributor) bekommen, das die gewünschten LPC11xx nun verfügbar sind... Preis 0,68 Euro/Stück bei 2500 auf Reel Grüße Michelle
Kai G. schrieb: > Klar, ich wollt nur nicht schon wieder eine µC Diskussion beschwören :-) Hehehe > Wenn wir Senderlogos haben wollen brauchen wir eh recht viel flash Ehm, speicherst Du die im Display teil? Also ich würde die im Hauptcomputer speichern und für das Frontpanel einen LPC1100 (Cortex M0) nehmen, denn der ist Hühnerfutter Grüze Michelle
>Allerdings bei 128 Bit Bus-breite mit puffer. Und das meiste ist doch >linearer code. Was heisst das "meiste" ? Wenn 75% das "meiste" sind und 25% eine Katastrophe sind, kommt unterm Strich bestenfalls mittelmässiges raus. >..aber hab ich noch nie irgendwo gesehen Jäh!! 1:0 für NXP... wegen Verschleierung (nicht wegen Leistung). Cache bringt genau so wenig wie FlashAccelerator, wenn gesprungen wird. Dann sinds etliche Wait-Cycle, egal welche Gimmicks im Prozessor sind. >Das ist das schöne bei ARM, das verdammt oft ein Sprung durch die >bedingte Ausführung verhindert werden kann. Das "schöne" bei ARM ist das Schlechte bei ARM, weil Flash zu langsam! Und Condition-Befehle bringen auch fast nichts, weil ja in diesem Fall die ganze Latte an Condition.-Befehlen abgearbeitet werden muss, was dann ebenfalls wieder etliche Takte braucht (weil man dann etliche Ausführungs- oder Sprung-Varianten in einen "String" von vielen Befehlsfolgen reinlegen muss, die wieder etliche Takte brauchen) >Alle 4-5 ASM Befehle kann passieren, aber halt ich doch für ewas >übertrieben :-) ist i.e. Realität. Es kann auch sein, dass es noch weniger sind. ---------------------- LangeRedeKurzerSinn: wenn Code aus Flash ausgeführt werden soll, dieses aber (wie hier) extrem langsam ist, wird's nix mit hoher Rechenleistung! (Da hilft nur schnellerer Flash, oder Ausführ. aus RAM heraus (falls RAM gross genug)) Aus diesem Grund versuchen viele Hersteller die schlechte Leistung des Flashs zu vertuschen. (bin mir sicher, dass dieser Vertuschung schon Etliche auf dem Leim gegangen sind)
Michelle Konzack schrieb: > Ehm, speicherst Du die im Display teil? Also ich würde die im > Hauptcomputer speichern und für das Frontpanel einen LPC1100 > (Cortex M0) nehmen, denn der ist Hühnerfutter Auch keine schlechte Idee. der main µC wird vermultich genug Flash haben, auuserdem man ja noch mit Farbtiefen/Palette/einfache RLE kompression (PCX) spielen. Also einfach einen Befehl in der API implementieren: "Hole Senderlogo / Bitmap"
Kai G. schrieb: > Wofür ein Spektrum? Damit das Display während der MP3 Wiedergabe > flacker? > Hmm, würde viel lieber eine liste mit Ordnuern/songs sehen als nervöses > nichtssagendes zumgezappel. Geht mir genauso. Ich hasse nervöses gezappel. Aber einige wollen sowas vielleicht haben und wie müssen es ihnen nicht verbauen. Also doch eher für solche Zwecke das Multimedia-Modul verwenden, welches dann auch das Display-Modul übernimmt.
MCUA schrieb: > Cache bringt genau so wenig wie FlashAccelerator, wenn gesprungen wird. > Dann sinds etliche Wait-Cycle, egal welche Gimmicks im Prozessor sind. Doch, wenn immer zu den selben funktionen gesprochen wird. >>Alle 4-5 ASM Befehle kann passieren, aber halt ich doch für ewas >>übertrieben :-) > ist i.e. Realität. Es kann auch sein, dass es noch weniger sind. GERADE DA wo es schnell sein soll wird aber nicht gesprungen (bei uns: MP3 decoding). Das ist eine der Basisoptimierungen für DSP Algorithmen die jeder macht und kennt... Wie auch immer. Selbst die Arm7 µC ist schnell genug. Das hat die Praxis schon bewiesen.
weiter oben war die Frage zu den steckern bei dem Autoradio. Sowas ist kein Problem sind an die Standards zu halten, bei den Steckern heisst das Zauberwort für Google "Fakra" für die HF Steckerverbinder (FM/AM, UMTS, WLan, .....) Und dann noch die restlichen Anschlüsse.. Kuckt Ihr zum Bleistift hier: http://www.roka-berlin.de/kfz-akast-gesamt.htm
... schrieb: > Kuckt Ihr zum Bleistift hier: > http://www.roka-berlin.de/kfz-akast-gesamt.htm Aussage der Firma am Telefon: "Wieviel 100000 Stück brauchen Sie denn". Also doch ein Problem. Naja, muss nochmal was nachschauen und zurückrufen, evtl. können wir dort doch etwas kaufen...
Also das ganze Thema ist sehr sehr lebhaft und mir scheint als könnte wirklich was daraus werden. Aber... dazu müste meiner Meinung nach so schnell wie möglich eine vernünftige Projektumgebung her. Zentrale Seite mit eigenem Forum, Wiki/CMS, Projektmanagent, Versionsmanagement, Bugtracker, etc. (oder was auch immer). Oder gibts das schon? Wenn OSS sein sollte währen gute Stichworte Trac, Mantis, svn, phpbb, etc. Die vorhandenen Systeme (sourceforge, Google Code) gefallen mir (noch) nicht wirklich. Zieldefinitonen, Verantwortliche und einfach loslegen. :) In diesem Thread stecken verdammt viele Informationen drin.. leider extrem unstrukturiert. Und das macht halt dann keinen Spass mitzuarbeiten. Subforen bräuchte man..
MCUA schrieb: > LangeRedeKurzerSinn: wenn Code aus Flash ausgeführt werden soll, dieses > aber (wie hier) extrem langsam ist, wird's nix mit hoher Rechenleistung! > (Da hilft nur schnellerer Flash, oder Ausführ. aus RAM heraus (falls RAM > gross genug)) Spricht das nicht schon wieder für externes RAM? Also beim Startup den Flashspeicher komplett raus kopieren und dann ausm exram laufen lassen?
Sven H. schrieb: >> LangeRedeKurzerSinn: wenn Code aus Flash ausgeführt werden soll, dieses >> aber (wie hier) extrem langsam ist, wird's nix mit hoher Rechenleistung! >> (Da hilft nur schnellerer Flash, oder Ausführ. aus RAM heraus (falls RAM >> gross genug)) > Spricht das nicht schon wieder für externes RAM? Nein. Der Arm7 ist kein "Scharchsack" und alles was wir hier an Funktionen gelistet haben kann er abdecken.
das "OSAR-Forum" ist online! die URL: http://forum.osar.it-livetalk.de Da ich das eben erst aufgesetzt habe, kann es bei dem einen oder anderen noch einige Stunden dauern, bis der DNS-Eintrag im Cache aller Provider angekommen ist. Die Aufteilung und Rechte-Vergabe ist im Moment auch noch nicht ideal, wird aber sicherlich in den nächsten Tagen vervollständigt werden. Harry
> Aussage der Firma am Telefon: "Wieviel 100000 Stück brauchen Sie denn". > Also doch ein Problem. Naja, muss nochmal was nachschauen und > zurückrufen, evtl. können wir dort doch etwas kaufen... Hm....kann man sich nicht vielleicht an die Bestellung einer anderen Firma mit dran haengen und einfach 20Stk fuer 1Euro von deren Teilen kaufen? > Zentrale Seite > mit eigenem Forum, Wiki/CMS, Projektmanagent, Versionsmanagement, > Bugtracker, etc. (oder was auch immer). Oder gibts das schon? Das Problem ist aber das jeder sein eigenes System nehmen will. Wenn ich z.B mal nicht HEW nehme, dann nehme ich Emacs, make und sccs. Aenderungen wuerde ich mit diff/patch machen. Bin ich damit kompatible? Ich bin mir ziemlich sicher an der Stelle kommt die naechste Katastrophe. :) > In diesem Thread stecken verdammt viele Informationen drin.. leider > extrem unstrukturiert. Und das macht halt dann keinen Spass > mitzuarbeiten. Subforen bräuchte man.. Ich glaube das wissen schon alle. Bloss eine Loesung scheint es in der Nach-Usenet Zeit nicht mehr zu geben. Alles schoen bunt, klickbar und leistungslos. > Spricht das nicht schon wieder für externes RAM? Ich sach dazu jetzt nichts. Nur oh..manoman...SEUFZ. Olaf
Tagg schrieb: > mit eigenem Forum, Wiki/CMS, Projektmanagent, Versionsmanagement, > Bugtracker, etc. (oder was auch immer). Oder gibts das schon? Wiki: http://osar.it-livetalk.de Forum: http://forum.osar.it-livetalk.de (seit wenigen Minuten online) SVN: wir werden das SVN von µC.net Harry
wenn ihr noch Probleme mit den Rechten im Forum habt(und da sind noch Probleme!) , bitte kurze Nachricht an mich! Ich kümmer mich dann darum. Harry
>> Zentrale Seite >> mit eigenem Forum, Wiki/CMS, Projektmanagent, Versionsmanagement, >> Bugtracker, etc. (oder was auch immer). Oder gibts das schon? > Das Problem ist aber das jeder sein eigenes System nehmen will. Wenn ich > z.B mal nicht HEW nehme, dann nehme ich Emacs, make und sccs. > Aenderungen wuerde ich mit diff/patch machen. Bin ich damit kompatible? ??? Ich versteht jetzt den Zusammenhang nicht ganz. Ein gutes Projektmanagement (Ziele, Verantwortlichkeiten, Recouchen) sind elementar für ein Professionelles Arbeiten. Tools wie Trac, SVN und ein Forum sind da sehr gute Hilfen. Insbesondere bei OSS-Gruppen muss es klare Vorgehensweisen und Verantwortlichkeiten geben. Sowas muss dokumentiert und in einen Rahmen gefasst werden. (zb. Wikis, SVN, etc) Mir ist es egal was für ein System wenn es seinen Zweck erfüllt. > Ich bin mir ziemlich sicher an der Stelle kommt die naechste > Katastrophe. :) Wieso Katastrope? Nich immer soviel reden, einfach mal machen. Wenn wir so bei uns arbeiten würden, währen wir schon lange Pleite. > Ich glaube das wissen schon alle. Bloss eine Loesung scheint es in der > Nach-Usenet Zeit nicht mehr zu geben. Alles schoen bunt, klickbar und > leistungslos. Das stimmt doch garnicht. Ich bin ein Konsolenkind und kritisiere die ganzen neuen Oberflächen oft massiv weil das viel effizenz verschenkt wird. (klickibunti) Aber wenn man das vernünftig anpasst und weiß worauf es ankommt hat man top Hilfmittel. Man muss halt den jungen Programmierern auch mal in den Ar*** treten wenn eine Mainframe Textanwendung mit 80x40 Zeichen schneller und besser zu bedinen ist wie der Windowspendant. Das hat nix mit der Anwendung sondern mit der Unfähigkeit des Programmierers zu tun. Wie immer kommt es darauf an wie es der Projektleiter drauf hat. Er sucht sich die Leute/Recouchen entsprechend zusammen und past das an. Macht er seinen Jop gut, wirds ein riesen Erfolg.
> Mir ist es egal was für ein System wenn es seinen Zweck erfüllt. So wie ich es verstanden habe will hier jeder sein eigenes System nutzen. Das ist der Punkt wo ich mich frage wie das gehen soll. Nicht das ich das jetzt verdamme oder gut heisse. Ich bin da erstmal neutral. Mir leuchtet nur nicht ein wie das klappen soll. > Wenn wir so bei uns arbeiten würden, währen wir schon lange Pleite. Das ist keine Frage. :-) > Wie immer kommt es darauf an wie es der Projektleiter drauf hat. Aber du bist hier in keiner Firma. Du willst Leute freiwillig dazu bringen etwas zu machen. Ich mache hier z.B nur mit solange ich Spass dran habe. Wenn es wie Arbeit wird bin ich sofort weg, weil Arbeit habe ich auch so genug. Olaf
mhh bin im prinzip auch sehr begeistert von der Idee ! ich würde sagen, es gibt eine Version, die den Grundanforderungen USB, SD, evtl OBD usw gerecht wird.. Was und Wie genau diese Version ausschauen soll, müsste man einfach mal in den nächsten Beiträgen zusammenfassen, evtl mit Abstimmen oä.. Ich denke es ist nicht möglich, für jeden etwas passendes zu bauen, daher sollte man schauen, was wirklich gewünscht ist und das so realisieren. Ich finde die Idee im Prinzip super ! Es wird ziemlich sicher ne Abstimmung fällig werden, wenn ich mir anschaue, wieviele Leute hier mitdiskutieren.. evtl auch mehrere je nach Frage (Prozessor, IDE ...) Thema Projektleitung.. Ich denke das ganze sollte nicht von einem einzigen gestemmt werden. Ein Team von sagen wir ca. 5 Leuten mit jeweiligem Fachgebiet dürfte effizienter sein, da so die Arbeit für den einzelnen erheblich weniger wird. Grüße, Stephan
Ich denke viel mehr als 5 Leute würden wir am Anfang sowieso nicht sein. Hier diskutieren wir übrigens weiter: http://forum.osar.it-livetalk.de Es wird sonst einfach zu unübersichtlich!
ich muss das mal ein wenig "pushen" :-D Hier: http://forum.osar.it-livetalk.de/ gehts weiter ;) Harry
Alle wichtigen Infos zu dem Projekt findet man jetzt auch hier: http://www.mikrocontroller.net/articles/OpenSource_Autoradio Wir suchen nach wie vor fähige Leute, die interessiert sind dieses Projekt voran zu bringen! Harry
hallo ich suche seit Jahren eine Sotware für Dab T1002 Grundig. Alte Software ist vorhanden auf CD. Müsste aber Aktualisiert werden. Derzeit emfange ich nur den dab rundfunk und nicht den Datenservice. könnten sie mir dabei behilflich sein. mit freundlichen grüßen Pfisterer
Pfisterer Andreas schrieb: > hallo > ich suche seit Jahren eine Sotware für Dab T1002 Grundig. Alte Software Frag lieber mal im Forum! http://forum.osar.it-livetalk.de dieser Thread ist eigentlich obsolet. Harry
hallo, bin auch schon seit langem dabei wieder meinen pc in das auto zu verbauen... bis jetzt wurde ich von einem guten dab/rds-teil abgehalten... da mit alten karten keine brauchbare qualität vorhanden war. nun vor einigen monaten habe ich das geeignete stück gefunden... http://www.frontier-silicon.com/audio/index.htm aber leider rücken die kein einzelnes teil raus, auch nicht für testzwecke, da sie vermuten, dass man sowieso selbst keine schnittstelle schafft. am projekt bin ich natürlich interessiert, falls es noch steht... meldet euch bei interesse bei mir... a.frena@gmail.com grüße alex
> am projekt bin ich natürlich interessiert, falls es noch steht...
Momentan krankt es etwas daran das ich immer noch auf die Controller
warte. Aus Frust habe ich heute Abend mal den aktuellsten gcc
runtergeladen, unter Linux neu uebersetzt und angepasst und ein erstes
kleines Testprogramm erzeugt das mein Bootmanager von SD-Karte reinlaedt
und startet:
[olaf] ~/sources/SH2A/test1: make
sh2a-gcc -mcpu=m2a -c start.s
sh2a-gcc -O0 -m2a -Wfloat-equal -Wunused-variable -g
-Wa,-alhcn=test1.o.asm,-L -c -o test1.o test1.c
sh2a-gcc -O0 -m2a -Wfloat-equal -Wunused-variable -g
-Wa,-alhcn=vecttbl.o.asm,-L -c -o vecttbl.o vecttbl.c
sh2a-gcc -O0 -m2a -Wfloat-equal -Wunused-variable -g
-Wa,-alhcn=test1.asm,-L -o test1 -nostartfiles -o start.elf start.o
-Wl,-Map=mapfile.txt -T sh2a.ld test1.o vecttbl.o intprg.c
sh2a-objcopy -O binary start.elf start.bin
[olaf] ~/sources/SH2A/test1: sh2a-gcc --version
sh2a-gcc (GCC) 4.5.1
Meine Test-LED blinkt. :-)
Olaf
Alexander Frena schrieb: > nun vor einigen monaten habe ich das geeignete stück gefunden... > http://www.frontier-silicon.com/audio/index.htm FS gibt ausschließlich (kostenlose) Muster an Firmen die auch die EVKits gekauft haben. Ich habe das (alte) Venice 6.1 und die programmierung ist ein einziger Horror. Vor allem benötigst Du erhebliche Rechenleistung, welche nur noch mit ARM Controllern im BGA Gehäuse verfügbari ist, also nicht gerade was für den Hobby-Electroniker. > aber leider rücken die kein einzelnes teil raus, auch nicht für > testzwecke, da sie vermuten, dass man sowieso selbst keine schnittstelle > schafft. Das sehe ich auch so... Grüße Michelle
Olaf schrieb: > Meine Test-LED blinkt. :-) Damit ist das Ding ja schon quasi komplett ;-) Traurig nur, dass es zum Schluss darauf rausläuft, dass zum Schluss - falls es soweit kommt - einer alleine wieder alles machen musste ... Grüße, Markus
> Traurig nur, dass es zum Schluss darauf rausläuft, dass zum Schluss - > falls es soweit kommt - einer alleine wieder alles machen musste ... Ach, ist ja noch viel zu tun. Aber es bringt nichts solange nicht andere Leute auch etwas zum mitprogrammieren haben. Und man muss wenigstens erstmal etwas schaffen das zumindest auf dem Level einer blinkenen LED sofort funktioniert sonst ist man schnell frustriert weil man nicht weiss wo man mit der Fehlersuche anfangen soll. Der Prozessor ist zwar wirklich schoen, aber das dicke Datenblatt erschlaegt einen am Anfang doch etwas. Wie der Zufall es aber so will habe ich vor einer halben Stunde erfahren das die Controller aus Japan bei Glyn eingetroffen sind und jetzt zu mir weiterverschickt werden. Ich denke ich werde dazu heute Abend oder morgen etwas schreiben. Im Augenblick arbeite ich im uebrigen gerade an einem Mega8 :-) Genauer gesagt ich habe mir gestern Abend mal das hier runtergeladen und ans laufen gebracht: http://www.harbaum.org/till/i2c_tiny_usb/index.shtml Ich bin gerade dabei da so anzupassen das man ueber USB das SPI-Flash am SH7262 brennen kann. Das braucht man zwar nur einmalig bei der ersten Inbetriebnahme, oder falls man den Bootloader vergurkt, aber irgendwie muss man ja das erste Programm da reinbringen. Ich selbst schreibe ein kleines Shellprogramm unter Linux weil das zuhause mein Hauptsystem ist. Es waere aber nicht schlecht wenn das einer hinterher unter Windows anpassen koennte damit andere Leute das auch benutzen koennen. Das sollte IMHO keine grosse Sache sein weil ich libusb verwende und es dies auch fuer Windows gibt. Es muss auch keine tolle anwendung sein. Einfach ein File von der Kommandozeile ins Flash brennen reicht schon. Olaf
Hallo alle, gibt es schon Neuigkeiten, oder ist das Projekt auf Grund gelaufen? Grüße, Benjamin
wg überzogener Anforderungen war es schon von Anfang an zum Scheitern verurteilt. Schöne WIKI aufgebaut, und nichts dahinter. Gruß berliner
Wenn das Projekt tatsächlich vorbei ist, sollten wir es neu aufziehen. Das wär auf jeden Fall eine interessante sache. Gruß Benjamin
> gibt es schon Neuigkeiten, oder ist das Projekt auf Grund gelaufen? Software MP3-Decodierung laeuft jetzt: http://www.criseis.ruhr.de/mp3_2.jpg Letzte Woche habe ich ein 400x240 Pixel TFT fuer die Front gekauft und arbeite jetzt an einer Platine fuer das Bedieninterface. Es handelt sich um ein Seiko 30WQF0H mit 160Grad Betrachtungswinkel und es hat zusaetzlich zu den ueblichen 18Bit Port noch eine SPI-Schnittstelle. > wg überzogener Anforderungen war es schon von Anfang an zum Scheitern > verurteilt. Ja nun, es gibt immer mehr Leute die sich gerne selber reden hoeren als etwas zu machen. So wie es aussieht ziehe ich das jetzt mit Kai alleine durch. Andererseits kann man auch nicht erwarten das sowas sich ueber Nacht entwickelt. Ich meine wir arbeiten ja alle auch noch als Entwickler und das ganze ist Hobby! .-) > Schöne WIKI aufgebaut, und nichts dahinter. Ich weiss nicht was ein Wiki ist, aber ich nichts aufgebaut. Ich habe ueberlegt ob ich nicht mal ein paar Seiten schreiben soll wie man den SH7262 benutzt. Aber ich bin mir noch nicht ganz klar ob ich das auf meiner eigenen Homepage machen soll oder mit dem Luxukram wie man das hier auf diese Seite findet. Es waere wohl netter so wie man das hier fuer die Hilfe findet, aber dazu muesste ich wissen wie ich diese Seiten bei mir zuhause mit dem Emacs erst mal schreiben kann und dann auf einmal hochlade. Weiss zufaellig einer wie man sowas am besten macht? Olaf
Sagmal, was ist eigentlich mit dem DIN-Gehäuse? Vor Jahren kannte ich mal eine Firma die sowas als Leergehäuse in "normaler Ausführung" sowie als Slot-In anbot, aber selbst monatelanges Suchen hat mich zu keinem Erfolg gebracht. Hast Du eine Firma gefunden? Wenn man das selber machen muß, also ein Abkanntbank und Stanze währen über einen Bekannten verfügbar. Eine CNC Fräßmashine (~3500 Euro) für Platinen und Kunstatoff sowie Aluminium will ich mir selber kaufen. Grüße Michelle
Olaf schrieb: >> gibt es schon Neuigkeiten, oder ist das Projekt auf Grund gelaufen? > > Software MP3-Decodierung laeuft jetzt: > > http://www.criseis.ruhr.de/mp3_2.jpg > > Letzte Woche habe ich ein 400x240 Pixel TFT fuer die Front gekauft und > arbeite jetzt an einer Platine fuer das Bedieninterface. Es handelt sich > um ein Seiko 30WQF0H mit 160Grad Betrachtungswinkel und es hat > zusaetzlich zu den ueblichen 18Bit Port noch eine SPI-Schnittstelle. Das find ich Toll dass du noch dran bist :) >> wg überzogener Anforderungen war es schon von Anfang an zum Scheitern >> verurteilt. > > Ja nun, es gibt immer mehr Leute die sich gerne selber reden hoeren als > etwas zu machen. So wie es aussieht ziehe ich das jetzt mit Kai alleine > durch. > Andererseits kann man auch nicht erwarten das sowas sich ueber Nacht > entwickelt. Ich meine wir arbeiten ja alle auch noch als Entwickler und > das ganze ist Hobby! .-) Ist mir klar, dass das seine Zeit braucht, hab nur lange Zeit nichts mehr im Forum von euch gehört und wollte deshalb mal nachfragen ob das Projekt noch lebt. Würd euch gerne helfen, wenn ich irgendwie helfen kann... Benjamin
> Sagmal, was ist eigentlich mit dem DIN-Gehäuse? Das ist noch ungeklaert. :-) Aber sagen wir mal so, solange die endgueltige Stueckzahl einstellig ist, oder gar naehe der ersten Primzahl liegt, ist es am guenstigesten einfach ein billiges NoName Radio fuer 30-40Euro zu kaufen und von da das Blech und den Anschlusstecker weiterzuverwenden. > Ist mir klar, dass das seine Zeit braucht, hab nur lange Zeit nichts > mehr im Forum von euch gehört und wollte deshalb mal nachfragen ob das > Projekt noch lebt. Würd euch gerne helfen, wenn ich irgendwie helfen > kann... Es waere jetzt eigentlich mal an der Zeit das ich ein bisschen was veroeffentliche. Bloss wenn ich das so mache wie hier auf der Internetseite dann muss ich das ja erstmal selber schreiben und irgendwie testen bevor ich es hochlade. Mir ist nicht klar wie das funktionieren soll. Meine Interneterfahrung beschraenkt sich bisher auf meine Homepage und die ist in HTML-pur mit Emacs geschrieben und sogar Mosaic kompatible. :-) Ansonsten koennte ich Interessenten gerne einen Prozessor verkaufen und auch die Layouts fuer ein Testboard (1) rausgeben. Damit kann man dann von SD-Karte MP3 abspielen und es gibt verschiedene Ports, SPI, I2C, RS232 zum rumspielen. Es hat aber noch nichts mit dem endgueltigen Board zutun. Momentan denke ich halt ueber das Panel nach, ist aber noch in einem fruehen Stadium. Soll heissen ich habs noch nichtmal geroutet. :-) Ich denke das gerade in das Frontpanel noch einiges an Arbeit rein gehen wird. Zum einen muss ueberhaubt erstmal eine Bedienphilosphie erarbeitet werden. Derzeit gibt es rechts und links vom Display einen Encoder (mag Kai) und unter dem LCD und rechts davon gibt es Tasten die man ueber das TFT beschriften kann. (mag ich) Ausserdem ein paar wahllos verteilte Taste die noch keinen Sinn haben. Man muss dann erstmal schauen was man genau an welcher Stelle braucht. Dann ist da das erstemal ernsthaft ueber Mechanik nachzudenken, also wie verlaengert man z.B die Tasten damit sie durch die Front schauen, welchen Encoder nimmt man jetzt, passt das alles auf eine Platine oder braucht man zwei um unterschiedliche Hoehen auszugleichen? Ausserdem gebe ich Kai naechste Woche ein paar RadioICs und er denkt wohl noch daruber nach ob er sie nehmen soll oder ob er irgendwo noch ein paar bessere Empfaenger herbekommt. Olaf 1: Das Testboard ist auch interessant wenn man sowieso mal was mit einem schnellen Prozessor machen will und mit Audioverarbeitung spielen will. Ich hab das urspruenglich als Machbarkeitsstudie angesehen um zu pruefen ob man den Prozessor auf einem selber geaetzten 2-Lagenboard vernuenftig ans laufen bekommt. Es sind auch durchaus andere Anwendungen denkbar. Mir schwebt da z.B noch ein MP3-Player mit Roehrenendstufe und SPDIF durch den Kopf. Ich weiss nicht ob ich es schonmal gezeigt habe, aber es sieht so aus: http://www.criseis.ruhr.de/mp3_1.jpg Das Audioboard mit dem AD-DA Wandler ist extra und auf dem Bild jetzt nicht zu sehen. Interessant waere dann ein faehiges und williges Opfer welcher das erstemal nach meiner Anleitung ein Dutzend mal auf die Fresse fallen will und jedesmal nachbessert wenn ich etwas zu erklaeren vergessen habe. Also nicht gerade ein Anfaenger der das erstmal einen Mega8 geloetet hat. .-) Ebenfalls interessant waere jemand der ein Stueck Software das ich unter Linux geschrieben habe damit man SPI-Flash ueber USB brennen kann unter WinXP zum laufen bringt damit auch andere Leute den Urlader das erstemal in ihr eigenes Board brennen koennen. Wer da Interesse hat soll sich mal melden. Olaf
Olaf schrieb: > Ausserdem gebe ich Kai naechste Woche ein paar RadioICs und er denkt > wohl noch daruber nach ob er sie nehmen soll oder ob er irgendwo noch > ein paar bessere Empfaenger herbekommt. TEF6616 gibts jetzt in Einzelstücken jetzt bei Mouser zu 15,71€ + Steuer. Hat schon jemand eine aufführliches Datenblatt gefunden??
Olaf schrieb: > Ja nun, es gibt immer mehr Leute die sich gerne selber reden hoeren als > etwas zu machen. So wie es aussieht ziehe ich das jetzt mit Kai alleine > durch. Das Problem ist eher, dass die Initiatoren mit einer gewissen Vorstellung an das Projekt herangehen und es Open Source machen, um "billige" Helfer zu bekommen. Dass die dann aber eigene Ideen und Vorstellungen haben ist eher hinderlich. Die meisten erfolgreichen Open-Source-Projekte brauchen erst einmal eine solide Basis, die von einer Einzelperson oder einer kleinen Gruppe erstellt werden, bevor es für die Community tatsächlich interessant wird und sich Leute wirklich beteiligen.
Olaf schrieb: > Ebenfalls interessant waere jemand der ein Stueck Software das ich unter > Linux geschrieben habe damit man SPI-Flash ueber USB brennen kann unter > WinXP zum laufen bringt damit auch andere Leute den Urlader das erstemal > in ihr eigenes Board brennen koennen. Lass mich mal in das Programm reinschaun.
> Lass mich mal in das Programm reinschaun.
Gib mich mal Adresse in Internetz...
Olaf
> MP3-Player mit Roehrenendstufe
Dann mußt Du aber Kutschenräder an dein Auto montieren. Nur so kriegst
Du das richtige 'vierling'.
Olaf schrieb: >> Lass mich mal in das Programm reinschaun. > > Gib mich mal Adresse in Internetz... > > Olaf du bist ja auch bei unserem Forum http://forum.osar.it-livetalk.de/index.php registriert oder? Ich schick dir dort ne PN mit meiner E-Mail Adresse. Möchte die nicht so öffentlich dahin schreiben. Benjamin
> du bist ja auch bei unserem Forum
Ich bin mir nicht ganz sicher, aber habe ich das Programm nicht schon
dort gepostet?
Olaf
Olaf schrieb: >> du bist ja auch bei unserem Forum > > Ich bin mir nicht ganz sicher, aber habe ich das Programm nicht schon > dort gepostet? > > Olaf Achja... habs schon gefunden... SPI_Flasher.zip http://forum.osar.it-livetalk.de/viewtopic.php?f=9&t=42 Ich schaus mir am Wochenende mal durch
Hallo Kai, Olaf und alle Anderen, wollte mich nur mal kurz mit einem Ping melden. Ich bin immer noch da und schaue auch gelegentlich rein. Allerdings bin ich leider bis kurz nach der CeBit zu 150% ausgelastet, weswegen ich so plötlzich verschwunden bin. Ist leider immer so, dass wenn das Hobby gerade in eine interessante Phase kommt, der Beruf einem die Zeit auffrisst. Aber es ist schon eine ordentliche Leistung, die bislang erbracht wurde. Auch wenn es weniger Leute als gehofft gestemmt wurde. Ich verfolge es aber weiter und bin bald möglichst wieder dabei. Btw. Ich habe den STM32 in Nut/OS portiert. Ansätze für andere Cortexe sind ebenfalls schon da. Es fehlen nur noch Ethernet und USB. Beides kommt auf jeden Fall, Ethernet als nächstes. Gruß, Ulrich
Ulrich P. schrieb: > Allerdings bin ich leider bis kurz > nach der CeBit zu 150% ausgelastet Was präsentierst du denn auf der CeBit und unter welcher Firma? Vielleicht sieht man sich ja ;) Benjamin
Hi Benjamin, Ich diene einem großen Schaltschrankhersteller und entwickle gerade eine Neuvorstellung im Bereich Überwachung und Steuerung für obige Schränke und ihrer Innenleben. Spannende Aufgabe mit Microcontrollern, Embedded Boards und Linux, etlichen Sensoren und diversen Bus-Systemen. Ulrich
> Ich diene einem großen Schaltschrankhersteller und entwickle gerade eine
Ich hoffe du programmierst nicht so wie Rittal liefert. :-D
Olaf
:) Definitiv nicht! Schade, dass Du Dich nicht mit einem Account hier anmeldest, sonst hätte ich Dich jetzt per PM gefragt, was da klemmt und was man für Dich tun kann. Ulrich
> Schade, dass Du Dich nicht mit einem Account hier anmeldest, Kann ich mir nie merken.... Hier mal die aktuellen Fortschritte: http://www.criseis.ruhr.de/tft.jpg Olaf
Oerks! Da bekommt man ja Augenkrebs. Ist der "Schattenwurf" gewollt?
Neee, das ist extra so gemacht, um das Cyber-War-Zentrum der Bundesregierung zu testen... :-D Schönen Sonntag Michelle
> Da bekommt man ja Augenkrebs. > Ist der "Schattenwurf" gewollt? Wie du vielleicht weisst geschieht die artgerechte Haltung von Et-Ings und Programmierern immer bei gedaempftem Licht und da kann es schonmal vorkommen das man beim fotografieren etwas verwackelt. :-) Ansonsten sind die Darstellungen auf dem LCD natuerlich erstmal nur Spielkram um ueberhaubt die Ansteuerung zu testen. BTW: Das Display, ein 30WQF0 von Glyn, ist ziemlich cool! Es hat SPI Ein- und Ausgang und weil es ein Farbdisplay ist wird jedes Pixel einzeln ueber einen eigenen Befehl angesteuert. Dadurch spart man sich das ganze Rumgehampel wie man es von monochromen LCDs kennt um das Pixel-Bit in einem Byte zu maskieren. Damit ist selbst die Ansteuerung von einem kleineren Controller relativ einfach und man kommt sogar ohne viel Ram aus solange man keine Fenster implementieren moechte. Olaf
Ist ja ok, war auch nicht so ernst gemeint ;-) Spielen muss ja auch sein.
Die Idee des OSCAR gefällt mir, auch wenn sie scheinbar Tot ist. Ich denke man sollte aber eher auf vorhandenen Rescourcen setzen z.b. gibt es DIN / Doppel DIN PC´s mit Monitor usw. als OS wäre denke ich mal Linux oder Android das beste, zur Kopplung ans Auto z.b. CAN-Bus / Analoge Steuerleitungen wäre sicher eine uC Lösung das beste um z.b. diese an den USB Anschluss zu tackern und eine Einheitliche API zu schaffen um die Daten im PC auszuwerten. Macht das Projekt noch jemand ? oder ist es wirklich tot ? Grüße René
z.b. http://www.mini-tft.de/xtc-neu/product_info.php?info=p43442_Doppel-DIN-Car-PC-Barebone--Intel-Mobile-M-1-5Ghz-.html http://kfz-multimedia.de/product_info.php?info=p654_Bravo-2-DIN-in-Dash-Car-PC-mit-Touchscreen-Intel-Atom-Dual-Core.html http://www.cartft.com/catalog/il/1116 http://www.alibaba.com/product-gs/218892314/2DIN_Car_PC_with_Computer_s.html http://www.telematik-shop.eu/Doppel-DIN-Car-PC-TS-intel http://shop.ican-gmbh.com/index.php/speziallosungen/intel-minipcs/car-pc-doppel-din.html http://www.cartft.com/catalog/il/959
Der Preis ist aber auch ein Hammer... Grüße Michelle
Das stimmt :-) aber dafür ist fast alles dabei und von der Industrie :-) nen default PC wird es immer geben :-) hoffe ich ... daher denke ich das dies die meiste flexibilität bietet :-) ... egal ob doppel din, single din oder komplett andere Lösung ..
Hallo, ich bin bei der suche nach einem Programmierbarem Autoradio auf diesen Thread gestossen und hätte daran Interesse mitzuwirken. Im Wiki von OSAR finde ich leider keine Kontaktdaten. Existiert das Projekt überhaupt noch? Mit wem kann man Kontakt aufnehmen? Gruss yonah
Hallo, auf der Suche nach einer Lösung für mein Problem bin ich auf diese Seite hier gestoßen und mache mal keinen neuen Beitrag auf. Ich habe ein Nachrüstnaviradio für einen BMW E46. Man muß bei dem ein oder anderen Abstriche machen, was mich aber extrem stört ist die Sprachqualität des integrierten BT-Mikrofons. Dieses ist eine einfache Mikrofonkapsel. Das im Auto ab Werk verbaute Mikro ist ein aktives mit Entstörfilter, was eben eine zusätzliche Stromversorgung besitzt und einen extra Lautsprecher; beim Nachrüstradio werden die Autolautsprecher versorgt. Das Problem liegt meiner Meinung in der Position des Mikro-Anschlußes bzw. der beiden Pole auf der Platine im Radio. An diese Stelle habe ich bereits das original BMW-Mikro gelötet, was aber keine Verbesserung brachte. Dieses liefert jedoch eine sehr gute Sprachqualität. Gibt es Experten, die mir hier vielleicht helfen können, das BMW-Mikro klangtechnisch optimal in das Nachrüstradio zu integrieren? Oder weiß jemand eine Quelle, in der man sich über Hilfestellungen schlau machen kann? Vielen Dank vorab!!
Was ist eigentlich aus den Projektideen geworden? Gab es eine interessante Umsetzung?
Noe, irgenwann hatte ich ein Auto mit eingebauten Radio was man nur schlecht ausbauen konnte weil das gleichzeitig Telefon war. Allerdings jetzt haette ich wieder eins wo ich drueber nachdenken koennte. :-D Olaf
"Gab es eine interessante Umsetzung?" Selbstverständlich. Steht beim Aldi hinter Glas für 69,95 EUR. Die Kassiererin muss nur schnell mal den Schlüssel holen ...
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.