Abstract: Sehr umfangreiches Embedded Linux Projekt auf Basis von XScale und P-M Modulen. Wir suchen jemanden, der uns beim (Peripherie-) Schaltungsdesign und Layout der notwendigen PCBs unterstützen kann. Entweder als community Beitrag oder in Auftragsarbeit. Guten Abend, ich versuche mich kurz zu fassen. Seit längerer Zeit arbeiten ich und mittlerweile auch ein, zwei andere Freaks,an einem Embedded Sytem, das Navigation (GPS, TMC), Kommunikation (GSM, PMR, GPRS, Intercom), Unterhaltung (MP3) und Messdaten Erfassung auf einem Tourenmotorrad zusammenfasst. Geplant ist der Einbau in einen speziellen Tankrucksack (Main CPU, Touchscreen, Storage, etc). Zusätzlich soll es auf dem Motorrad zwei Funktionseinheiten (1x Kommunikation, 1x Datenerfassung) geben, die per Ethernet mit der Main CPU verbunden werden. Als OS wird ein embedded Linux (ElinOS) zum Einsatz kommen. Libraries, Controller und GUI werden in C / C++ verfasst (QT embedded). Hintergrund der Aktion: So etwas gibt es für Motorräder einfach nicht! Es gibt Navi im Tankrucksack, Navi mit GSM, Intercom mit Musik, PMR und GSM, aber alles ist irgendwie zusammengebastelt. Ich möchte meinen iPod & mein Handy zu Hause lassen, am Nordkapp gibts nämlich keine Steckdose um das Zeugs aufzuladen ;-) Die letzten zwei Jahre haben wir damit verbracht Komponenten auszuwählen, Motorrad spezifische Einflüsse zu analysieren und einen Prototypen zu bauen. Dies auf Basis eines 3.5 SBCs von Arbor, einem 7 Touchscreen von Xenarc, einem GSM-GPRS Modul von SonyEricsson und einem GPS-Modul von Garmin. Hierfür wurde ein passendes Alu-Gehäuse aus dem Vollen CNC-gefräst. In dieser Zeit haben wir (vor allem ich), sehr viel Lehrgeld bezahlt um am Ende zum Schluss zu kommen, dass es ein spezifisches HW-Design braucht um den gewünschten Einbettungsgrad zu erreichen. Der Prototyp fasste nur fertige Module (GSM, GPS) auf einem PCB zusammen und wurde wegen der Faulheit des Beauftragen Elektroniker-Lehrlings nie wirklich fertig :-( Obwohl einiges an Elektronik Know-How vorhanden ist, reicht es nicht aus um die HW so hinzukriegen wie wir uns das vorstellen. Software ist kein Problem, da können wir vom Treiber bis zum GUI alles selber fabrizieren. Konkret geht es also darum, basierend auf SoMs (Xscale PXA270 und Pentium M ETX-e) die kompletten Boards für die Peripherie Anbindung zu entwickeln. Das was wissen wir, aber nicht das wie ;-) Falls jemand interessiert ist, kann ich gerne weitere Details posten, bzw. ich bin dabei ein Projekt-Wiki einzurichten. Wie gesagt, wir können uns eine aktive Projektmitarbeit vorstellen, oder Lohnfertigung, oder ... Grüsse aus der Schweiz::Bernhard
Hallo Bernhard, nun du sprichst hier gerade einige Leute an die gerne ein solches Board mit dem PXA270 hätten, aber aus Kostengründen es sich gerade nicht leisten können. Näheres findest du im Thread http://www.mikrocontroller.net/forum/read-1-265881.html#new Nun ich denke es würden sich einige Leute finden die euch helfen würden wenn das Board an sich dann als Open-Source für alle verfügbar wäre. Vielleicht wäre es ja auch möglich, dass ihr das Board dann günstig an Bastler vertreiben könnt.
Hallo Thomas, danke für den Tipp! Vielleicht kann man da was kurzschliessen... Es ist übrigens geplant das gesamte Projekt unter einer OpenSource Lizenz zu veröffentlichen (welche ist zur Zeit noch unklar). Anybody else? Danke & Gruss::Bernhard
hört sich nach ner speziallösung die unheimlich teuer ist und später kaum einer haben will an. ein pda als navi und dazu eine kommunikationskarte (ggf eigenentwicklung) für GSM, PMR, GPRS und Intercom. wenns unbedinngt sein muß noch n TMC-modul dabei. Fertig is das MoKoMeNavcenter(Tm)
@tenner Es ist eine Speziallösung und wir wollen damit auch keinen Preis für wirtschaftlichkeit gewinnen ;-) Die Bastellösung mit 10 verschiedenen Einzelgeräten hab ich schon hinter mir. Das Ergebnis war einfach zu unbefriedigend...
"Der Prototyp fasste nur fertige Module (GSM, GPS) auf einem PCB zusammen und wurde wegen der Faulheit des Beauftragen Elektroniker-Lehrlings nie wirklich fertig :-(" Man kann ja der deutschen Jugend viel nachsagen, aber bei so einem Monsterprojekt würde ich erstmal nicht von Faulheit sprechen. Das ist einfach kein Lehrlingsprojekt, basta. Es ist wirklich erschreckend, wie sich reine Softwerker die Hardwareentwicklung vorstellen. Man bräuchte nur ein paar Baugruppen zusammenzupappen und fertig. So kann da nie ein Schuh draus werden. Und wenn ein Lehrling so nebenbei das nicht zum Laufen kriegt, eine komplette eigene Hardwarelösung ist der noch viel dornigere Weg. Wenn die Herstellungskosten keine Rolle spielen, aber die Entwicklungskosten und Zeit, würde ich unbedingt zu soviel wie möglich Fertigbaugruppen raten. Und vor allem, eine möglichst konkrete Spezifikation (Pflichtenheft), was das Ding alles machen soll, und wie es das machen soll. Erweiterungsluftschlösser zu bauen, vergeudet nur Zeit. Bei so einem großen Monsterprojekt dürfte auch das Powermanagement eine wichtige Rolle spielen, z.B. ein Mikrokontroller, der allein für die Zu- und Abschaltung der benutzten Komponenten zuständig ist und entsprechende Leistungsschaltstufen. Und auch wenn man kein CE haben will, spielen EMV, Temperaturfestigkeit, Rüttelfestigkeit trotzdem eine Rolle. Peter
Hallo Peter, die Formulierung war vielleicht etwas herablassend (es war übrigens ein Schweizer Lehrling). Das Problem war nicht die komplexität der Aufgabe, aber das spielt jetzt eh keine Rolle mehr. An dieser Stelle möchte ich erwähnen, dass es sowohl ein Pflichtenheft gibt, wie auch umfangreiche Abklärungen betr. der geplanten Komponenten. Wie du richtig bemerkst sind EMV, Temp. range und Vibrationsfestigkeit entscheidende Punkte. Die mechanischen Probleme haben wir grösstenteils gelöst (ich war ursprünglich nicht "reiner" Softwerker ;-). EMV und Stromversorgung sind Themen, die wir gerne mit einem Experten erarbeiten möchten. Vielleicht hast du da Erfahrungen? Ich weiss einfach, dass die Störungen auf dem Bordnetz katastrophal sind und ihnen nur mit Drosselspulen und dergleichen kaum beizukommen ist. Zum Thema "Erweiterungsluftschlösser": Es gibt eine klare Trennung zwischen "must" & "nice to have". TMC & Gyro sind z.B. solche "nice to haves". Ich haben in meinem ersten Post erwähnt, dass ich bei Interesse gerne weitere Details bekannt gebe. In diesem Projekt stecken zwei Jahre Recherche, die Passen einfach nicht in einen Eröffnungspost. Aber ich nehme gerne jede Anregung entgegen. So long::Bernhard
Hallo, wir kennen uns ja schon aus diesem Thread: http://www.mikrocontroller.net/forum/read-1-265881.html#new Nach (wirklich) langem Suchen bin ich zu dem Schluss gekommen, dass es auf Grund der Komplextät kaum einen Sinn macht, so ein SoM selber zu "bastel", nicht für den Preis, den z.B. Toradex anbiete. Außerdem will ich mich nicht ewig an der Basis aufhalten, bis ich mich endlich um meine eigentliche Anwendung kümmern kann (Inertial-Navigationsystem für Indoor Anwendungen -> virtuelle Karte aufbauen usw. unabhängig von GPS) Von einem PXA255 System wollte ich absehen. Ich habe eins auf Arbeit und bin damit nicht sonderlich zufrieden. Bei höheren Auflösungen geht das Speichermanagement in die Knie. Schon bei geriner Last (z.B. Maus bewegen) gibt es auf dem Dispaly herrliche Effekte. Ich kann aber trotzdem gerne mal Bilder machen. Naja, auf jeden Fall hätte ich großes Interesse an einer Sammelbestellung für das Colibri Modul. Das Baseboard will ich, in abgespeckter Version, nach der Schematik von Toradex nachbauen. Da könnten wir z.B. gerne zusammenarbeiten.
Ich habe nur einen (wichtigen) Tip: Das beste was du deinem System unbedingt antun solltest ist ein SIRF- Star-III GPS Chipsatz (am einfachsten eine nagelneue GPS-Maus mit RS232 nehmen mit dem Sirf3). Die Dinger sind gigantisch! Schlagen JEDES alte GPS um Längen, Empfang ist sogar in Gebäuden und Schluchten teilweise noch möglich. Bei GPS kannst du alles vergessen, was älter als 1Jahr ist und daher nicht darauf basieren kann - vor allem alte OEM-Module mit externer Antenne. Teuer und selbst mit der teuersten Antenne viel schlechter. jörn
Da ich schon einige Backplanes für die ETX-Module konstruiert habe, kann ich Dir sagen: Leg schon mal 10.000 Euro parat, denn eines ist klar: ein solches Board wirst Du nicht von einem Hobby-Layouter kriegen können... Und ein Profi wird so um die vier Wochen benötigen, wenn er schnell ist. Happy Layouting! Stephan.
@Jörn Danke für den Hinweis! Ich habe mich bis anhin mit einem Garmin Modul rumgeschlagen (GPS 15L), weil ich zu Beginn nix anderes gekannt habe. Für das Projekt werde ich aber entweder einen SiRF-III Chipsatz oder ein ANTARIS4 Modul der Firma uBlox nehmen (http://www.u-blox.com). Eigentlich wollte ich das Modul der Wahl direkt in unsere Applikation integrieren, aber wenn Aufwand & Ertrag nicht stimmen, steht auch eine GPS-Maus (USB) zur Diskussion. So long::Bernhard
@Stephan Walter Die Sammelbestellung ist sicher eine Option und auch für eine Zusammenarbeit beim Layout bin ich zu haben. Ich weiss halt nicht, inwiefern sich unsere Bedürfnisse decken. Das Modul wofür wir den PXA270 einsetzen wollen wird "headless" sein, also keinen Screen ansteuern müssen. Aber ich bin sicher, ein Austausch über Erfahrungen beim Design könnte sehr nützlich sein! @ Stephan Es ist mir klar, dass man ein ETX bzw. ein ETX-e Carrierboard nicht einfach mal so schnell layoutet. Auch wenns nicht gleich 10k Euronen sein müssen, darf das auch was Kosten. So long::Bernhard
@Bernhard Ihr wollt also ein System mit mehreren Prozessoren? Wozu braucht ihr den PXA im Genauen? Wie stellt ihr euch die Verbindung zum Pentium M vor? Ueber LAN? Das Display ist uebrigens das kleiner Uebel. Der Controller dafuer ist im PXA ja schon drin. Es wird extern nur ein paar Pegelwandler 3,3V -> 5V und eine Stiftleiste geben. Die Pins fuer das Display kann man in Software zu GPIOs machen, dann kann man die Stiftleiste auch fuer sonst was nehmen.
Die PXAs kommen im Kommunikations- und im Datenerfassungsmodul zum Einsatz, wobei letzteres weniger Priorität hat. Der eigentliche Hauptrechner für den Touchscreen, MP3 & Karten storage, etc. soll mit einem ETX-e Board realisiert werden. Das hat alle aktuellen Schnittstellen und massenhaft Power. Die Schnittsctelle zum Display bzw. Inverter möchten wir per LVDS realisieren, notfalls über VGA. Das SoM für das Kommunikationsmodul ist per Ethernet (CAT 6 S-STP wegen der Störungen) über einen Switch mit dem Tankrucksack-Hauptrechner verbunden. Der PXA270 ist dort im Wesentlichen für die Aufbereitung und Mischung der verschiedenen Audiostreams zuständig (ALSA), sowie für die Steuerung des GSM-Moduls und des Bluetooth-Moduls über USB (AT commands, etc). Bluetooth ist die Schnittstelle den Motorradhelmen (Schuberth Bluesonic). Die Kommunikation zwischen Fahrer & Sozius geschieht direkt über Bluetooth. Für die Integration des analogen Audiosignals des PMR-Funkgerätes, kommt ein spezieller TI Analog<-PCM->USB Codec zum Einsatz (PCM2902).
@SeppKnallhirsch Wiki ist mehr oder weniger eingerichet, der Inhalt gammelt aber noch fröhlich in Docs und Textfiles rum... Wenn man doch nur mehr Zeit hätte ;-)
@SeppKnallhirsch ich poste den Link zum Wiki, sobald es brauchbar ist. So long::Bernhard
Zum Colibri: Audio ist auf jeden Fall on Board. Aber wie seid ihr auf die Idee gekommen, dass die Audio Signale über den Bus laufen? Wenn ihr euch mal die Spec anschaut, seht ihr, dass es das extra Analogeingänge /-ausgänge für Audio und Touch gibt. Die haben ja auch mit dem XScale nix mehr zu tun sondern kommen vom UCB1400. Es gibt sogar noch vier ungenutzte Analogeingänge, vielleicht kann man die noch als extra Audiokanäle nutzen. Wie wollt ihr die analogen Signale über die USB-Leitung bringen? Auf die Differenzeingänge addieren? Hat sowas schon mal jemand gemacht? Würde mich auch interessieren, könnte ja eigentlich funktionieren.
Über den Bus des PXA270 können IMHO maximal zwei AC angesprochen werden, das heisst wir könnten neben dem UCB1400 noch einen zweiten AC'97 ansprechen. Wir trauen dem analogen Audioteil des UCB1400 nicht so richtig. Wir benötigen die analogen Eingänge für die Funk (PMR) integration, also nicht gerade eine Audioquelle in HiFi Qualität. Ich hab da zwei Käferchen gefunden die für uns durchaus geeignet wären USB<-->analog: http://focus.ti.com/docs/prod/folders/print/pcm2900.html http://www.micronas.com/products/by_function/uac_355xb/product_information/index.html Die Audioanbindung der Headsets (Helme) passiert über Bluetooth (siehe unten). Dort wird beschrieben, dass das verwendete Modul sowohl Audio über den Serial Link, wie auch über separate PCM I/Os akzeptiert. [http://bluetooth-alsa.sourceforge.net/embed.html] It's not that important for now to get PCM connected up directly, but there may be applications where it's nice. (We normally use the fact that CSR can route the audio over hci in our linux driver) [...]
da gibts noch mehr Teile TIs TAS1020 oder TUSB3200 z.B. die eine USB Audio Funktionalität bieten. Der Micronas wird wohl schwer zu beschaffen sein. Falls Ihr Fragen zu USB Audio habt ich kenne die TI Teile recht gut. Thomas
Hi, ich finde das Projekt hoert sich interessant an. Die ganzen Komponenten sind auch Automotive-Konform (Temperaturbereich) oder kann man diesen Aspekt ausser acht lassen bei dem Geraet? Gruß, Dirk
@Thomas Danke für das Angebot! Ich denke wir können jede Unterstützung brauchen :-) Ich schauen mir die Teile mal an und werd was dazu ins Wiki schreiben. @Dirk Hab weiter oben schon mal was dazu geschrieben. Ein Motorrad ist so ziemlich der unwirtlichste Ort für elektronische Komponenten, es spielt also eine ziemlich grosse Rolle ob das Zeug robust genug ist ;-) [...] Wie du richtig bemerkst sind EMV, Temp. range und Vibrationsfestigkeit entscheidende Punkte. Die mechanischen Probleme haben wir grösstenteils gelöst. [...] So long::Bernhard
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.