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.
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.
