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.