Frage zu ARM7/Cortex-M3 (im Rahmen der 8-bit ->32 bit Migration)

Hallo, NG!
Hintergrund: Migrationsplaene von 8-bit (8051) auf eine 16/32-bit
Architektur.
Habe mich intensiver umgeschaut, wohin die Reise bei Mikrokontrollern so
geht, und den Eindruck bekommen, dass die ARM-Architektur dank ihres
einerseits einheitlichen Ursprungs und ihrer andererseits mehrheitlichen
Implementierungsquellen (NXP, Luminary, TI, ST, etc...) bessere Zukunft (und
Diversifikation) hat als die proprietaeren Architekturen wie von Renesas,
AVR32, PIC and Co,. seien die letzten heutzutage auch so beliebt.
Die erste Frage allgemeiner Natur: ist mein Eindruck richtig? Hintergedanke:
man will sich bei der Wahl einmal richtig und zukunftssicher festlegen, um
spaeter nichts zu bereuen. Es ist wie beim Restaurantbesuch: zuerst die Qual
der Wahl, und danach sehen die Speisen am Nachbartisch (oder bei der Frau
gegenueber) leckerer aus als die eigenen (geht es vielen so? :)).
Eine weitere, konkretere, Frage zu ARM7 vs. Cortex-M3:
ARM7 hat von Neumann Architektur, und der Code kann aus dem beliebigen Ort
im Adressenbereich ausgefuehrt werden. Cortex-M3 fuehrt wieder die
Harvard-Architektur ein, zumindest im Sinne, dass intern die Busse zum FLASH
und RAM separat liegen. Ich bin aber aus den Beschreibungen nicht schlauer
geworden, ob ungeachtet dessen und des weiterhin planaren Adressenbereichs
der Code auch aus dem beliebigen Speicherort (auch aus dem internen SRAM)
ausgefuehrt werden kann.
TIA,
Igor.
Reply to
Igor "Knight" Ivanov
Loading thread data ...
Das wird ein ziemlich langer und wenig ergiebiger thread da die Vorhersage der Zukunft schwierig ist. Hätten wir jetzt 1989 wäre die verbindliche Aussage in den Medien gewesen: "in Zukunft setzen sich auch für Toaster x86-Derivate durch die auf einem embedded Microsoft-Betriebssystem in Turbo-Pascal programmiert werden".
* ARM hat für Hersteller den Nachteil daß sie Lizenz zahlen müssen. Im untersten Preissegment ist das durchaus relevant. * ARM hat den technischen Nachteil daß er ursprünglich satte Mengen Speicher in externen DRAMs erwartete. Er ist keine Controller-Architektur. Natürlich haben sie nachgebessert a la Thumb, Cortex ... Aber damit fragmentiert man das einheitliche Prozessormodell. * 8 Bit Controller die mit wenig Speicher auskommen gibts weiterhin mit 5V Versorgung. Etwas worauf z.B. automotive Kunden Wert legen. Varianten mit CPU-Core bei niederiger Spannung und integriertem Regler und Wandlern sodaß der Chip nach aussen wie ein 5V-IC aussieht gibts für die 68HC08 auch. Aber selten. Und bei 16/32 Bit wahrscheinlich oft kaum möglich.
Der dicke PIC ist glaube ich ein MIPS.
MfG JRD
Reply to
Rafael Deliano
Solange man nicht die Frau am Nachbartisch leckerer findet?! :-)
-ras
--
Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
 Click to see the full signature
Reply to
Ralph A. Schmid, dk5ras
Wir haben das so gemacht, dass wir uns eine recht einheitliche und plattformübergreifende Bilbliothek an Funktionen, welche die Hardware bedienen, geschrieben haben. Damit kann man leicht die Architektur wechseln, Single Source ist damit kein Problem mehr.
Programmiert wird konsequent in "C", falls nicht Assembler bei einzelnen Funktionen zwingend ist.
Damit vermeiden wir, irgendwelche Klimmzüge wegen Beschaffbarkeit bei der Hardware machen zu müssen, sprich Produkte mit "nur 8051 oder IA32" Dogmen schlecht zu designen.
Und ansonsten empfehle ich Dir, auch mal nach DSPs zu schauen, die TI TMS 28Fxxx Serie stellt ziemlich kompakte Single Chip Lösungen mit Flash, RAM, schnellem ADC, jeder Menge Peripherie, großem Adressraum, 32/64 Bit Ops und inzwischen auch Varianten mit Hardware Floating Point (F335) zur Verfügung. Aber: Kein DRAM.
Soll es schneller gehen: Blackfin, aber kein Flash mehr on Board, und die Handhabung ist deutlich komplexer (auch wegen diverser Bugs), dafür ist der vom Stromverbrauch noch sehr genügsam, hingegen können fette IA32 oder PowerPC sehr viel Aufwand mit der Kühlung bedingen und den üblichen Rahmen sprengen.
Btw.: Der ARM ist keine schlechte Wahl, aber bedingt meist mehr Aufwand. Top für Handheld-Computer, eher mau für eine Motorsteuerung.
Und: Man kann heute auch 32 Bit Cores performant in einem FPGA betreiben.
Gruß Oliver
--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Reply to
Oliver Bartels
Am Wed, 06 May 2009 14:55:05 +0200 schrieb Ralph A. Schmid, dk5ras:
Aus der Entfernung sieht vieles gut aus ;-)
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im 
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin 
 Click to see the full signature
