Hallo zusammen, ich bin in diesem Gebiet leider nicht ganz so erfahren. Ich bräuchte einen AUTOMOTIV (da der uC min. 10Jahre Verfügbar ist) 16Bit uC mit: - CAN-Schnittstelle - min. 10AD Eingänge/Ausgänge - ASC - JTAG Dies soll nämlich für eine Steuerungselektronik/Leistungelektronik für ein Pedelec werden. Was jedoch GANZ WICHTIG ist: -----> ES SOLL MIT EINEM FREE-COMPILER komilierbar sein z.B. GNU oder GTC Compiler. Hat jemand von euch eine Idee bzw. kennt einer von euch welchen uC ich am besten nehmen soll? Am liebsten wäre es, wenn es ein uC gibt den man oft benutzt wurde und dementsprechend viel Hilfe im Forum bekommt. Ich bedanke mich jetzt schon ganz ganz herzlich für die hilfreichen Beiträge von euch. Wenn ihr mehr Details braucht kann ich es gerne schreiben. Freunliche Grüße Fab
Hallo, schau dir die AVR32U3C an (hat sogar zusätlich noch Floating Point Unit an Board). das AVR Studio 6 ist eine kostenlose Entwicklungsumgebung, welche den GNU Compliler verwendet. mfg DerDan
Fab L. schrieb: > Ich bräuchte einen AUTOMOTIV (da der uC min. 10Jahre Verfügbar ist) > 16Bit uC mit: gingen auch 32 Bit? Da hättest du diverse ARM implementierung zur auswahl > Dies soll nämlich für eine Steuerungselektronik/Leistungelektronik für > ein Pedelec werden. Stückzahl über 10 Jahre? > Was jedoch GANZ WICHTIG ist: > -----> ES SOLL MIT EINEM FREE-COMPILER komilierbar sein z.B. GNU oder > GTC Compiler. Bei AUTOMOTIV Stückzahlen spielen Kosten für Compiler/IDE/debugger so gut wie keine rolle.
Danke für die Antworten! Also im Moment habe ich einen 16Bit Infineon drauf, jedoch möchte ich ein Redesign der kompletten Platine durchführen. Ich möchte nur ein Automotiv uC haben, damit ich ihn immer nachbestellen könnte. Denn ich habe im Moment das Problem, das der uC nicht mehr lieferbar ist, deswegen möchte ich einen Automotiv uC haben. Kosten spielen hierbei leider eine grpße Rolle, deswegen sollten alle Compiler & Debugger nichts kosten. Es ist nur ein Prototyp, deswegen müssen die auch alle free sein. Es wäre mir auch am liebsten, wenn es schon viele Beispielprogramme vorhanden sind, denn ich bin Programmiertechnisch nicht gerade der Erfahrenste (Anfänger). Das Programm wurde für ein 16Bit Infineon geschrieben, jedoch mit DaveDrive (Code wurde generiert)... spielt es eine große Rolle zwischen 16 & 32Bit? Also Programier technisch?? Was sind den ARM-Implementierungen?? Danke im voraus.
Diverse Hersteller haben für einzelne Controller Longlife Programme. Das ist nicht nur für automotive Kunden sondern in vielen Industriebereichen wichtig. Wo nachschauen weis ich aber grad nicht auswendig. viel Erfolg Hauspapa
Hat da keiner gute Wertvolle Tipps ?
Fab L. schrieb: > Ich möchte nur ein Automotiv uC haben, damit ich ihn immer nachbestellen > könnte. Nur dafür? Oder auch automotiven Temperaturbereich etc.?
der AVR32 UC3C ist in automotive verfügbar, wobei für Atmel ARM gibt es 12Jahre Verfügbarkeitsgarantie vom Hersteller das heißt du kriegst hier auch einen recht kleineren CortexM3. beide habn kostenlosen C/C++ Compiler im AtmelStudio 6 Was willst Du mehr?
Temperaturbereich ist für meine Anwendung irrelevant. AVR32 UC3C hört sich nicht schlecht an, wenn man dafür kostenlose Tools gibt. Gibt es dafür auch Code Beispiele? Denn im vorherigen uC habe ich es mit dem DaveDriveKit vom Infineon, den Code Generieren lassen, nun weis ich jedoch nicht ob es genug Hilfen und Code-Beispiele gibt die mich da weiterbringen können. z.B. PWM Signal generieren, CAN verbindungen etc... Vielen Dank für die netten Antworten
Fab L. schrieb: > Denn im vorherigen uC habe ich es mit dem DaveDriveKit vom Infineon, den > Code Generieren lassen, nun weis ich jedoch nicht ob es genug Hilfen und > Code-Beispiele gibt die mich da weiterbringen können. Gibt es, steht i.d.R. bei Atmel sogar schon in den Datenblättern (wenn auch sehr rudimentär). Allerdings wirst Du nicht drumherum kommen, Dich in den neuen µC einzuarbeiten. Eine Korrespondenz zu "Dave" hab ich bisher für Atmel und PIC aber noch nicht gesehen.
Ein langlebiger Controller wird sicher auch der STM32 sein. Den gibt es in über 250 Variationen und gleiche Gehäuse sind zueinander nahezu Pinkompatibel (siehe Doku). Drin ist ein Cortex-M3 oder M4 den man mit GCC und vielen kostenlosen Entwicklungsumgebungen übersetzen kann. Zudem gibt es hier im Forum und im www sehr viele Beispiele und Hilfen. Mit bis zu 168MHz, FPU und 1MB Flash (2MB kommen auch bald) wirst Du damit für die Zukunft garantiert gerüstet sein. PS: Lese in dem Artikel: STM32
Markus Müller schrieb: > Ein langlebiger Controller wird sicher auch der STM32 sein. Den gibt > es in über 250 Variationen und gleiche Gehäuse sind zueinander nahezu > Pinkompatibel (siehe Doku). > Drin ist ein Cortex-M3 oder M4 den man mit GCC und vielen kostenlosen > Entwicklungsumgebungen übersetzen kann. > Zudem gibt es hier im Forum und im www sehr viele Beispiele und Hilfen. > > Mit bis zu 168MHz, FPU und 1MB Flash (2MB kommen auch bald) wirst Du > damit für die Zukunft garantiert gerüstet sein. > > PS: Lese in dem Artikel: STM32 Ja da hast du recht, die STM32 habe ich mir auch angeschaut! Die sind echt nicht schlecht, aber an sich brauche ich nicht so Leistungsstarke uC für mein Projekt :) Im großen und ganzen möchte ich eigt einen uC, wo ich im Netz ganz viele Sachen wie CODE etc. finden kann, da ich kein Profi in dem Gebiet bin und die müssen natürlich noch lange Verfügbar sein (min.5 Jahre) ... Ich schau es mir mal genauer an danke... PS. Bei weiteren Antworten und Anregungen würde ich mich sehr freuen
Bronco schrieb: > Fab L. schrieb: >> Denn im vorherigen uC habe ich es mit dem DaveDriveKit vom Infineon, den >> Code Generieren lassen, nun weis ich jedoch nicht ob es genug Hilfen und >> Code-Beispiele gibt die mich da weiterbringen können. > > Gibt es, steht i.d.R. bei Atmel sogar schon in den Datenblättern (wenn > auch sehr rudimentär). > Allerdings wirst Du nicht drumherum kommen, Dich in den neuen µC > einzuarbeiten. > Eine Korrespondenz zu "Dave" hab ich bisher für Atmel und PIC aber noch > nicht gesehen. Leider habe ich da auch nichts passendes gefunden !
Nimm einen uC von Texas Instruments, die haben eine non-obsolence policy. Gruss, Anton
>aber an sich brauche ich nicht so Leistungsstarke uC für mein Projekt :)
Das ist eben der Trick an der Sache, der wird garantiert gut
funktionieren. Auch wenn man mal ein nächstes Projekt macht, in dem man
mehr braucht, dann hat man das einfach schon und man kann die
aufgebauten Quellen wieder weiter verwenden >> Zeitersparnis.
Und kosten die nahezu gleich viel wie die "kleinen".
Code-Beispiele findest Du zur Genüge hier: http://www.mikrocontroller.net/forum/codesammlung Allerdings höre ich immer mehr heraus, daß Du lieber einen Grundkurs in hardwarenahem Programmieren suchst. Vielleicht solltest Du lieber nach einem µC suchen, für denen es bereits fertige Bibliotheken zur Hardware-Kapselung gibt, dann mußt Du Dich nicht mit Register&Co auseinandersetzen. Meines Wissens gibt es sowas für den ARM.
Markus Müller schrieb: >>aber an sich brauche ich nicht so Leistungsstarke uC für mein Projekt :) > > Das ist eben der Trick an der Sache, der wird garantiert gut > funktionieren. Auch wenn man mal ein nächstes Projekt macht, in dem man > mehr braucht, dann hat man das einfach schon und man kann die > aufgebauten Quellen wieder weiter verwenden >> Zeitersparnis. > Und kosten die nahezu gleich viel wie die "kleinen". Klingt sehr logisch, wenn man sich es erst da durch gekämpft hat :)
Fab L. schrieb: > Es wäre mir auch am liebsten, wenn es schon viele Beispielprogramme > vorhanden sind, denn ich bin Programmiertechnisch nicht gerade der > Erfahrenste (Anfänger). wenn Pedelec heißt dass Du einen brushless Motor ansteuern willst dann will ich es deutlich sagen: vergiss es
Bronco schrieb: > Code-Beispiele findest Du zur Genüge hier: > http://www.mikrocontroller.net/forum/codesammlung > > Allerdings höre ich immer mehr heraus, daß Du lieber einen Grundkurs in > hardwarenahem Programmieren suchst. > Vielleicht solltest Du lieber nach einem µC suchen, für denen es bereits > fertige Bibliotheken zur Hardware-Kapselung gibt, dann mußt Du Dich > nicht mit Register&Co auseinandersetzen. Meines Wissens gibt es sowas > für den ARM. Ja genau da hast du mich durchschaut ! Genau sowas suche ich auch!!!
>Bernd schrieb: > wenn Pedelec heißt dass Du einen brushless Motor ansteuern willst dann > will ich es deutlich sagen: vergiss es Ob Pedelec oder nicht Pedelec ... Du hast recht, ich bräuchte Beispiel-Programme für die Ansteuerung eines BLDC Motors Also gibt es da keine?
Der STM32 hat Timer für Motion Control drin, einfach ein wenig Doku lesen, ich denke Du kommst schon klar damit. Damit kann man eine direkte Ansteuerung der H-Brücke incl. Totzeiten für das Umschalten programmieren. Von ST gibt es jede Menge Beispiele für die Timer Nutzung.
Fab L. schrieb: > Ob Pedelec oder nicht Pedelec ... Du hast recht, ich bräuchte > Beispiel-Programme für die Ansteuerung eines BLDC Motors > > Also gibt es da keine? Die Compiler-Hersteller haben meistens große Beispielcodesammlungen auf ihrer Homepage, die man sich auch ohne Registrierung da kostenlos herunter laden kann. Man möchte die User ja nicht voll im Regen stehen lassen. Zum Beispiel Keil. Habe da schon einiges in eigenen Anwendungen verwurstelt, überarbeitet, angepaßt, z.B. eine CAN-Software für die LPC2000 von NXP. Die LPC2000 sind inzwischen auch 8 Jahre alt. Auf einem Seminar in der Anfangszeit nannte ein Produktmanager von NXP noch ungefähr wenigstens 7 Jahre. Herr Teufel, der ist hier gelegentlich auch mal im Forum unterwegs. Wir wollten mit einem neuen Typen ja nicht schon nach 2 Jahren wieder ein Redesign. Aussterben tun die in den nächsten 2 Jahren bestimmt auch nicht. Über einen frei verfügbaren Compiler weiß ich nicht so genau Bescheid, sollte es aber geben.
LPC2000 = ARM7 Core >> GCC geht. Aber wenn schon einen aus der NXP Reihe, dann lieber den LPC17xx (= Cortex-M3 = Jünger und moderner und somit langlebiger >> auch GCC so wie auch der STM32 weil da auch ein Cortex-M4/M4 drin arbeitet).
>Markus Müller schrieb: > Der STM32 hat Timer für Motion Control drin, einfach ein wenig Doku > lesen, ich denke Du kommst schon klar damit. Damit kann man eine direkte > Ansteuerung der H-Brücke incl. Totzeiten für das Umschalten > programmieren. > > Von ST gibt es jede Menge Beispiele für die Timer Nutzung. Habe eine Ansteuerung über eine B6-Schaltung. Ich lese mir mal ein bisschen die Doku an ... Danke
Markus Müller schrieb: > LPC2000 = ARM7 Core >> GCC geht. Aber wenn schon einen aus der NXP > Reihe, dann lieber den LPC17xx (= Cortex-M3 = Jünger und moderner und > somit langlebiger >> auch GCC so wie auch der STM32 weil da auch ein > Cortex-M4/M4 drin arbeitet). Ja, irgend was mit THUMB oder THUMB2 beispielsweise. Ich hatte länger nichts mehr mit den ARMen zu tun, meine Typen waren damals die LPC21xx und LPC22xx. In der Software ständiges Umschalten zwischen ARM und THUMB, weil wir Codegröße von Anfang an sparen wollten, wo es möglich war, das war gelegentlich etwas nervig. Aber man kann sich bei ARM7 ja auch völlig auf einen Typ fest legen, auch kein Problem. Immerhin wurde diese Flexibilität ja angeboten. Wer die Wahl hat, hat eben die Qual. Auch haben die LPC durchgängig 32-bit-Register bei allen Peripherals. Das war bei anderen ARM7-Anbietern nicht immer so, und dann nervig.
schon interessantes Topic. Du willst einen guten Controller auch lange Sicht lieferbar haben, hast "keine Ahnung" (vom Programmieren und von Mikrocontrollern) und es darf nichts kosten. Ausserdem soll es schon "alles fertig" geben, dass du deine Software nur noch zusammenzubauen brauchst. Sowas schliesst sich meist aus. Wenn die Arbeitszeit Geld kostet (oder du knapp an Zeit bist), ist es manchmal günstiger, eine IDE mit Debugger und vielen Codebeispielen sowie Libraries (Ethernet, USB, Filesystem, RTOS, ...) von einem Anbieter zu kaufen, da du nur dann tatsächlich deine Applikation zu grossen Teilen aus den mitgelieferten Beispielen innerhalb kürzester zeit (innerhalb weniger Stunden) zusammenstückeln kannst. Suchst du dir alles selbst aus verschiedensten offenen Quellen zusammen, hast du eine grössere Fehlerrate in deiner Software und brauchst einiges an Zeit, bis du das alles zusammengeschustert hast.
> Random ... schrieb: > schon interessantes Topic. > Du willst einen guten Controller auch lange Sicht lieferbar haben, hast > "keine Ahnung" (vom Programmieren und von Mikrocontrollern) und es darf > nichts kosten. Ausserdem soll es schon "alles fertig" geben, dass du > deine Software nur noch zusammenzubauen brauchst. > > Sowas schliesst sich meist aus. Wenn die Arbeitszeit Geld kostet (oder > du knapp an Zeit bist), ist es manchmal günstiger, eine IDE mit Debugger > und vielen Codebeispielen sowie Libraries (Ethernet, USB, Filesystem, > RTOS, ...) von einem Anbieter zu kaufen, da du nur dann tatsächlich > deine Applikation zu grossen Teilen aus den mitgelieferten Beispielen > innerhalb kürzester zeit (innerhalb weniger Stunden) zusammenstückeln > kannst. > > Suchst du dir alles selbst aus verschiedensten offenen Quellen zusammen, > hast du eine grössere Fehlerrate in deiner Software und brauchst einiges > an Zeit, bis du das alles zusammengeschustert hast. Programmieren kann ich, ist jedoch nicht ganz so mein Gebiet ... Das einzige was ich nur bräuchte, wäre ein Code-Beispiel wie man PWM Signale für die B6-Schaltung der dann natürlich die Hallsensoren abfragen muss etc. ! Da habe ich die meisten Probleme ... der Rest könnte ich im großen und ganzen. Aber du hast Recht, es geht meist schneller es selber zu programmieren, anstatt 1000 offene Quellen sich zusammen zu frickeln.
Fab L. schrieb: > Also im Moment habe ich einen 16Bit Infineon drauf, jedoch möchte ich > ein Redesign der kompletten Platine durchführen. Renesas RL78 oder V850. Dazu KPIT GNU Tools. > Ich möchte nur ein Automotiv uC haben, damit ich ihn immer nachbestellen > könnte. Denn ich habe im Moment das Problem, das der uC nicht mehr > lieferbar ist, deswegen möchte ich einen Automotiv uC haben. Vorsicht, die lange Liefergarantie hast Du nur, wenn Du mit dem Hersteller auch einen enstprechenden Vertrag geschlossen hast. Als "normaler" Kunde, der eventuell sogar über einen Distributor seine Kleinmengen bestellt, wirst Du nach dem "not recommended for new designs" - Termin auch keine Bauteile mehr bekommen. Es kann gut sein, dass der Halbleiterhersteller die mit seinen Kunden vereinbarten Liefermengen auf Halde produziert und danach die Fab zugemacht hat. Also, frag auf jeden Fall beim Hersteller direkt nach und kauf das Zeug nicht einfach bei RS.
> om pf schrieb: > Vorsicht, die lange Liefergarantie hast Du nur, wenn Du mit dem > Hersteller auch einen enstprechenden Vertrag geschlossen hast. Als > "normaler" Kunde, der eventuell sogar über einen Distributor seine > Kleinmengen bestellt, wirst Du nach dem "not recommended for new > designs" - Termin auch keine Bauteile mehr bekommen. Es kann gut sein, > dass der Halbleiterhersteller die mit seinen Kunden vereinbarten > Liefermengen auf Halde produziert und danach die Fab zugemacht hat. > > Also, frag auf jeden Fall beim Hersteller direkt nach und kauf das Zeug > nicht einfach bei RS. Sehr gut zu wissen danke!!
Fab L. schrieb: >> Gibt es, steht i.d.R. bei Atmel sogar schon in den Datenblättern (wenn >> auch sehr rudimentär). >> Allerdings wirst Du nicht drumherum kommen, Dich in den neuen µC >> einzuarbeiten. >> Eine Korrespondenz zu "Dave" hab ich bisher für Atmel und PIC aber noch >> nicht gesehen. > > Leider habe ich da auch nichts passendes gefunden ! Warum nicht bei Dave bleiben und einen der neueren XMC4000 nehmen (Infineon wirbt auch da mit "long-term supply"). Ähnliche (habe Dave (und HAL scnr) schon lange nicht mehr angesehen) Tools gibt es bspw. von SiLabs (AppBuilder) für ihre Cortex-M3 http://www.silabs.com/products/mcu/Pages/32-bit-mcu-software.aspx (restliche IDE ist Eclipse, Compiler der gcc) Statt der erwähnten Renesas-Teile wären auch die RX600/RX200 interessant, da gäbe es den Peripheral Driver Generator
Versuchs damit http://www.ti.com/ww/en/launchpad/stellaris_head.html?DCMP=stellaris-launchpad&HQS=stellaris-launchpad 32-bit ARM Architektur mit CAN und allem Pipapo. Kann man als Piggyback auf die Platine mit der Peripherieelektronik stecken. Billiger gehts nimmer.
Fab L. schrieb: > Kosten spielen hierbei leider eine grpße Rolle, deswegen sollten alle > Compiler & Debugger nichts kosten. Es ist nur ein Prototyp, deswegen > müssen die auch alle free sein. Prototyp ? Das heißt eventuell soll da auch mal etwas verkaufbares für den Straßenverkehr draus werden ? In dem Fall besorge dir einmal die Iso 26262, und lerne die mal. Wenn du dich daran hältst wirst du in etwa einem Jahr soweit sein, den Anforderungskatalog für den µC und den Rest der Platine zusammenzustellen. Und bevor jetzt das Geschrei wegen unnützer Normen und Bürokratie losgeht. Es ist eben so!!
Fab L. schrieb: > Hat da keiner gute Wertvolle Tipps ? Aber ja doch. Geh in ein paar Wochen zur Embedded nach Nürnberg und dort zu Fujitsu und laß dir von denen ne Scheibe geben, wo Softune nebst Compilern drauf ist. Ist in Europa kostenlos und die Fujitsu-Chips (sowohl die 16 Bitter als auch die 32 Bitter) sind langzeitverfügbar, da das meiste davon eben für den Auromobilbau ist. W.S.
Habe mich Anfangs sehr für den STM32Fx interessiert, jedoch darf es leider kein 32Bit sein, denn für meine Anwendung ist es viel zu überdimensioniert. Kennt keiner einen 16-Bit uC der das alles erfüllt: Ich bräuchte einen AUTOMOTIV (da der uC min. 10Jahre Verfügbar sein muss, Temp.Bereich irrelevant) - CAN-Schnittstelle - min. 15AD Eingänge/Ausgänge - PWM - JTAG - wenn möglich BLDC mit Hall Sensoren tauglicher bzw. anwendbarer uC Danke im Voraus Freundliche Grüße fab
Hallo Fab L,
> Denn ich habe im Moment das Problem, das der uC nicht mehr
lieferbar ist
Welchen C167-Typ benötigst Du genau, ich habe noch ein paar Hundert.
PIC24 > jedoch darf es leider kein 32Bit sein, denn für meine Anwendung ist es > viel zu überdimensioniert. Verstehe ich jetzt nicht. Macht doch alles der C-Compiler.
C167 schrieb: > Hallo Fab L, > >> Denn ich habe im Moment das Problem, das der uC nicht mehr > lieferbar ist > > Welchen C167-Typ benötigst Du genau, ich habe noch ein paar Hundert. Weis leider nicht was du mit c167-Typ meinst... aber es ist glaub ich irrelevant... Was jedoch wichtig ist, ist das es mit Freeware laufen soll, also ohne kostenpflichtige Software
> Weis leider nicht was du mit c167-Typ meinst... aber es ist glaub ich irrelevant... > Also im Moment habe ich einen 16Bit Infineon drauf, jedoch möchte ich > ein Redesign der kompletten Platine durchführen... > Denn ich habe im Moment das Problem, das der uC nicht mehr > lieferbar ist, deswegen möchte ich einen Automotiv uC haben. Wenn Du einen 16Bit Infineon µC hast, dann ist es wohl ein Controller aus der C167-Familie. So wie ich Dich verastanden habe, suchts Du einen neuen µC, da Du den "alten" nicht mehr kaufen kannst. Also, welchern µC hat Du bisher im Einsatz - genaue Typbezeichnung z.B SAF-C167CR-LM. Wenn Dein bisheriges Design nicht an Grenzen stößt, ist es das einfachste dabei zu bleiben und nur für Neuentwicklungen den Controller zu wechseln.
Fab L. schrieb: > jedoch darf es > leider kein 32Bit sein, denn für meine Anwendung ist es viel zu > überdimensioniert. Sagt wer? Überleg lieber mal, was Dich mehr Geld kostet: die Hardware oder die Entwicklungszeit? Erst wenn Du richtig hohe Stückzahlen hast, schlägt der Stückpreis der Hardware zu, ansonsten ist eher die Entwicklunszeit der Kostentreiber. Hier gilt: Ein einfach zu programmierender 32-Bitter kann durchaus deutlich günstiger sein als ein schwieriger 8-Bitter. Halbwegs leistungsfähige µCs (z.B. mit CAN) haben immer eine gewisse Grundkomplexität (z.B. DMA-Kanäle für den CAN), in die man sich erst einmal einarbeitne muß, wenn man nicht gerade so ein Tool wie DAVE hat. Da macht es aber auch keinen Unterschied mehr, ob es ein 16-Bitter oder 32-Bitter ist.
C167 schrieb: >> Weis leider nicht was du mit c167-Typ meinst... aber es ist glaub ich > irrelevant... > >> Also im Moment habe ich einen 16Bit Infineon drauf, jedoch möchte ich >> ein Redesign der kompletten Platine durchführen... >> Denn ich habe im Moment das Problem, das der uC nicht mehr >> lieferbar ist, deswegen möchte ich einen Automotiv uC haben. > > Wenn Du einen 16Bit Infineon µC hast, dann ist es wohl ein Controller > aus der C167-Familie. > > So wie ich Dich verastanden habe, suchts Du einen neuen µC, da Du den > "alten" nicht mehr kaufen kannst. > > Also, welchern µC hat Du bisher im Einsatz - genaue Typbezeichnung z.B > SAF-C167CR-LM. > Wenn Dein bisheriges Design nicht an Grenzen stößt, ist es das > einfachste dabei zu bleiben und nur für Neuentwicklungen den Controller > zu wechseln. Ach so... da hast du vollkommen recht! Ich hatte eine XE164-F96F66L
Bronco schrieb: > Fab L. schrieb: >> jedoch darf es >> leider kein 32Bit sein, denn für meine Anwendung ist es viel zu >> überdimensioniert. > Sagt wer? > > Überleg lieber mal, was Dich mehr Geld kostet: die Hardware oder die > Entwicklungszeit? > Erst wenn Du richtig hohe Stückzahlen hast, schlägt der Stückpreis der > Hardware zu, ansonsten ist eher die Entwicklunszeit der Kostentreiber. > Hier gilt: Ein einfach zu programmierender 32-Bitter kann durchaus > deutlich günstiger sein als ein schwieriger 8-Bitter. > > Halbwegs leistungsfähige µCs (z.B. mit CAN) haben immer eine gewisse > Grundkomplexität (z.B. DMA-Kanäle für den CAN), in die man sich erst > einmal einarbeitne muß, wenn man nicht gerade so ein Tool wie DAVE hat. > Da macht es aber auch keinen Unterschied mehr, ob es ein 16-Bitter oder > 32-Bitter ist. Natürlich das verstehe ich voll und ganz, doch leider hat man auf der Arbeit Vorgaben, die man einhalten muss. Deswegen sollte es höchstens ein 16-Bitter sein...
C167 schrieb: > So wie ich Dich verastanden habe, suchts Du einen neuen µC, da Du den > "alten" nicht mehr kaufen kannst. GENAU SO IST ES!
Fab L. schrieb: > Natürlich das verstehe ich voll und ganz, doch leider hat man auf der > Arbeit Vorgaben, die man einhalten muss. > > Deswegen sollte es höchstens ein 16-Bitter sein... Sagt wer? Steht das im Lastenheft/Pflichtenheft so drinn oder ist es Deine Einschätzung oder die Deines Chefs?
Bei Freescale kannst Du nachschauen, welcher Baustein im sog. Longevity-Programm drin ist und ab dem angagebenen Datum für 10 oder 15 Jahre noch sicher produziert wird: http://www.freescale.com/webapp/sps/site/overview.jsp?code=PRDCT_LONGEVITY_HM&fsrch=1&sr=1
für den UC3 gibt es folgende appnote und bsp: AVR32710: Space Vector Modulation for Motor Control using 32-bit AVR UC3 (file size: 1047214, 19 pages, revision B, updated: 08/2010) This application note is a 32-bit AVR UC3 stand-alone application which computes real-time Space Vector Modulation on a Brushless DC Motor. This application is designed to work with the EVK1100 evaluation kit. Ansonsten hast doch hier alle Bauteile und welche Appnote es gibt zu verschiedenen Motor APplikationen: http://www.atmel.com/applications/homeappliances/motor_control/default.aspx Der größte Teil davon ist auch in automotive erhältlich...
Fab L. schrieb: > Ich möchte nur ein Automotiv uC haben, damit ich ihn immer nachbestellen > könnte. Denn ich habe im Moment das Problem, das der uC nicht mehr > lieferbar ist, deswegen möchte ich einen Automotiv uC haben. Im Endeffekt bringt dir ein Automotive-Part wenig bis garnichts solange du nicht direkt beim Hersteller abnimmst. > Kosten spielen hierbei leider eine grpße Rolle, deswegen sollten alle > Compiler & Debugger nichts kosten. Es ist nur ein Prototyp, deswegen > müssen die auch alle free sein. Kosten in der Entwicklung enstehen seltenst durch Lizenzkosten. Ausser der Entwickler verdient kein Geld. > Es wäre mir auch am liebsten, wenn es schon viele Beispielprogramme > vorhanden sind, denn ich bin Programmiertechnisch nicht gerade der > Erfahrenste (Anfänger). Oha, dann viel Spass mit Frickeltools. Versuch doch lieber erstmal mit den Freemium-Tools eines kommerziellen Anbieters anzufangen. > Das Programm wurde für ein 16Bit Infineon geschrieben, jedoch mit > DaveDrive (Code wurde generiert)... spielt es eine große Rolle zwischen > 16 & 32Bit? Also Programier technisch?? > Was sind den ARM-Implementierungen?? Ja, es besteht ein riesiger Unterschied zwischen einem C166 und einem ARM Mikrocontroller. Den 166 mit seinem dutzend Speichermodellen und Datapagepointern etc pp ist nervig zu beherrschen. Ein ARM hat einen linearen 4GB Addressraum in dem alles lebt. Ein sehr einfaches Programmiermodell behaupte ich mal. Zudem hast du meist deutlich mehr Rechenleistung. Mehr Rechenleistung im MotorControl bedeutet sauberere Regelung, weniger Verbrauch, mehr Zeit für Safety etc... An deiner Stelle würde ich mal einen STM32 ins Auge fassen. ST bietet hier auch eine aehnliche MotorControl-Bibliothek. Der Chip basiert auf einem ARM Cortex-M3 oder M4. > Danke im voraus. Keine Ursache
Fab L. schrieb: > C167 schrieb: >> So wie ich Dich verastanden habe, suchts Du einen neuen µC, da Du den >> "alten" nicht mehr kaufen kannst. > > > GENAU SO IST ES! Die XC2000'er Serie ist binärkompatibel und wird von Infineon in großen Stückzahlen verkauft. fchk
>Weis leider nicht was du mit c167-Typ meinst... aber es ist glaub ich >irrelevant... >Was jedoch wichtig ist, ist das es mit Freeware laufen soll, also ohne >kostenpflichtige Software Ich hatte letztes Jahr ein Vorstellungsgespräch bei einem Automotive-Zulieferer. Da kam auch das Thema GCC auf, weil in meinen Unterlagen eben "Erfahrung mit GCC" gestanden ist. Also, die Herschaften wollten überhaupt nix von der freien Software im Automotive-Bereich wissen, die waren richtig negativ dem gegeüber eingestellt und sahen den Einsatz solcher Werkzeuge als ein "nicht kalkulierbares Restrisiko" an.
Ich wuerd Automotive vergessen, wenn es nur um Lieferbarkeit geht. Man kann ja ein paar Stueck an Lager legen.
Nimm eine TI 28xx Das sind richtige 16bitter. Die kennen nicht einmal Byte, selbst der Speicher wird 16bit breit angesprochen. Alles andere kann man vergessen!
Fab L. schrieb: > Ich bräuchte einen AUTOMOTIV Du scheinst mir ziemlich beratungsresistent zu sein. Also, meinen ernstgemeinten Tip mit Fujitsu kennst du, nu mach mal oder laß es halt bleiben. W.S.
Fab L. schrieb: > Ich hatte eine XE164-F96F66L Verstehe ich nicht, die meisten XE164 Typen sind noch in Production. Bastler?
Fab L. schrieb: > Was jedoch GANZ WICHTIG ist: > > ES SOLL MIT EINEM FREE-COMPILER komilierbar sein Free as in freedom or free as in free beer? Darf es freie Software sein? Da gibt durchaus Automotive-Ports von GCC, etwa Infineon Tricore. Oder wie in Freibier? Darf nix kosten?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.