MSPGCC Toolchain für MSP430 Familie

[Harry (Gast)]

Guten Morgen allesamt,

Hat zufällig jemand von Euch schon Erfahrungen mit der GCC Toolchain für 
den MSP430 von Texas Instruments?

Zum Beispiel in Relation zu IAR oder CCS?

Ist diese Toolchain brauchbar ?

[Sebastian (Gast)]

MSPGCC gibt es schon lange. Soweit ich weiß, schon bevor TI's Code 
Composer populär wurde. Die Qualität dürfte ähnlich AVR-GCC sein. Ich 
weiß nicht, ob das Problem heute noch aktuell ist, aber früher mußte 
man, wenn man beide auf einem (Windows-) PC haben wollte unbedingt 
MSPGCC als zweites installieren, nach AVR-GCC.

[Christian R. (supachris)]

Also prinzipiell ist der Compiler äußerst brauchbar und wird auch 
mittlerweile im mspgcc4 weiter gepflegt. Was bissl fehlt ist die 
sinnvolle Integration des Debugging in Eclipse. Es geht zwar so 
leidlich, aber es fehlen einfach viele Sachen. Außerdem muss man aus dem 
alten mspgcc3 Projekt den msp430-gdbproxy benutzen. Denn TI hat offenbar 
das API für die msp430.dll zum Ansteuern der Debugger den mspgcc 
Entwicklern nicht freigegeben. Prinzipiell kann man aber damit ganz gut 
arbeiten, wenn man sich etwas an die Eigenheiten gewöhnt hat.

Die Sache mit der Installationsreihenfolge ist nicht mehr. Das lag an 
der Cygwin-Krankheit, die bei älteren mspgcc Versionen erforderlich war. 
Aber alle aktuellen Versionen laufen nativ in Windows.

[ebtschi (Gast)]

Hallo,

wie sieht es eigentlich von der Performance (der Firmware) aus bei 
MSPGCC, im Vergleich zu IAR und CCS?

[Strubi (Gast)]

Christian R. schrieb:
> Außerdem muss man aus dem
> alten mspgcc3 Projekt den msp430-gdbproxy benutzen. Denn TI hat offenbar
> das API für die msp430.dll zum Ansteuern der Debugger den mspgcc
> Entwicklern nicht freigegeben

Das hat sich wohl etwas geaendert, inzwischen gibt es einigen 
OpenSource-Kram, siehe auch "mspdebug". Funktioniert unter Linux prima 
mit dem Launchboard (knappe 5 USD).
Zum Compiler kann ich nur sagen: der GCC hat IMHO die beste Architektur, 
und der Code fuer den MSP430 ist, soweit ich das beurteilen kann, 
optimal. Bin mir allerdings nicht sicher, ob nun Support für die 
allerneusten MSP430 (mit erweiterten Registern) vorhanden ist.

Gruss,

- Strubi

[Christian R. (supachris)]

Ja, mspdebug kenne ich, aber ich arbeite mit Windows. Da gehts mit dem 
msp430-gdbproxy auch ganz gut. Schlecht ist nur die Unterstützung des 
Eclipse GDB Interfaces, Kommandos wie Restart und Stop Over werden da 
beispielsweise nicht richtig unterstützt. Ansonsten funktioniert es, und 
da man die msp430.dll und hil.dll austauschen kann, kann man auch 
aktuelle Chips debuggen.
Der mspgcc4 kann auch die aktuellen MSP430X Chips mit den erweiterten 
Registern. Die letzte Windows Version ist zwar noch vom Febraur 2010, 
aber mit den Patches kann man den offenbar notfalls selber neu bauen.

Was mir aufgefallen ist: Auf einem MSP430F1121A erzeugt der mspgcc4 bei 
einem Projekt mit den gleichen Compiler-Settings, gleichem Quellcode 
etwa 300....400 Byte mehr Programmcode. Wieso auch immer.

[Klaus T. (gauchi)]

Sofern sich "brauchbar" auf die Bedienbarkeit bezieht:

Ich hab nach kurzem Einlesen auf hackaday.com (da gabs ein Tutorial zum 
LaunchPad) mein eigenes Programm mit msp430-gcc und mspdebug recht 
schnell auf dem Prozessor gekriegt, allerdings läuft mspdebug am Mac nur 
mit sehr viel nachhelfen.

Das Demoprogramm von TI zu compilieren hab ich dagegen mit IAR gar nicht 
und mit CCS erst nach einigem basteln hinbekommen, ein hex oder gar elf 
file was ich mit mspdebug flashen könnte habe ich nicht produzieren 
können (geht sicher, aber ich wollte keine weitere Zeit darin versenken 
herauszufinden wie).

Mit gcc und Makefiles arbeite ich schon seit Jahren, daher fiel mir das 
leicht. Vermutlich ist die GUI der beiden kommerziellen Compiler 
einfacher zu durchblicken (aber nicht für mich).

[Achim M. (minifloat)]

Klaus T. schrieb:
> allerdings läuft mspdebug am Mac nur
> mit sehr viel nachhelfen

Geht schon, da gibts doch ein fertiges Paket irgendwo.
Ah hier: http://osx-launchpad.blogspot.com/

Das einzige was am Mac stört, ist, dass der USB-UART(von TI Virtual Com 
Port genannt) nicht geht. Mspdebug läuft seit Einbinden des "codeless" 
.kext tadellos.

mfg mf

[Klaus T. (gauchi)]

Mini Float schrieb:
> Das einzige was am Mac stört, ist, dass der USB-UART(von TI Virtual Com
> Port genannt) nicht geht.

Den hab ich inzwischen sogar ans laufen gebracht (dafür brauchte ich die 
Original-Firmware, damit der Controller was sendet, was ich empfangen 
kann), allerdings nicht als Kernel-Treiber sondern mit libusb und 
Python.
Ich hab allerdings noch nicht gut genug verstanden was ich da tue, um 
das zu veröffentlichen.

Mini Float schrieb:
> Mspdebug läuft seit Einbinden des "codeless"
> .kext tadellos.

Das ging bei mir nicht so tadellos, bei mir muss ich mspdebug als root 
ausführen und selbst dann klappt es nicht immer.

[Christian R. (supachris)]

Klaus T. schrieb:
> ein hex oder gar elf
> file was ich mit mspdebug flashen könnte habe ich nicht produzieren
> können

Naja, Hex geht, elf natürlich nicht. IAR erzeugt was eigenes und CCE 
wenigstens COFF, aber beides nicht mit dem gdb verwendbar.