Reply to
Lutz Schulze
Oliver Bartels :
ARM ist nicht gleich ARM. Der OP meint hier z.B. die ARM7 mit integriertem RAM und Flash und jeder Menge Peripherie im Chip und oft auch preisgünstigen nicht-BGA Gehäusen z.B. LPC2103 oder ST32. Also die typischen uC's wie früher der 8051. Das was Du meinst sind eher die ARM9, an die man extern DRM's und Speicher dranlöten muss. Ich denk mal, dass ARM sich ziemlich durchsetzen wird, schon allein auch dadurch, dass man mit derselben Core-Architektur sowohl die Substeuerung eines Tranceiver IC's als auch den PDA abdecken kann. Aber ihmo ist die Core recht nebensächlich. Bei den typischen uC-Anwendungen zählen eher gute Peripherie etc., geschrieben wird eh fast alles in C. Der ARM wird aber trotzdem so populär wie der 8051 werden (wobei ARM ja nicht ARM ist:-).
Mhh, naja wenn man gern viele Teile des Controller selbst entwickeln möchte... und meist sind FPGA's ja *Vorurteil an* eklige BGA's, klotzig gross und stromhungrig :).
M.
Reply to
Matthias Weingart
... und nach ein paar Jahren gibt es das gewaehlte FPGA nirgends mehr zu kaufen, jedenfalls nicht in Stueckzahlen.
--
Gruesse, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg
Ja, das geht (sowohl internes wie auch externes RAM). Allerdings ist er dann langsamer, weil halt der Vorteil der eigenen Busanbindung wegfällt.
Bei ARM7 war's glaub' ich noch umgekehrt -- da war Code aussem RAM schneller Flash..
--
Thomas Kindler
Reply to
Thomas Kindler
Na und. Portables VHDL rulez.
Gruß Oliver
--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Reply to
Oliver Bartels
Mag in Euren Marktsegmenten gehen. In meinen sieht das meist so aus:
a. Relayout b. Neuer EMV Test c. Danach alles zum TUEV/UL Check d. ECO schreiben e. Wochenlanges Regression Testing und so weiter
und wenn's ganz dicke kommt, z.B. bei dem was gerade auf meinem Arbeitstisch vorliegt,
f. Neue FAA oder sonstwelche Type Certification
Oder auf gut Deutsch ein ganzer Batzen Dollars an NRE.
--
Gruesse, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg
Was meint ihr, was "eure" Frauen wohl so denken?
--
mfg hdw
Reply to
horst-d.winzler
Sind die auch noch schnell genug, wenn man die in C programmiert? Ein Kollege schwört auf Assembler. Habe ihn letztens mal davon überzeugen können, die kostenlose Symphony-Umgebung für die Freescale-Teile zumindest mal auszuprobieren, aber nachdem ich dann gesehen habe, was die für Assembler produziert hat (insbesondere bei den kritischen Inner-Loops bei Signalverarbeitung und Stackhandling bei Unterfunktionsaufrufen), hatte auch ich dann nichts mehr dagegen, daß er die weiter in Assembler programmiert :-) zumal es nicht die schnellsten DSPs sind, da das Endprodukt preiswert sein soll.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss
"Igor \"Knight\" Ivanov" schrieb:
Coldfire V2 hast Du auch angeschaut? Z.B. Kirin 3? In Kleinmengen leider nur zu Mondpreisen erhältlich (Motorola-typisch), aber in Produktionsstückzahlen m.E. recht attraktiv.
Überlege Dir noch, was genau Dir an der langfristigen Verfügbarkeit einer "Architektur" wichtig ist. M.a.W. wo trifft Dich eine Umstellung am schlimmsten?
Bei der Firmware hilft Dir die herstellerübergreifende Verfügbarkeit der "Architektur" nur eingeschränkt. Das Anpassen auf die Peripherie eines CM3 von Hersteller B kann so viel Arbeit machen wie die Umstellung auf einen ganz anderen Controller.
Bei der Toolchain kann es aber schon relevant sein. Ein ordentlicher Debugger und/oder Compiler können richtig ins Geld gehen.
Für ARM und Coldfire ist gcc aber wenigstens im Kern gut gepflegt. Bei den Bibliotheken gibt's wohl noch eher Potential für Verbesserungen.
Bleibt also ein Debugger. Wenn Du keine Lust auf Gebastel hast, wirst Du für einen CM3 Serial Wire Debugger ein paar hundert EUR ausgeben wollen. Beim Coldfire gäbe es Codeworrier (SCNR) mit einem P&E Interface, naja... Oder teuere Debugger von Lauterbach oder iSYSTEM.
Ein anderer Aspekt ist, in welchen Bereichen die Controller eingesetzt werden. Es soll ja Produkte geben, die länger als zwei Jahre gebaut werden. Dann gibt's auch die Controller länger. Vielleicht.
Servus
Oliver
--
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:
Reply to
Oliver Betz
Meine sagt immer danach, beim naechsten Besuch wuerde sie lieber meine Speise fuer sich bestellen :).
Reply to
Igor "Knight" Ivanov
Hallo, ALLE!
Absolut ins Schwarze getroffen. Es geht tatsaechlich um Mikrokontroller und nicht um Mikroprozessoren. Cortex-M3 wird auch des oefteren als eine spezielle Weiterentwicklung fuer die embedded Domaene bezeichnet (z.B. bei mikrocontroller.net: "Eine weitere aktuelle Variante des ARM ist der ARM Cortex-M3, der für Low-End-Anwendungen und als Konkurrenz zu 8- und 16-Bit Mikrocontrollern wie dem AVR und MSP430 gedacht ist." )
[...]
Ich teile diese Meinung auch, wie anfangs geschrieben, denn man sieht, dass auch die jenigen Hersteller, welche ihre "spezifischen" uCs im Programm haben (ATMEL AVR, TI MSP430, etc..), auch ARMs anbieten.
An dieser Stelle moechte ich schonmal ALLEN Bedanken, die bis jetzt geantwortet haben, und stelle die Frage, welche Evaluation/Development Kits und Entwicklungsumgebungen zu empfehlen sind. Fuer 8051 haben wir KEIL (uVision IDE), welche, wie ich verstehe, zwar um die Unterstuetzung von ARM7/Cortex-M3 erweitert werden kann, was aber bestimmt nicht billig kommt. Dank der oben zitierten Seite bin ich auch z.B. auf "CrossWorks" von Rowley und andere Entwiklungswerkzeuge gestossen.
Was wuerdet ihr Empfehlen?
TIA,
Igor.
Reply to
Igor "Knight" Ivanov
Das ist trotzdem gut, denn es vereinfacht einige spezielle Anwendungen, welche sich selbst im FLASH modifizieren wollen.
Reply to
Igor "Knight" Ivanov
*Igor \"Knight\" Ivanov* wrote on Wed, 09-05-06 21:43:
Meine ließ sich auf Reisen nie zu etwas neuem überreden, bestand auf etwas "sicherem" a la Wienerschnitzel und wenn das Essen kam wollte sie tauschen. Jung verliebt habe ich das auch jedes Mal getan.
Reply to
Axel Berger
Igor "Knight" Ivanov schrieb:
Ich stehe vor dem gleichen Problem und habe mir Rowley Crossworks 1.7.19 (mit dem Gnu Compiler im Hintergrund) und IAR EWARM 5.20 angeschaut.
Zur Code-Qualität: gcc Debug: 42856 Bytes gcc Release: 14024 Bytes IAR Debug: 4314 Bytes IAR Release: 3526 Bytes (alles ein und die selbe kleine Testapplikation für einen STM32 mit 128k Flash mit der STM32 FwLib).
Soviel mal dazu.
--
Mit freundlichen Grüßen

Frank-Christian Krügel
Reply to
Frank-Christian Krügel
Frank-Christian Krügelschrieb: "
Na dann ist ja alles klar. Jetzt verstehe ich auch, warum hier so viele von Assembler schwärmen. Bei den Zahlen ist Assembler sogar zwingend einzusetzen.
Dirk
Reply to
Dirk Ruth
Frank-Christian Krügel schrieb:
Hallo,
ist das beim gcc alles Maschinencode für die kleine Testapplikation selbst, oder ist da das meiste die eingebundenen Standardbibliotheksfunktionen für C?
Vielleicht muß man nur die Floatingpoint Unterstützung abschalten und die printf Funktion rausnehmen.
Bye
Reply to
Uwe Hercksen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.