mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Evaluation neuer Mikrocontroller: ARM?


Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Mine Fields (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Mine Fields (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Andi B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm ich wusste gar nicht dass der schon so alt ist.
Was hältst du von einem AT91SAM9260?

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann doch lieber gleich den SAM9G20, der ein verbesserter SAM9260 ist.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: Frank Q. (franki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Nein, ich bekomme keine Provision :-)

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Eckhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-(

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ruppi66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Q. (franki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/r...
http://www.msc-toolguide.com/renesas/tool-family/r...

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.

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: 1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ä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.

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mine Fields (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.... :/

Autor: Mine Fields (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
5V, 125 °C und hat zur Not auch eine FPU.

Autor: Max G. (l0wside) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_summ...

Autor: Frank Q. (franki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/processin...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian Olid (solid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: BöserFisch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.