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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

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

Quoted text here. Click to load it

Hab den Crossworks MSP430 im Einsatz. Bin zufrieden, guter Code kommt raus
(kriegt man in Assembler nicht viel besser hin), guter Debugger. Paul
reagiert auch bei Bugs (bzw. nicht laufender Lizenz - weil neuer Rechner ;-(
recht schnell und er treibt sich in den entsprechenden Foren auch rum. Ich
denke mal die ARM-Umgebung ist mindestens genauso gut.
Denkbar ist sicherlich auch gcc und Eclipse. Der gcc-arm sollte imho recht
ausgereift sein, da schon jahrelang und auf vielen Plattformen im Einsatz
(w├╝rd ja gern Deinen Testbericht hier lesen :-).

M.

Re: Frage zu ARM7/Cortex-M3 (im Rahmen der 8-bit ->32 bit Migration)
Quoted text here. Click to load it

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

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

Quoted text here. Click to load it


Kommt auf die Qualit├Ąt des Compilers an. Der Rowley f├╝r den MSP430 ist recht
gut; der mcpgcc war dagegen mal grottenschlecht (keine Ahnung was der heute,
4 Jahre sp├Ąter so erzeugt). Aber meher als 10% Overhead hat bisher kaum ein
C-Compiler erzeugt. Wenn es wirklich eng wird, muss man dann aber manchmal
trotzdem noch von Hand optimieren und den Output des C-Compilers im Assembler
verbessern. Meistens spielt es aber keine grosse Rolle, ob er 5% Takte und
Code mehr braucht. Die Ersparnis bei ev. sp├Ąterer Portierung auf einen
anderen Controller wiegt das bei weitem auf.

M.

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

Quoted text here. Click to load it

Bei DSPs w├Ąre ich mir da nicht so sicher, ob das nur 5% langsamer wird. Die
haben z.B. f├╝r Audioverarbeitung optimierte 24-Bit Register, was f├╝r einige
Assembler-Rechenoperationen einen Fixedpoint-Wert von -1 bis +1 darstellt,
spezielle Adressmodi und andere interessante Instruktionen (man kann damit
z.B. eine FFT mit einen recht kurzen Assembler-Block umsetzen). Als ich den
C-Compiler ausprobiert hatte, hat der f├╝r eine einfache Multiplikation
dagegen schon eine Unterroutine angesprungen. Ich w├╝rde mal sch├Ątzen, wenn
man das portabel in C programmiert, da├č das dann 300%-400% langsamer w├Ąre,
als von Hand erstellter Assembler. Ist auch nicht so schwierig, da der
Befehlssatz an 6502 erinnert (ist ja auch von Motorola), was zumindest
besser als x86 ist und eher darauf ausgelegt, von Hand programmiert zu
werden, anders als z.B. der ARM-Befehlssatz, der eher f├╝r optimierte
Umsetzung von C-Code geeignet ist, da zumindest ich nie behalten kann,
welche Post-, Pre- usw. Operationen man am besten mit einem Befehl jeweils
kombiniert f├╝r ein optimales Ergebnis.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de , http://www.it4-systems.de

Re: Frage zu ARM7/Cortex-M3 (im Rahmen der 8-bit ->32 bit Migration)
Quoted text here. Click to load it

Nimm einen gescheiten Compiler und DSP, dann wird die Multiplikation,
wenn man es richtig anstellt, inline gemacht.

So sowohl bei TI als auch bei Analog Devices Blackfin.

Deren Compiler vektorisieren je nach den M├Âglichkeiten des DSP
ganz massiv, es werden z.B. Schleifen erkannt, umgestellt und
durch Repeat-Befehle ersetzt.

Allerdings sollte man dann auch im Handbuch nachschauen,
unter welchen Bedingungen (Compiler-Switches, Datentypen,
Konstellationen) vektorisiert wird, h├Ąufig liegt es an einer
Kleinigkeit, z.B. streng normgerechte Fehlerbehandlung, dass eine
Bibliotheksroutine aufgerufen wird.

Ansonsten k├Ânnen moderne Compiler mit der Datenflu├čanalyse
diesbez├╝glich schon extrem leistungsf├Ąhig sein.

Gru├č Oliver

--
Oliver Bartels + Erding, Germany + snipped-for-privacy@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

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

Quoted text here. Click to load it

Werde ich vielleicht mal ausprobieren, zumal auch der Support von Freescale
in letzter Zeit nicht mehr so gut ist (gibt keinen direkten Ansprechpartner
mehr, den man anrufen kann, Supportanfragen per Webformular z.B. zu
DMA-Transfer werden von China aus mit Zitaten der Webseite beantwortet oder
nicht funktionierenden Code-Beispielen usw.).

Quoted text here. Click to load it

Ja, das w├Ąre vielleicht eine Idee. Gibt ja auch kommerzielle Anbieter f├╝r
die Freescale DSPs, vielleicht sind die besser. Problem bei der Firma ist,
da├č die gerne bei altbew├Ąhrtem bleibt. Aber daf├╝r bin ich ja als Externer
dabei, um da von Zeit zu Zeit mal neue Ideen einzubringen :-)

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de , http://www.it4-systems.de

Re: Frage zu ARM7/Cortex-M3 (im Rahmen der 8-bit ->32 bit Migration)
Frank Buss schrieb:

[...]

Quoted text here. Click to load it

in letzter Zeit?

_Wann_ war es denn zuletzt so, da├č Du schnell eine kompetente Antwort
bekommen hast?

Oder hattest Du eine Methode, den first level Support zu umgehen?

Quoted text here. Click to load it

Kenne ich schon seit Jahren so. Bis der 1st level das an die
Entwickler weiterreichte, brauchte man schon drei Runden. Danach drei
Wochen.

Servus

Oliver
--
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

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

Quoted text here. Click to load it

Der Kollege hatte da eine Durchwahlnummer zu jemanden bei Freescale in
Deutschland. Nur leider arbeitet der nicht mehr f├╝r Freescale, soda├č es
jetzt den offiziellen Weg gehen mu├č, mit den bekannten Folgen.

Die Datenbl├Ątter sind auch ein wenig chaotisch. Statt mal eine
Registertabelle kommt das auch mal im Flie├čtext vor und man mu├č im Prinzip
immer mehrere Stellen gleichzeitig im PDF auf haben, um die notwendigen
Informationen herauszulesen, um das in Code umzusetzen, wobei man manchmal
schon raten mu├č, welche Adresse zu welchem Registernamen jetzt passt.
W├╝rden die das verbessern, und mehr und besseren Beispielcode zur Verf├╝gung
stellen, dann w├╝rden wohl viele Supportfragen gar nicht erst auftreten. Die
DSPs an sich haben schon eine gute Qualit├Ąt und man bekommt auch noch alte
Typen sehr lange geliefert.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de , http://www.it4-systems.de

Re: Frage zu ARM7/Cortex-M3 (im Rahmen der 8-bit ->32 bit Migration)
Frank Buss schrieb:

Quoted text here. Click to load it

ja, da gab es ein paar Spezialisten, die aber bei den Problemen, die
_ich_ mit den Controllern hatte, auch passen mu├čten.

Quoted text here. Click to load it

nicht nur das. Es fehlen schlichtweg wichtige Informationen (zumindest
bei den "nicht-DSP" Microcontrollern). Und trotz Service Request
stehen die nach einem Jahr immer noch nicht drin. Das binde ich jedem
Freescaler auf die Nase, viele sagen "ja, wissen wir, wollen wir
verbessern", aber die Fortschritte sind kaum zu erkennen.

Quoted text here. Click to load it

...und damit unter'm Strich Arbeit einsparen. Wenn sie nur mal die
_Investition_ angehen w├╝rden, das Management der Dokumentation zu
verbessern.

Quoted text here. Click to load it

Trifft auch auf deren anderen Controller zu. Liegt wohl auch an der
Kundschaft.

Servus

Oliver
--
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

Re: Frage zu ARM7/Cortex-M3 (im Rahmen der 8-bit ->32 bit Migration)
Quoted text here. Click to load it

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

--

Re: Frage zu ARM7/Cortex-M3 (im Rahmen der 8-bit ->32 bit Migration)
Quoted text here. Click to load it

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



Re: Frage zu ARM7/Cortex-M3 (im Rahmen der 8-bit ->32 bit Migration)
"Igor \"Knight\" Ivanov" schrieb:

Quoted text here. Click to load it

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:

Site Timeline