Hallo,
ich soll in der Firma einen neuen Mikrocontroller evaluieren. Bisher
hatten wir MPC555 eingesetzt (PowerPC), sowie 68HC08. Beides nicht so
die optimalen Controller für unsere Anwendung, wie ich finde. Der MPC
ist im BGA-Gehäuse - ich habe hier bereits einen grossen Stapel an
defekten Leiterplatten, die sich aufgrund dieses BGAs nicht reparieren
lassen (ja ich weiss, es gibt BGA-Rework-Stationen, aber die Kosten viel
Geld).
Der PowerPC wird in der Zentralen Steuerung eingesetzt - dort müssen
einige PWM-Werte berechnet werden anhand von Messdaten, die von
AD-Wandlern kommen etc. Zudem läuft ein TCP-Stack.
Die HC08 werden für Sensoren etc. eingesetzt - also abfragen von
Endschaltern, Auswerten von Tastern an einem Bedienpanel etc. Die ganzen
Controller sind über einen Bus miteinander vernetzt. Ich soll jetzt
einen neuen Controller evaluieren. Meiner Meinung nach wäre es schön,
wenn man dieselbe Architektur benutzen könnte für diese Sensoren, als
auch für die Zentrale Steuerung, da man dann nur noch einen neuen
Compiler und einen neuen Debugger beschaffen muss.
Sofort habe ich nun an ARM gedacht, denn einerseits gibt es da grosse
Brocken wie den AT91RM9200, die sich mit weit über 100 MHz takten lassen
und entsprechende Leistung bringen, als auch kleinere, wie die LPC2148
etc, welche es auch in einem QFP48 gibt. Zwar ist ein ARM in einem
solchen simplen Sensorknoten ein bisschen overkill, aber das macht ja
nichts - eventuell kann man dann bereits vor Ort eine gewisse
Aufbereitung von Messdaten etc. vornehmen. Besser als der HC08 ist es
auf jeden Fall.
Nun die Frage:
Ist ARM hier die richtige Wahl? Wir bauen damit Maschinen, die 15 Jahre
oder länger laufen sollen. Das heisst, die Prozessoren müssen nach
langer Zeit noch verfügbar sein.
Persönlich möchte ich wegkommen von dieser PowerPC-Geschichte, die sind
ziemlich hässlich zum Debuggen und Programmieren, und ausserdem meist
nur im BGA verfügbar - und sie kosten viel zu viel, für das was die
können.
Ich dachte beim Prozessor für die Zentralsteuerung so an einen LPC2468
oder AT91SAM ... irgendwas. Bei den Sensoren könnte ich mir sowas wie
LPC214x oder auch irgend einen Atmel vorstellen.
Was könnt ihr hierzu sagen, gibts ausser ARM noch andere Prozessoren,
die infrage kämen? Bitte nichts mit BGA.
Schön wäre es auch, wenn es eine CPU mit FPU drauf wäre - das würde noch
ein paar neue Möglichkeiten eröffnen, an die wir bisher noch gar nicht
zu denken wagten.
Auf jeden Fall brauchen wir viele Schnittstellen: UART, CAN, später
möchten wir evtl. was mit USB machen.
Bin mal gespannt, was ihr hierzu meint. Ich selber würde voll auf ARM7
oder 9 setzen, Cortex-M3 eher nicht, da dies meines Wissens noch eher
"kleine" Controller sind - ich brauche aber Massenhaft Flash, und
deshalb muss es einer mit externem Bus sein und viel internem Memory, wo
auch Code ausgeführt werden kann. Mein Chef meinte jedoch, nur ein
Controller, der in der Automobilbranche verwendet würde, sei lange genug
verfügbar - das mag sein, aber das würde unser Kriterium Nummer 1,
nämlich dass man überall denselben Prozessor verwenden kann, nicht
erfüllen (ein PowerPC in einem Sensorknoten macht wenig Sinn ;-)).
Tobias Plüss schrieb:> Mein Chef meinte jedoch, nur ein> Controller, der in der Automobilbranche verwendet würde, sei lange genug> verfügbar
Dann schau dich doch mal bei Infineon und TI um.
>Dann schau dich doch mal bei Infineon und TI um.
Ist das wirklich so? Werden ARMe in der Automobilindustrie auch
eingesetzt? Ich kenn mich da nicht so dolle aus. Zudem behaupte ich auch
mal, dass mir die 50 Timer, die ein solcher PowerPC anbietet, eh nix
nützen, denn ich hab sowieso noch einen FPGA auf meinem Board mit drauf
als IO-Knecht, weil dieser MPC555 zuwenig IOs bietet. Dann könnte man
PWM und anderes Timing-Gedöns ja auch gleich mit im FPGA machen.
Tobias Plüss schrieb:> gibts ausser ARM noch andere Prozessoren,> die infrage kämen? Bitte nichts mit BGA.> Schön wäre es auch, wenn es eine CPU mit FPU drauf wäre> Mein Chef meinte jedoch, nur ein> Controller, der in der Automobilbranche verwendet würde,
Schau Dir mal die TriCore-Prozessoren von Infineon an. (Sind für den
Automobilmarkt entwickelt worden).
Es gibt dort auch "kleinere" Derivate (TC1736/24) die für Sensorik fast
schon in Frage kommen. FPU (32 Bit) ist auch verfügbar.
Tobias Plüss schrieb:> Dann könnte man> PWM und anderes Timing-Gedöns ja auch gleich mit im FPGA machen.
Ich würde eher den anderen Weg gehen und alles im Prozessor machen.
Gruß Anja
Hmm jaaa, Tricore sieht auch interessant aus.
Wobei mir bei den ARMen hingegen gefällt, dass es diese von ziemlich
vielen Herstellern gibt - wenn Atmel jemals aufhört, ARMe zu
produzieren, dann nimmt man halt einfach die von TI oder so. Klar muss
man die Leiterplatten neu machen, aber man braucht keine Toolchain. Wenn
Infineon jedoch jemals aufhört, die Tricores zu produzieren, dann hat
man ein Problem - man sitzt dann auf einer sehr teuren
Entwicklungsumgebung, die man für nix anderes gebrauchen kann. Deshalb
wäre es schön gewesen, wenn es hier sowas "universelles" wie ARM gäbe,
aber scheinbar kommt man nicht darum herum, sich an einen einzelnen
Hersteller zu binden - ob jetzt Infineon oder Freescale oder TI, jeder
kocht da sein eigenes Süppchen. Schade...
Tobias Plüss schrieb:> Werden ARMe in der Automobilindustrie auch> eingesetzt?
Möglich, das weiß ich nicht. TI und Infineon werden auf jeden Fall
eingesetzt, die haben spezielle Produkte für Automotive-Anwendungen.
Ich würde TI und Infineon bezüglich der Abkündigungspolitik noch eher
trauen wie Atmel oder NXP.
Oder andersherum gefragt:
Controller wie die AT91RM9200 oder LPC2468 sind zu schwachbrüstig, als
dass man die in consumer-multimedia-Geräten gebrauchen könnte. Aber
andersherum scheinen sie zu wenig "langlebig" zu sein, um sie für
industrielle Steuerungen zu gebrauchen. Wer setzt denn solche
Prozessoren ein, bzw. wozu? Irgend eine gewisse Lebensdauer müssen die
Dinger doch auch haben, oder nicht?
Beide genannten Typen (AT91RM9200, LPC2468) sind durchaus
Universalprozessoren, die von vielen Kunden, gerade auch im langlebigen
industriellen Umfeld, eingesetzt werden. Im Gegensatz dazu gibt es
Prozessoren, deren Lebenszyklus nur dem eines einzelnen oder weniger
Schlüsselprodukte entspricht. Dies muss man ggf. beim Hersteller
erfragen oder auf Grund der Verbreitung herausbekommen.
Vor einigen Jahren gab es einen interessanten ARM-Prozessor von Samsung;
jedoch riet Samsung selbst von dessen Einsatz ab, weil er speziell für
eine bestimmte Gerätegeneration von Tintenstrahldruckern von Brother
hergestellt wurde, also nur ca. ein Jahr erhältlich war. Andere
Prozessoren von Samsung sind aber auch lange Zeit erhältlich, z.B.
S3C2400, S3C2500.
Der o.a. AT91RM9200 ist ein langzeitverfügbarer Prozessor, da er in
vielen langlebigen Produkten eingesetzt wird. Ich selbst habe auch schon
im Auftrag zweier Kunden an den entsprechenden U-Boot- und
Linux-Kernel-Anpassungen gearbeitet. Der Kunde hat den Prozessor sowohl
als Standardprodukt als auch mit einer eigenen ROM-Maske eingesetzt.
Leider ist der AT91RM9200 unglaublich fehlerhaft. Fast jeder
Peripherieblock hat eklatante Schwächen, selbst so banale Teile von
I2C/TWI, SPI und UARTs. Und EMV-mäßig ist er auch nicht ganz
unproblematisch. Atmel weigert sich auch, diese Fehler zu beheben, da
der Prozessor "zertifiziert" sei und damit die Masken nicht mehr
angefasst werden dürften.
Auch bei den Nachfolgeprozessoren AT91SAM9xxx wurden teilweise einige
Fehler der Peripherieblöcke nicht behoben.
Der AT91RM9200 hat ja auch schon etliche Jahre auf dem Buckel.
Heutzutage sollte man durchaus ARM-Prozessoren mit Cortex-M3 o.ä.
einsetzen und nicht mehr die klassischen ARM7- oder ARM9-Typen. ARM hat
nämlich endlich mit CMSIS einen Standard für die gebräuchlichsten
Peripherieblöcke eingeführt, vor allem für die Taktgenerierung,
Speicherkonfiguration, Timer, usw..
http://t*nyurl.com/6xjy6ue
Bei den alten ARM-Prozessoren hat jeder Hersteller sein eigenes Süppchen
gekocht. Wesentlich verbessert hat sich auch das Interrupt-System.
Früher musste man im Interrupt-Handler teils sehr aufwändige Abfragen
durchlaufen, um die Interrupt-Quelle herauszufinden. Seit den
Cortex-/CMSIS-Prozessoren gibt es endlich ordentliche vektorisierte
Interrupts. Das ganze ist wirklich schon so ausgereift, dass man es
einsetzen kann.
Gerade die STM32-Prozessoren dürften auch zu ziemlichen Langzeittypen
werden.
Ja, einfach ist für mich ein Nachteil dieser Cortex-Prozessoren, dass
ich bisher noch keinen gefunden habe, der einen externen Bus hat. Das
ist für mich Pflicht, da für den Zentralen Steuerprozessor die paar k
RAM, die in so einem Cortex typischerweise drin sind, einfach nicht
reichen. Auch für die Applikation wirds knapp; ich habe hier immerhin
4MB FLASH, von dem gewisse Teile ins RAM geladen und dort ausgeführt
werden. Auch der TCPIP-Stack verbraucht viel Speicher. Klar könnte man
da gewisse Optimierungen vornehmen, das würde aber alles auf Kosten von
Performance gehen - und das dürfen wir uns auch nicht erlauben.
Ja, das große RAM und ggf. auch Flash ist in der Tat ein Problem... Bei
den OMAPs von TI würde ich mich nicht darauf verlassen, dass die lange
lieferbar wären, da sie doch sehr stark an einzelne Gerätegenerationen
(Smartphone, Navigationssysteme) gebunden sind.
Das, was auch noch sehr interessant sein kann, wenn hohe Rechenleistung,
insbesondere mit FPU(!), und externes Speicherinterface gefragt sind,
sind die SuperH-Prozessoren von Renesas, ehemals Hitachi. Leider haben
die nun so gar nichts mit ARM zu tun.
Wir haben solch einen Prozessor (SH2) aber auch schon für eine
rechenintensive Kundenapplikation programmiert. Der GCC erzeugte jedoch
teilweise sehr fehlerhaften Code, wenn man im Wechsel mit float- und
double-Typen arbeitete. Ein Mitarbeiter von mir hat da aber einige
Workarounds gefunden.
>Wir bauen damit Maschinen, die 15 Jahre>oder länger laufen sollen.
15 Jahre sind eine Ewigkeit. Ich wage zu bezweifeln das es
Controller die man heute kaufen kann auch noch in 15 Jahren
gibt. Leg dir schon mal ein grosses Lager an;)
>Ja, einfach ist für mich ein Nachteil dieser Cortex-Prozessoren, dass>ich bisher noch keinen gefunden habe, der einen externen Bus hat.
Bei den STM32 gibt es welche mit Businterface.
Hallo,
an den Cortex-M3 von TI lm3s9 kannst Du auch ein externes Flash
anbinden, der hat ein External Peripheral Interface (EPI). Allerdings
ist das interne Flash was die Flash-Zyklen anbelangt nicht so toll,
siehe Errata-Sheet Nr. 4.4.
Die Periepherie ist dann natürlich auch schon ziemlich am Ende, weil mit
dem EPI nicht mehr viel freie Pins da sind.
Andreas,
die FPU muss nicht sein. Es wäre schön, aber ich denke, man wird da
wieder auf den Boden der Realität zurückkehren müssen. Ich denke, einen
Controller mit FPU wird man sowieso nicht mehr in einem lötbaren
Gehäuse, sprich kein BGA, finden - es sollte schon ein QFP sein, damit
wir ggf. auch Leiterplatten reparieren können.
Wie schaut denn das z.B. bei CNC-gesteuerten Maschinen aus. So eine
Maschine will man ja nicht alle 5 Jahre neu kaufen, nur weil eine
Steuerplatine abgeraucht ist, und es den passenden Prozessor nicht mehr
gibt - und in einem ähnlichen Umfeld sind wir auch tätig. Eine unserer
Anlagen kostet ziemlich viel Geld, und da wäre es dem Kunden nicht
zuzumuten, dass wir nach sagen wir mal 5 oder auch 10 Jahren keine
Ersatzteile mehr anbieten können, weils die Prozessoren nicht mehr gibt.
Gerade deshalb möchte ich ja mal vom HC08 weg - der ist älter als ich,
und der Debugger dazu ist unglaublich schlecht, er grenzt eigentlich
mehr an ein "Im-Nebel-Stocher-Werkzeug".
Die Renesas SuperH werde ich mir mal anschauen, danke für den Tipp. In
der Firma, wo ich früher arbeitete, wurden die auch eingesetzt - und da
wurden noch viel heiklere Maschinen produziert, nämlich solche, die 24/7
dauerbetrieb während 20 Jahren aushalten müssen. Da hatten wir auch
SuperH drin - ich habe die ganz vergessen! Danke für den Tipp.
Zwar wird die Entwicklungsumgebung und der Debugger ein schweinegeld
kosten - bei ARM sind die Preise erstaunlicherweise recht human, ich war
ziemlich erstaunt, als ich bei Segger ein Angebot für J-Link Debugger
plus passende Software eingeholt habe. Als Toolchain schwebte mir IAR
vor oder Keil. Aber mit den SuperH würden die ja eh flach fallen, der
Segger Debugger erst recht.
Gerade wenn es um Austauschbaugruppen geht, muss man ja in vielen Fällen
auch nicht unbedingt identische Hardware liefern, sondern nur
hinreichend funktionskompatible.
Deswegen sollte man lieber nicht nach dem 15-Jahres-Prozessor suchen,
sondern nach einer Prozessorfamilie (Kern, Umsetzung) mit einer
ordentlichen Roadmap, damit man mit erträglichem
Software-Anpassungsaufwand gelegentlich neue Hardware-Versionen auflegen
kann. Außerdem spricht wenig dagegen, Ersatzbaugruppen kurz vor EOL der
Bauteile auf Vorrat zu fertigen und z.B. in Tüten eingeschweißt zu
lagern. Alternde Bauelemente, z.B. Batterien und Flüssig-Elkos, kann man
ja notfalls später noch nachbestücken.
Ich sehe das nicht viel anders als du.
Aber wahrscheinlich werde ich da auf Granit beissen, denn es wird
bestimmt Leute geben, die werden sich nicht so über diese Tatsache
freuen und dem 15Jahres-Prozessor ein wenig "nachtrauern". Aber was für
mich auch klar ist:
Ein HC08 ist auch kein zeitgemässer Prozessor mehr, und der PowerPC ist
ganz sicher auch nicht der richtige Prozessor.
Ich muss mich mal bei den SuperH umschauen. Andernfalls werde ich
LPC2000 vorschlagen, da gibt es ja schon bereits einige recht alte
Modelle. Und wenn der ARM7 ausstirbt, nimmt man halt einen 9er. Nur
ungern würde ich wieder sowas ganz spezielles wie einen
Automotive-Prozessor beschaffen - die TPU des PowerPC mag ganz in
Ordnung sein, aber das Ding ist unermesslich kompliziert, man wälzt
viele Stunden das Manual und schreibt viele Zeilen Code, bis man shcon
nur einen einzelnen dummen IO-Pin toggeln kann. Das ist einfach zu
kompliziert, und die Rechenleistung von dem PowerPC ist auch recht
schwach, wenn ich sie mit einem aktuellen ARM vergleiche. Das Dingens
kann nur 40 MHz - da lacht jeder, der einen ARM9 mit 200 MHz rennen
lässt. Dann ist auch float in Software kein Thema mehr - eventuell
liesse sich ein AT91RM9200 evaluieren, die Frage ist dann halt immer
noch, wie man die vielen IOs und PWMs realisiert. Und weiter, was für
einen Prozessor man dann für die kleineren Geräte nimmt - denn da lässt
sich schon nur aus Kostengründen sicher nicht ein solcher Superprozessor
verbauen. Viel schöner wäre es, wenn es da was im QFP48 oder so gäbe.
Evtl. könnte man auch über eine Kombination von ARM Cortex M3 für die
Peripherie und ARM9 für den Zentralrechner nachdenken - aber ich weiss
noch nicht, was IAR dazu sagt - ob man mit der Standardmässigen Lizenz
vom Embedded Workbench alle ARM-Arten programmieren kann, oder ob da auf
eine bestimmte Familie eingeschränkt wird?
Ich rate nochmals ab vom betagten und unglaublich fehlerhaften
AT91RM9200...
Er ist nur deswegen auf so vielen Boards enthalten, weil es "damals"
(ca. 2002) kaum ähnlich leistungsstarke Alternativen gab.
Der AT91RM9200 hat sein erstes Jahrzehnt schon fast herum.
Leider nein, denn die Atmel Site sagt, dass es diesen nur im BGA gibt.
Leider haben viele Bestücker den BGA-Prozess nicht richtig im Griff,
ausserdem lassen sich solche Leiterplatten nur mit wirklichem
Spezialequipment reparieren. BGA fällt also, wenn es nach mir geht,
vollkommen flach. Wir haben kein Röntgengerät und auch keine
Rework-Station - siehe oben, wo ich bereits erwähnt habe, dass hier
bereits ein Stapel alter Leiterplatten rumliegt, wo es den Prozessor
zerblasen hat - das lässt sich nie wieder reparieren, weils so ein
dummes BGA ist. Beim QFP macht man mit dem Skalpell schnipp, und der
Prozessor ist weg - so muss es sein. Notfalls wird das Ding mit einer
Matrize, welche man auf dem Lötkolben aufsetzt, ausgelötet. Aber es
lässt sich wenigstens irgendwie wieder auslöten und selber reparieren,
das ist wichtig!
Tobias Plüss schrieb:> vollkommen flach. Wir haben kein Röntgengerät und auch keine> Rework-Station - siehe oben, wo ich bereits erwähnt habe, dass hier> bereits ein Stapel alter Leiterplatten rumliegt, wo es den Prozessor> zerblasen hat - das lässt sich nie wieder reparieren, weils so ein
Was macht ihr damit, dass es euch den Prozessor zerbröckelt? Habt ihr
die EMV nicht im Griff?
fchk
Tobias Plüss schrieb:> Evtl. könnte man auch über eine Kombination von ARM Cortex M3 für die> Peripherie und ARM9 für den Zentralrechner nachdenken - aber ich weiss> noch nicht, was IAR dazu sagt - ob man mit der Standardmässigen Lizenz> vom Embedded Workbench alle ARM-Arten programmieren kann, oder ob da auf> eine bestimmte Familie eingeschränkt wird?
Nein, da ist keine Beschränkung drin.
fchk
Morgen Frank,
> Was macht ihr damit, dass es euch den Prozessor zerbröckelt? Habt ihr> die EMV nicht im Griff?
Das ist gut möglich. Ich hab da zwar schon einiges bereinigt, aber wer
weiss schon, was die Kunden im Feld jeweils mit den Dingern anstellen -
ich erlebe da manchmal die sonderbarsten Fehlerbilder. Meist zerschiesst
es auch nicht nur den Prozessor, sondern auch noch irgendwelche
IO-Treiber usw. Man muss dazu sagen, dass diese Leiterplatte zur
Steuerung von Leistungsbaugruppen dient - wir steuern damit eine PWM bei
600V und bis zu 120A. EMV-technisch gesehen also eine nicht ganz so
einfache Umgebung, mittlerweile haben wir es aber so mehr oder weniger
im Griff. Schön wäre es halt, wenn man im Falle eines zerbröselten
Prozessors diesen austauschen könnte. Die anderen Chips sind ja kein
Problem, weil TSSOP und so weiter, das lässt sich problemlos reparieren.
> Nein, da ist keine Beschränkung drin.
Sehr schön. Das heisst, wenn ich IAR EWARM beschaffe und die passende
USB-JTAG Box, dann kann ich damit jegliche ARMe, Von Cortex, über
ARM7/9/11 bis hin zum XSCale alles machen. Sehr gut. Weisst du evtl.
gerade, in welcher preislichen Gegend sich die IDE so bewegt? Reden wir
da von <10000€, oder 20000, oder was weiss ich? JTAG-Debugger jedenfalls
sind erstaunlich günstig - ich muss ja keinen Boundary Scan und all den
Kram haben, sondern ich will nur Debuggen damit.
Gruss
>Ein HC08 ist auch kein zeitgemässer Prozessor mehr, und der PowerPC ist>ganz sicher auch nicht der richtige Prozessor.
Den HC08 würde ich auch rausstellen, (und zB durch Atmel AVR ersetzen)
aber ich verstehe Deine Ablehnung gegen den PowerPC nicht. Die sind gut,
günstig, leistungsfähig, zuverlässig und haben wirklich eine lange Live
Cycle von 10..20 Jahren. BGAs ist "state of the art" Technologie, ich
habe keine Probleme damit, wenn Dir viele Boards abrauchen vermute ich
Design-Fehler.
Wenn Langlebigkeit ein Thema ist empfehle ich bei Freescale CPU's zu
bleiben, Du könntest sonst vom Regen in die Traufe kommen. Gewisse
andere Firmen kündigen manchmels ihre Chips ab ab, bevor Du die
Serienproduktion hochhahren konntest...
Meine Empfehlung wären Prozessoren von Renesas der Serien H8S, H8SX,
SH2A oder RX610/620. Alle Typen haben viele, gleichartige Timer, einen
ext. Daten-/Adressbus, DMA+DT-Controller, gleichartige USARTs und die
Flash-Versionen Zugriffe ohne Wartezyklen selbst bei 100MHz.
Diverse interne Daten- und Adressbusse ermöglichen parallele Transfers.
SH2A und RX Prozessoren gibt es mit (schneller) FPU. Die Gehäuse sind
typischerweise LQFP128, LQFP144 und LQFP176.
Ich nenne ein paar Typen, die Du Dir ansehen solltest:
H8S/2329 25MHz für einfache Anwendungen
H8SX/1668R 50MHz, ExDMA für QVGA-Ansteuerung
SH7286, 100MHz, Vcc 3-5V!
SH7211, 160MHz 2 x Ausführungseinheit, sehr schnell
SH7216, ähnlich 7211 mit FPU
RX610, 100MHz universell 2MB Flash, 128kB RAM
RX620, 100MHz mit div. Schnittstellen
Kostengünstige Entwicklungsboards gibt es zum Beispiel hier:
http://www.msc-toolguide.com/renesas/tool-family/rsk?p=5
(ein bißchen stöbern) oder auch hier
http://www.glyn.de/content_xl.asp?wdid=2&wpid=3399&sid=00000026795E555F595546615158405C47
Nein, ich bekomme keine Provision :-)
Hi,
koennte sonst noch den Blackfin empfehlen. Den setzen einige
Automotive-Kunden ein. Das 'Haltbarkeitsdatum' scheint da auch sehr gut,
leider gibt es halt keine second sources wie bei den ARM-Chips. Von den
Tools her...die offiziellen Entwicklungstools sind eher so naja und für
Hardcore-Entwicklung muss man sich gehörig am Kopf kratzen, deswegen
verwenden wir durch die Bank GCC (da lässt sich derselbe HW-unabhängige
Code auch für den ARM compilieren).
Für Steuerungsaufgaben finde ich das Ding Top, und der Stromverbrauch
pro Leistung ist bei den neuen Käfern fast ungeschlagen. Schlecht ist
nur, dass es einige dieser Varianten nur im BGA-Gehaeuse gibt, man muss
also genau suchen.
Gruss,
- Strubi
Wir setzen Cortex-M3 (STM32F103) ein und nutzen die IAR Umgebung. Es
gibt hiervon eine Cortex-only Version (ich glaube die kann nur M0/M3,
kein Ax oder Rx). Hat gekostet 3300,- netto IIRC. Die Vollversion mit
ARM7/9/11 schätze ich auf 4500,- maximum.
Bei der Ausschreibung unserer HW (machen wir nicht selbst) haben alle
vier oder fünf Anbieter den STM32 genommen. Denke, dass man da
langfristig gut bedient ist. Unsere Geräte haben einen Produktzyklus von
~10 Jahren.
Hallo,
wenn ihr schon mit Freescale Controllern arbeitet, dann lohnt sich
sicherlich ein Blick auf die Kinetis Familie. Sind ARM Cortex M4
Prozessoren, also mit FPU. Es gibt sie auch in QFP und mit externem
Speicherinterface.
Die HC08 kannst Du ggf durch HCS08 ersetzen.
Eckhard
Ich habe den Thread bisher nur überflogen, aber hier werden ja "nur"
wild Controller empfohlen und auch wieder von abgeraten.
Für ein strukturiertes Herangehen müsstest Du doch eine Liste mit
Anforderungen und Evaluationskriterien aufstellen und damit die
Controller betrachten. Erst recht wenn die Maschinen 15 Jahre und mehr
laufen!
Hast Du sowas mal aufgestellt?
Falls ich beim überfliegen was übersehen habe, sorry!
Wenn für das Programm 1MB Flash reinchen würden, dann würde ich auch zu
einem STM32 tendieren, denn Daten und andere Dinge könnte man auch in
einen Atmel DataFlash speichern, das ist ein FLASH Speicher mit SPI Bus
und hat viele MB.
Hier ein Artikel über STM32.
Mathi schrieb:> Für ein strukturiertes Herangehen müsstest Du doch eine Liste mit> Anforderungen und Evaluationskriterien aufstellen
Hat er schon versucht:
Tobias Plüss schrieb:> ich brauche aber Massenhaft Flash, und> deshalb muss es einer mit externem Bus sein und viel internem Memory
Ich krieg bei derart konkreten Angaben immer Bauchgrimmen.
Wo und welche Rechenpower benötigt wird, ist mir nicht klar, das bischen
PWM-Zeugs kanns ja wohl nicht sein.
Peter
holger schrieb:> 15 Jahre sind eine Ewigkeit. Ich wage zu bezweifeln das es> Controller die man heute kaufen kann auch noch in 15 Jahren> gibt. Leg dir schon mal ein grosses Lager an;)
Oder schau dir die zugesagte Verfügbarkeit der Hersteller an. Für
Freescale sind z.B. hier die 10 und 15-jährigen Prozessoren gelistet:
http://www.freescale.com/webapp/sps/site/overview.jsp?code=PRDCT_LONGEVITY_HM
Peter Dannegger schrieb:> Hat er schon versucht:>> Tobias Plüss schrieb:>> ich brauche aber Massenhaft Flash, und>> deshalb muss es einer mit externem Bus sein und viel internem Memory>> Ich krieg bei derart konkreten Angaben immer Bauchgrimmen.
Das erweckt bei mir den Eindruck er möchte UNBEDINGT einen ARM.
Unabhängig von den Anforderungen :-(
Hallo Peter,
ich bin gespannt auf deinen Beitrag. Du hast immer gute Ideen.
Was hier konkret gemacht wird:
es müss im Takt von 3.3 ms oder schneller 16 3x3 Matrizen multipliziert
und addiert werden. Mit den Rechenwerten wird ein digitaler Regler für
die PWM gefüttert. Zudem ist es leider so, dass sich im Betrieb die
Regelstrecke dauernd ändert. Mithilfe dieser Matrizen alssen sich gleich
auch noch die Reglerparameter, also das Kp und Ti, berechnen. Die
Messwerte, die eintrudeln - 16 Spannungen und 16 Ströme insgesamt -,
sind 16 Bit vorzeichenbehaftete Ganzzahlen - wenn da nur eine einzige
Multiplikation ausgeführt wird, werden leider schon 32 Bits draus. Ich
möchte auch lieber kein float verwenden, auf solchen Embedded-Systemen
bin ich da ziemlich dagegen!
Warum das mit den Matrizen gemacht wird? Naja, ich persönlich würde das
auch lieber anders angehen, aber mein Vorgesetzter will das so.
Ausserdem muss ich zugeben, dass die Berechnung sehr elegant ist - man
bekommt gleich alle notwendigen Zahlen, und der Regler parametriert sich
selbst, das ist schon sehr bestechend.
Notfalls würde ich allerdings auch lieber sogar 64 Bit
Fixpoint-Arithmetik betreiben, als diese Übung mit Matrizen und float.
Wie viel Flash ich brauche:
Momentan sind von dem 4 MB Flash ca. 3MB belegt. Der Grossteil davon ist
die Applikation, sprich: diese 3MB werden sich ändern, wenn man einen
anderen Prozessor mit einem anderen Befehlssatz verwendet.
Des Weiteren werden 512k an RAM verwendet. Das reicht gerade so, zwar
habe ich grosszügig dimensionierte Stacks und ein etwas aufgeblähtes
RTOS, aber die anfallenden Datenmengen sind schon relativ beträchtlich.
Hallo Tobias,
arbeite schon länger mit ARM und habe mich mittlerweile auf die
STM32-Familie festgelegt. ES gibt verschiedene Gehäusebauformen (wie bei
Dir auch QFP bevorzugt) und ein wichtiger Punkt ist die Pinkompatibität
zwischen den einzelnen Unterfamilien. Auch ich setze seit Jahren den IAR
ein und bin voll zufrieden. Du kannst alle ARM´s damit programmieren
(wenn Du nicht eine beschränkte Version hast).
Für den Sensorbereich langt Dir ein Kleiner STM32F100, 101, 102, 103 je
nach Peripheriebedarf und für den "Großen" würde ich die neue
STM32F2-Familie einsetzen, welche ein externes Businterface hat.
Datenblätter sind schon im Netz. Hier haste mit den F2x7-Typen gleich
auch ne Ethernet-Schnittstelle integriert.
Gruß Ruppi66
Moin
man sollte gerade bei den ARM 9 Cores noch etwas anderes beachten z.B.
den speicher.
Der RM9200 müste noch mit normalem SD RAM arbeiten. preislich sicher
nicht mehr das günstigste am markt, besonders dann wenn der etwas
grösser sein sollte.
Aktuelle Freescale (z.B. iMXxxx) haben da schon teilweise SD DDR bzw SD
DDR2 als möglichkeit. da sehen die speicherpreise schon etwas anders
aus. teilweise ist allein zwischen DDR und DDR2 faktur 2 drin ( wenn
nicht mehr)
Ist z.B. auch bei Atmel der grund weshalb ich auf die SAM9xxx serie
nicht umbedingt setzen würde. Die werden sicher in zukunft durch die
SAM9Mx bzw SAM9G serie abgelöst.
Hallo Tobias,
wenn Du schon einen FPGA als io-extender drauf hast,
warum dann nicht gleich eine Softcore cpu mit in den fpga legen.
Welchen FPGA nutzt Du da ?
Deine Multiplication kannst Du ja zur Not in dedizierte Logik im FPGA
auslagern
Ein Emac sollte auch kein Problem sein, externen Speicher ebenfalls.
Das einzigste waere, auf Grund deines Umfeldes (EMV) solltest Du
zumindest ne WDT laufen lassen und den FPGA im Fehlerfall rebooten.
Besser waere noch scrubbing, aber das ist dann wieder ein höherer
Aufwand.
LG
ein bastler
Klar möchte ich am liebsten einen ARM. Einfach deshalb, weil ich diese
mittlerweile gut kenne und da mittlerweile einigermassen fit bin mit der
Programmiererei. Ausserdem sind sie sehr skalierbar, was man vom PowerPC
nicht behaupten kann - sprich es gibt sie sowohl im 10x10mm QFP als auch
im GFP208. Wenn das auf die SuperH auch zutrifft (bin noch nicht zum
Recherchieren gekommen), dann wären diese eine gute Alternative. Wichtig
sind auch die Preise für Debugger und IDE. Bei ARM kenne ich die
mittlerweile; bei SuperH muss ich es noch in Erfahrung bringen, aber ich
habe da Befürchtungen, dass die Teile 10k oder mehr kosten (Debugger und
IDE meine ich).
STM32F2x7 werde ich mir anschauen, danke!
bastler,
als FPGA wird ein recht alter Typ genutzt - die Leiterplatte wurde lange
vor meiner Zeit von Leuten entwickelt, die gar nicht mehr hier arbeiten.
Am FPGA wurde seither kaum je was geändert, den haben wir immer so
belassen wie er ist. Es ist ein Altera ACEX mit 30k LEs. Das Teil ist
wirklich uralt, und ausserdem im BGA - weshalb es sowieso früher oder
später auch ersetzt werden muss. Mit diesen Softcores habe ich
allerdings gar keine Erfahrung, und wir haben hier auch niemanden, der
bisher damit gearbeitet hat. Daher denke ich, dass dies eher schwierig
ist... zumal bezweifle ich, dass 30k LEs reichen, um einen solchen
Überprozessor zu bauen.
Moin
ARMs werden auch in der Automobil industrie eingesetzt.
Die grossen "geschosse" von Freescale oder TI z.B. für navi oder
multimedia anwendungen. Die wollen ja High end video und 3d navigation
parallel haben, ...
und CAN ist da auch kein problem beim ARM9. gibt genug mit.
und kosten für entwicklungsumgebung.
es geht von sehr sehr teuer bis low budget.
IDE kann man z.B. die CDT von E-Clips verwenden
Compiler von GNU (gcc)
Debugen mit dem GDB.
nur der JTAG Probe kann etwas geld kosten. muss aber nicht.
Hier sehe ich eher die anforderungen an den Debuger als kriterium,
Welche Targe OS soll / muss er unterstützen, Welche Funktionen soll
dieser mit bringen, nur reines debuggen oder doch lieber etwas mehr,
trace, code analyse funktionen, ...
Mit den CortexM3 und der GDB debugger sieht es aktuell noch etwas mau
aus. SWD Wird aktuell noch nicht offiziel vom openOCD unterstützt.
1234 schrieb:> ARMs werden auch in der Automobil industrie eingesetzt.>> Die grossen "geschosse" von Freescale oder TI z.B. für navi oder> multimedia anwendungen. Die wollen ja High end video und 3d navigation> parallel haben, ...
Allerdings sind die parametrischen Anforderungen an Infotainment Systeme
nicht so hoch wie an andere Fahrzeugsysteme. Schließlich ist es -wenn
auch ärgerlich- eigentlich egal ob ein Navi ausfällt. Aber bei ABS oder
ESP siehts da schon anders aus ;)
Ändert aber an der sache der Ersatzteil verfügbarkeit von 10 bis 15
Jahren und dem temperaturbereich die der baustein abkönnen muss aber
absolut gar nichts.
wobei bei sicherheits relevant sich mir eher die frage stellt ob ich der
HW traue ober der Software.
Software ist nun mal nie fehlerfrei.
1234 schrieb:> Ändert aber an der sache der Ersatzteil verfügbarkeit von 10 bis 15> Jahren und dem temperaturbereich die der baustein abkönnen muss aber> absolut gar nichts.
Doch leider schon. Der Temperatur bereich ist nicht der Gleiche. Und im
Infotainment bereich werden andere Strategien entwickelt und verfolgt
als für die Motorsteuerungen. Die OEMs sind sogar zum Teil gezwungen im
Infotainment auf nicht automotive qualifizierte Bausteien zu setzen.
Zudem soll der gesuchte Controller laut Autor im Industrieumfeld
eingesetzt werden.
Allerdings hast Du damit recht, das es AEQ100 qualifizierte Controller
für den Bereich gibt. Ich wäre aber bei diesen sehr vorsichtig mit der
langzeit Verfügbarkeit.
Andreas Schweigstill schrieb:> Bei> den OMAPs von TI würde ich mich nicht darauf verlassen, dass die lange> lieferbar wären, da sie doch sehr stark an einzelne Gerätegenerationen> (Smartphone, Navigationssysteme) gebunden sind.
Die OMAP meinte ich oben auch nicht, sondern eher die C2000-Serie. Die
reicht evtl. für die Anforderungen und die Architektur wird sicherlich
auch langfristig verfügbar sein. Sie wird eben auch im Automotivebereich
(nicht Infotainment) eingesetzt. Gleiches gilt für Infineon; die C166
gibt es schon seit ca. 2 Jahrzehnten und wird wohl auch weiterverfolgt.
Die Tricore bleiben sicherlich auch noch eine Weile am Markt.
Wichtig ist eben, dass die Architektur langfristig verfügbar ist. Man
muss dann nur saubere Schnittstellen (sowohl in Software als auch in
Hardware) schaffen, dann kann man auch im Falle einer Abkündigung
entsprechend schnell reagieren.
> Klar möchte ich am liebsten einen ARM. Einfach deshalb, weil ich> diese mittlerweile gut kenne und da mittlerweile einigermassen> fit bin mit der Programmiererei. Ausserdem sind sie sehr skalierbar,> was man vom PowerPC nicht behaupten kann - sprich es gibt sie> sowohl im 10x10mm QFP als auch im GFP208.> Wenn das auf die SuperH auch zutrifft (bin noch nicht zum> Recherchieren gekommen),
Ich wuerde weder ARM noch SuperH verwenden. Beides sind IMHO eher
Prozessoren fuer den Consumerbereich. Also Spielkonsolen, PDAs und
andere Kisten die schnell sein sollen, die es aber in fuenf Jahren nicht
mehr gibt.
Fuer den Industiellen Bereich hat Renesas die R8C, M16C, M32 und R32.
Die sind extrem skalierbar. Du kannst jederzeit den Prozessor wechseln
und merkst da fast keinen Unterschied. Du kannst sogar leistungsmaessig
sehr unterschiedliche Prozessoren auf den gleichen Footprint setzen.
Du kannst aber auch dir ganzen Mitsubishi linie, also R8C bis R32 und
die
Hitachis (SuperH) unter derselben Entwicklungsumgebung nutzen.
> sind auch die Preise für Debugger und IDE. Bei ARM kenne ich die> mittlerweile; bei SuperH muss ich es noch in Erfahrung bringen, aber ich> habe da Befürchtungen, dass die Teile 10k oder mehr kosten (Debugger und> IDE meine ich).
Die Entwicklungsumgebung fuer die R8C bis R32 kostet bei Renesas 2kEuro.
SuperH weiss ich nicht, wuerde ich aber aehnlich einschaetzen.
Olaf
Danke euch für die zahlreichen Tipps.
Ich werde mir noch die Renesas M32C anschauen, ich habe gerade gesehen
dass diese eine FPU drin haben. Wenn es als nötig erachtet wird....
Auch die SuperH werde ich angucken. Notfalls kaufe ich mir dieses
Entwicklungskit von meinem eigenen Geld, es sieht so interssant aus dass
ich sowas auch privat zum basteln nutzen würde.
Fraglich wäre noch, ob die Teile leicht zu beschaffen sind. Werde morgen
mal kurz meinen Distributor anrufen und das erfragen.
Vielen Dank euch!
Gruss Tobias
Wenns um die Verfügbarkeit geht, würde ich zu den ARM Cortex M3 raten.
Da gibts ja schon 4 Hersteller (Atmel, NXP, ST, TI).
ST ist zur Zeit bei 1MB Flash, 128kB RAM intern.
CAN, USB, Ethernet haben die oft auch schon drin.
Peter
Hi Peter,
danke auch für deinen Tipp.
Ich selber würde auch einen ARM nehmen. Aber wie es halt so ist, nicht
immer kriegt man das, was man gerne möchte - es wird offenbar ein
PowerPC bleiben. Zum Glück habe ich noch nicht allzu viel Aufwand
betrieben, sonst wäre der jetzt für die Katz :-)
Nur so aus Interesse:
würdest du persönlich das auch so einschätzen, dass ein gut optimierter
Code, der mit meinetwegen 64 Bit Fixpoint rechnet, ganz bestimmt
schneller ist, als ein Controller mit FPU? Ich habe so den Verdacht,
dass dem so ist. Zwar kann "meine" PowerPC-FPU hier quasi im Hintergrund
rechnen - das heisst, ich schmeiss meine Operanden einfach in
irgendwelche Register, mache irgend was anderes, und wenn die Rechnung
fertig ist, kann ich dann das Resultat raus lesen. Das Problem ist
leider: meine Berechnung ist sehr sequentiell. Man muss erst einiges
addieren, bevor man multiplizieren, dividieren und was weiss ich weiter
rechnen kann, und die Zwischenergebnisse werden manchmal auch benötigt.
Somit bringt eine FPU, die "parallel" rechnet, eh nix, weil ich ja das
Resultat sowieso immer abwarten muss :-) Da kann man gleich mit Fixpoint
und ohne spezielle Hardwareunterstützung in Form einer FPU rechnen.
Was ich allerdings zugeben muss: die Dynamik könnte ein Problem sein.
Deshalb die 64 Bit.
Aber gut, die Diskussion ist eh müssig, wenn sich ja nix ändern soll.
Früher oder später wird es sich dann ja schon rächen, wenn man nichts
macht, und alternde Tools für alternde Prozessoren einsetzt - aber muss
ja nicht mein Problem sein. Ich muss den Kram nur layouten und
programmieren.... :/
Tobias Plüss schrieb:> würdest du persönlich das auch so einschätzen, dass ein gut optimierter> Code, der mit meinetwegen 64 Bit Fixpoint rechnet
Da muss man doch nicht schätzen, das kann man ganz genau nachschauen.
Stefan L. schrieb:> Tobias Plüss schrieb:>> würdest du persönlich das auch so einschätzen, dass ein gut optimierter>> Code, der mit meinetwegen 64 Bit Fixpoint rechnet>> Da muss man doch nicht schätzen, das kann man ganz genau nachschauen.
Zum Nachrechnen: "es müss[en] im Takt von 3.3 ms oder schneller 16 3x3
Matrizen multipliziert und addiert werden" Wenn man alles addiert d.h.
16 Matrixadditionen und 16 Matrixmultiplikationen kommt man auf:
Komplexität Addition: hier 3 3 16 = Additionen = 144
Komplexität Multiplikation n^3 (trivial Algorithmus) = 3^3 =27 * 16 ~
432 d.h. 432 + 144 = 576 "Berechnungen" in 3.3 ms ~ 5.5 us pro
Berechnung. Laut http://www.smxrtos.com/ussw/gofast/gofast_arm_cwk.htm
braucht ein ARM7 @ 48 Mhz < 3 us pro Addition oder Multiplikation d.h.
das Teil wäre hier zu 60% ausgelastet (ohne FPU).
Empfehlung: AVR32 in Form des UC3C
http://www.atmel.com/dyn/corporate/view_detail.asp?ref=&FileName=UC3_Automotive_f2.html&SEC_NAME=
5V, 125 °C und hat zur Not auch eine FPU.
Tobias Plüss schrieb:> Nun die Frage:> Ist ARM hier die richtige Wahl? Wir bauen damit Maschinen, die 15 Jahre> oder länger laufen sollen. Das heisst, die Prozessoren müssen nach> langer Zeit noch verfügbar sein.> Persönlich möchte ich wegkommen von dieser PowerPC-Geschichte, die sind> ziemlich hässlich zum Debuggen und Programmieren, und ausserdem meist> nur im BGA verfügbar - und sie kosten viel zu viel, für das was die> können.
Ich fasse mal zusammen:
- Lange Verfügbarkeit
- Skalierbare Architektur
- CAN und serielle Schnittstelle
- Industrielles Umfeld
Der Ansatz, bei Automotive-Teilen zu schauen, ist erst mal nicht falsch.
Mir fallen als uC-Hersteller da spontan ein:
- Infineon
- ST
- Renesas
- Freescale
Ich unterstelle mal, dass der Hardware-Entwicklungsaufwand im Vergleich
zum Software-Entwicklungsaufwand eine untergeordnete Rolle spielt. Wenn
das so ist, wäre ARM keine schlechte Wahl, denn: auch wenn ein
bestimmtes Derivat abgekündigt wird oder ein Hersteller die Architektur
aufgibt, wird es trotzdem mit einiger Sicherheit noch ein anderes
Derivat geben.
PowerPC gibt es übrigens auch im LQFP, siehe z.B. unter
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC563xM&tab=Buy_Parametric_Tab&fromSearch=false
Olaf schrieb:> Ich wuerde weder ARM noch SuperH verwenden. Beides sind IMHO eher> Prozessoren fuer den Consumerbereich. Also Spielkonsolen, PDAs und> andere Kisten die schnell sein sollen, die es aber in fuenf Jahren nicht> mehr gibt.
Mit dieser Aussage hast Du den Vogel abgeschossen, Herr Schützenkönig.
Tobias Plüss schrieb:> Ich werde mir noch die Renesas M32C anschauen, ich habe gerade gesehen> dass diese eine FPU drin haben.
Dann nimm lieber den RX610; den würde ich als Nachfolger für den M32C
ansehen. Er hat einen Mix der guten Eigenschaften aus den H8SX, SH und
M32 Serien nebst FPU. Für 80 € bei Glyn gekommt man ein Board, nebst
Segger JTAG und HEW von Renesas: ein feines Teil!
Tobias Plüss schrieb:> Zudem läuft ein TCP-Stack.
Hmm, den MPC555 haben wir auch mal eingesetzt, ist ja nun schon einige
Jahre alt das Ding.
Der Controller hat doch aber gar kein Ethernet, was willst Du da mit nem
TCP-Stack?
Extern drangeklebt?
Wenn es nur um das Gehäuse geht, es gibt MPCs inzwischen auch sowohl von
Freescale selbst als auch von ST im TQFP Gehäuse.
Tobias Plüss schrieb:> Nur so aus Interesse:> würdest du persönlich das auch so einschätzen, dass ein gut optimierter> Code, der mit meinetwegen 64 Bit Fixpoint rechnet, ganz bestimmt> schneller ist, als ein Controller mit FPU?
Ich muß ehrlich sagen, ich versuche komplizierte Rechnungen zu
vermeiden, weil ich gerne verstehen will, was ich da mache. Und ich bin
kein Mathe-Genie.
Ich habe gemerkt, daß es keinen Sinn macht, die Rechnungen 1000-mal
genauer zu machen, als es die Sensoren, AD-Wandler, Aktoren, mechanische
Komponenten usw. überhaupt hergeben.
Insbesondere bei Regelungen spielt es keine Rolle, ob man gleich im
ersten Schritt den vermeintlich exakten Stellwert ausrechnet.
Ich hab z.B. ne Regelung, die pro Schritt einen Fehler bis zu 10% haben
kann und trotzdem besser 0,1% ausregelt. Der Trick ist, daß ich immer
nur die Abweichung behandle, d.h. je geringer die Abweichung, umso
kleiner der Fehler.
Auch werden Funktionen bei kleinen Werten oft einfacher, z.B. sin(x) = x
für kleine x.
Eine Regelung muß eigentlich nur nach der gewünschten Zeit konvergieren.
Das Motto: "Nur so genau wie nötig" spart manchmal verblüffend viel
Aufwand ein.
In der Software kann man viel annähern und sogar schummeln, ohne das es
auffällt.
Ein gutes Beispiel dafür sind Videokompressionen. Solange das Video
läuft, ist alles super Qualität. Aber wehe, man schaltet auf Standbild,
dann ist das Bild grauenhaft.
Dagegen sieht das Standbild einer alten MAZ auch gut aus.
Peter
ARM ist nichts für Langzeiteverfügbarkeit.
Ob Automotiv oder nicht. Ist einfach so.
Außerdem kann man nicht von einem Fujitsu Cortex M3 auf einen gleichen
Chip eines anderen Herstellers springen. Das ist viel zu Aufwendig und
zu teuer. Compilerlizensen etc.
Ich kann dir nur, wie oben schon gesagt, Renesas RX empfehlen. Hier
sprechen wir von 15 Jahre +!!
Renesas ist sowas wie der Mercedes bei MCU's. Hat alles kann alles.
Sorgenfrei.
Support Starterkits etc. gibt es glaub ich bei Rutronik, MSC, definitiv
aber bei Glyn.
Kommt halt bei allen auch auf die Stückzahl an.
Weis nicht ob die Überlegung noch aktuell ist, hoffe ich konnte dir
helfen.
Sebastian Olid schrieb:> ARM ist nichts für Langzeiteverfügbarkeit.> Ob Automotiv oder nicht. Ist einfach so.
Da haben sich die Zeiten aber gehörig geändert. Gerade wenn Du auf ARM
setzt, hast Du wegen des de-facto-Standards eine Garantie, die Cores auf
Jahre hinaus zu kriegen. Und wer seinen Code mit GCC entwickelt, hat
inzwischen kaum Portierungs-Kosten. Habe selber eine Umstellung von ARM
auf Blackfin zu verantworten gehabt, der (Automotive-)Kunde hat davon
kaum was gemerkt.
Bei Renesas wäre ich aufgrund der momentanen Lage bezüglich Japan
äusserst vorsichtig. Ausserdem ist die Zeit der veralteten Nischenlösung
auch in der Automotive-Industrie längst vorbei, nicht umsonst kränkeln
einige Vendors aus der schwerfälligen Liga (Infineon, etc.).
Wenn man heutzutage kostengünstig/portabel und robuste Entwicklungen
stemmen will, kommt man meiner Meinung kaum an GCC und gut unterstützten
Plattformen (wie u.a. ARM) vorbei. Es geht nie ohne Spezialisten, aber
die sind in der OpenSource-Community deutlich häufiger und günstiger als
in der proprietären Ecke.
Sebastian Olid schrieb:> ARM ist nichts für Langzeiteverfügbarkeit.
Schön, dass dir das nach bereits 2 Monaten einfällt. Hättest den
Thread auch in der Versenkung lassen können.
Noch mal der Hinweis
Die Listen der Hersteller anschauen.
Es gibt auch ARMs mit verfügbarkeiten von 10 / 15 Jahren.
Es kommt aber auch immer noch darauf an wie lange die MCU schon am Makrt
ist.
Auf ein Pferd setzen das schon 15 jahre auf dem Buckel hat und dann
hoffen das es noch weiter 15 jahre überlebt, ...
siehe i.mx 53 28 ...
http://www.freescale.com/webapp/sps/site/overview.jsp?code=PRDCT_LONGEVITY_HM
Thread beobachten
Seitenaufteilung abschalten