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

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

MfG JRD

Solange man nicht die Frau am Nachbartisch leckerer findet?! :-)

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/

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

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 
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für Sensoren

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.

... und nach ein paar Jahren gibt es das gewaehlte FPGA nirgends mehr zu kaufen, jedenfalls nicht in Stueckzahlen.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

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

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

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/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Was meint ihr, was "eure" Frauen wohl so denken?

--
mfg hdw

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

"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:

Meine sagt immer danach, beim naechsten Besuch wuerde sie lieber meine Speise fuer sich bestellen :).

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.

Das ist trotzdem gut, denn es vereinfacht einige spezielle Anwendungen, welche sich selbst im FLASH modifizieren wollen.

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

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

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

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