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 ;-)).
:
Gesperrt durch Moderator
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.
Hmm ich wusste gar nicht dass der schon so alt ist. Was hältst du von einem AT91SAM9260?
Dann doch lieber gleich den SAM9G20, der ein verbesserter SAM9260 ist.
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.
Tobias Plüss schrieb: > 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). Du hättest mal ein bißchen stöbern sollen: http://www.msc-toolguide.com/renesas/tool-family/rsk/renesas-starter-kit-plus-for-sh7211.html http://www.msc-toolguide.com/renesas/tool-family/rsk/renesas-starter-kit-plus-for-sh7286.html Für 359 Ocken bekommst Du ein Board mit Prozessor, E10a Debugger (JTAG) und HEW-IDE, was keine Wünsche übrig läßt. Nach 60 Tagen ist die Codegröße auf 256kB begrenzt, oder man nimmt gleich GCC http://www.kpitgnutools.com/index.php und befindet sich dann im erlesenen Kreis der GCC-Nutzer.
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.
Hab da grad noch was lustiges gesehen. wieso nicht FPGA und ARM Core zusammenschmeissen? ARM M0/M1 im FPGA geht ja hone weiteres aber der Zynp-7000 hoert sich auch ganz lustig an. Cortex A9 mit FPGA in einem gehäuse. http://www.xilinx.com/technology/roadmap/processing-platform.htm
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