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

"Igor \"Knight\" Ivanov" :

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.

Frank Buss :

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.

Uwe Hercksen schrieb:

Da steht nix von Qualität...

Und strippen?

Falk

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

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 + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

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

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

Kann gut an den unterschiedlichen Runtime-Bibliotheken liegen, so daß der Offset von ca. 11k konstant bleibt, wenn man mehr Code hinzufügt. War das gestrippt, also Größe ohne Debug-Infos?

Die Grafikdemo für das Luminary RDK-IDM-Board lag IIRC mit gcc bei ca. 70K - incl. TCP/IP, Webserver und Grafikbibliothek.

cu Michael

Mal off-records: Hast Du ne Ahnung, was E.F. mittlerweile so treibt? Schon ewig nix mehr gelesen.

Ciao - Carsten

Frank Buss schrieb:

[...]

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?

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:

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

Frank Buss schrieb:

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

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.

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

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: