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 ?
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.
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.
Hallo, wie sieht es eigentlich von der Performance (der Firmware) aus bei MSPGCC, im Vergleich zu IAR und CCS?
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
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.
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).
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
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.
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.