Hallo Liebe µC Gemeinde, ich mache zurzeit ein freiberufliches Projekt, wo die wichtigste Anforderung ist, dass der Mikrocontroller mindestens 10 Jahre verfügbar ist und hohe Temperaturen verträgt. Nach Recherche ist mir bewusst, dass da nur Automotive Chips in Frage kommen (das steht auch schon jetzt mit dem Kunde fest!). Ich habe mir folgende mögliche ausgesucht: - S32 von NXP - SPC5 von ST - TriCore Aurix von Infineon - SAM E5x und SAM E70 von Atmel Alle Chips können das von mir geforderte mit Leichtigkeit(bezüglich Geschwindigkeit, CAN-Bus, ADC-Auflösung). Was mir jedoch wichtig ist, ist die Verbreitung in Communities, die Handlichkeit/Performance der Entwicklungssoftware und verfügbaren Libraries. Kennt sich jemand in dem Automotive Bereich aus und kann was dazu sagen? (oder kennt einen alternativen Chip bei dem das alles stimmt?) Grüße und Danke für eure Erfahrung, Manfred
Die ARM-basierten µC hätten zumindest den Vorteil, dass du verbreitete Open-Source-Tools (Compiler, IDE, Debugger) nutzen kannst, sofern die Hersteller-Bibliotheken damit funktionieren. Sicherheitskritisches wird man damit aber wohl nicht machen können.
Ich würde sehr dringend erst mal abklopfen was für Anforderungen der Kunde an die Softwareentwicklung hat. Von da ausgehen kannst du dir Controller raussuchen deren Compiler du dir als Freiberufler leisten kannst.
Hi
>http://ww1.microchip.com/downloads/en/De
Das ist aber auch nicht mehr ganz taufrisch: • Atmel Studio 6
MfG Spess
spess53 schrieb: > Hi > >>http://ww1.microchip.com/downloads/en/De > > Das ist aber auch nicht mehr ganz taufrisch: • Atmel Studio 6 > > MfG Spess Das ist Medizintechnik. Da ist man immer hindendran. Der Hintergrund ist, dass der Kram zertifiziert werden muss, und das ist teuer. Das tut man nicht, weil das neue Tool bunter blinkt, sondern nur wenn man muss.
Würde noch die Kinetis EA Serie von ehemals Freescale, jetzt NXP einwerfen. KEAZ64 und KEAZ128 bieten beide auch CAN. Manfred M. schrieb: > Nach Recherche ist mir bewusst, dass > da nur Automotive Chips in Frage kommen (das steht auch schon jetzt mit > dem Kunde fest!). Warum eigentlich? Einen erweiterten Temperaturbereich bekommst du doch auch mit "industrial grade", oder etwa nicht?
Hi >Das ist Medizintechnik. Da hat der Link nicht geklappt. Ich meinte den den aus PeDas Beitrag: Beitrag "Re: Verbreitung von Automotive µC" Und das ist Automobiltechnik. MfG Spess
Test schrieb: > Von da ausgehen kannst du dir > Controller raussuchen deren Compiler du dir als Freiberufler leisten > kannst. Als Freiberufler sollte man sich da nichts leisten müssen, sondern vom Kunden bezahlen lassen.
spess53 schrieb: > Hi > >>Das ist Medizintechnik. > > Da hat der Link nicht geklappt. Ich meinte den den aus PeDas Beitrag: > > Beitrag "Re: Verbreitung von Automotive µC" Ah, ok :-) Jedenfalls zum Thema noch: Abseits vom Automotive-Sektor gibt es schon noch Möglichkeiten. Mein Arbeitgeber ist, sagen wir mal, im gewerblichen Sektor unterwegs. Entsprechend laufen die Produkte sehr lange (teils über 20 Jahre), und Langelebigkeit und Abkündigungen sind bei uns große Themen. Wir haben auch ST-Controller im Einsatz. ST hat viele Controller im Longevity Program für 10 Jahre, beginnend ab Januar: https://www.st.com/content/st_com/en/about/quality-and-reliability/product-longevity.html Rücksprache mit dem Distributor oder ST-FAE ist aber empfehlenswert, die können bei der Wal der korrekten Derivate aus dem STM32-Dschungel helfen. Es gibt ja balt >1000 Derivate der Serie, nicht jedes davon ist ein Highrunner. Was auch noch ginge, sind Microchip PIC. Da wurde bisher - soweit mir bekannt - noch gar nichts abgekündigt. Wir haben einige uralte Platinen mit PICs noch in Produktion, und zumindest den Controller (ein PIC16C715) ist noch erhältlich. Und das Teil ist wirklich sehr als ;-) Es muss ja kein 8-Bitter sein, PIC32 gitbs ja auch.
taufrisch schrieb: > Entsprechend laufen die Produkte sehr lange (teils über 20 Jahre), und > Langelebigkeit und Abkündigungen sind bei uns große Themen. Alternative: Software mittels einer Hardwareabstraktion und/oder RTOS entwickeln, und immer den aktuell billigsten Controller nehmen. Jedes Mal wenn einer abgekündigt wird fällt dann etwas Portierungsaufwand an, aber dadurch hat man mehr Freiheit bei der Controllerwahl und kann eben ggf. Einkaufskosten sparen. Was in Summe wirtschaftlicher ist muss man dann evaluieren...
Niklas G. schrieb: > taufrisch schrieb: >> Entsprechend laufen die Produkte sehr lange (teils über 20 Jahre), und >> Langelebigkeit und Abkündigungen sind bei uns große Themen. > > Alternative: Software mittels einer Hardwareabstraktion und/oder RTOS > entwickeln, und immer den aktuell billigsten Controller nehmen. Jedes > Mal wenn einer abgekündigt wird fällt dann etwas Portierungsaufwand an, > aber dadurch hat man mehr Freiheit bei der Controllerwahl und kann eben > ggf. Einkaufskosten sparen. Was in Summe wirtschaftlicher ist muss man > dann evaluieren... Hmm, das klingt theoretisch toll. Praktisch ist das eher so: Bei meinem Arbeitgeber beispielsweise sind die Stückzahlen mittel (wasweisich, ein paar wenige Tausend pro Jahr oder weniger), da müsstest du jedesmal die Platinen angreifen, wenn der Controller zu tauschen ist. Das macht Einmalkosten, schon in der Hardware. Dazu muss der Kram jedesmal durch die QS, wo halt auch noch Aufwand anfällt. Und EMV wird auch fällig, bei externen Prüfinstituten, das kostet auch "geringfügig" (aleine das bis zu 10k€). Weil weltweiter Verkauf. Die Host-Systeme müssen Firmware-Pakete für alle möglichen Controller mitschleppen, die Software muss erkennen was sie wo hineinzuspielen hat, kritische Fehler müssen dann in mehreren Projekten behoben werden. Ja gut, wenn das richtig gemacht ist, muss man nur "Compile" drücken, testen darf man trotzdem. Das alles ist Aufand, und ein paar zehntausend Euro Einmalkosten schlagen sich dann schon merklich im Endpreis nieder. Dazu das übliche Standard-Chaos: Manchen Code kann nur der Entwickler lesen, der die Firma schon vor 10 Jahren verlassen hat. Manchen Code muss man aus Kompatibilitätsgründen aus alten Projekten mitziehen, für Portierung hat man keine Zeit. Und gewachsen sind viele Projekte auch. Also wachsen, im Sinne von Unkraut oder Krebs. Und logischerweise: Für Pflege oder Portierung will niemand bezahlen.
taufrisch schrieb: > Praktisch ist das eher so: > Bei meinem Arbeitgeber beispielsweise sind die Stückzahlen mittel > (wasweisich, ein paar wenige Tausend pro Jahr oder weniger), da müsstest > du jedesmal die Platinen angreifen, wenn der Controller zu tauschen ist. > Das macht Einmalkosten, schon in der Hardware. Bei den Einmalkosten für die Zertifizierung hast du wohl recht aber beim Controllertausch muss man nicht zwangsläufig die Platine redesignen. Bei den großen Herstellern gibt es eigentlich immer Pin-kompatible Nachfolger. Bei ST kann man sogar so ziemlich jeden STM32 im LQFP48 durch einen beliebigen anderen im LQFP48 tauschen, selbst übergreifend über mehrere Familien, z.B. von F1 auf F3. Wenn sich dann die Platine nicht ändert ist auch die (Re-)Zertifizierung nicht mehr so wild, da man im Vorfeld sicher sein kann, dass das Design so durchgeht.
Christopher J. schrieb: > Bei ST kann man sogar so ziemlich jeden STM32 im LQFP48 > durch einen beliebigen anderen im LQFP48 tauschen, selbst übergreifend > über mehrere Familien, z.B. von F1 auf F3. Wenn sich dann die Platine > nicht ändert ist auch die (Re-)Zertifizierung nicht mehr so wild, da man > im Vorfeld sicher sein kann, dass das Design so durchgeht. Stimmt, und das ist ein relativ wichtiges Kriterium bei der Auswahl einer µC-Familie. Das Problem bei der Sache liegt aber oft im Detail. Wenn man viel µC interne Peripherie verwendet, was man heute oft tut, wird es dann oft schwierig. Weil sich die Derivate in kleineren Details unterscheiden. Ich habe z.B. schon die Komparatoren der F051 verwendet, da wirds dann später vermutlich eng mit Ersatz. Gerade die Verwendung von Peripherie ermöglicht aber oft tolle Konzepte. Wer das "Drop in Replacement" auch gut kann ist Microchip. Da kann man teils PIC16 durch PIC32 ersetzen. Es gibt quasi Standard Footprint für PICs.
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.