Hallo zusammen, nachdem ich leider an die 8K Codegrößenlimitierung des IAR Embedded Workbench in der Kickstart Version anstoße, habe ich mir gedacht ich würde es mal mit Eclipse und MSPGCC probieren... Die Anleitungen hier in diesem Forum sind ja alle sehr veraltet, daher habe ich mich stark an dem Vorgehen dieser Webseite http://xpg.dk/projects/msp430/msp430-eclipse/ orientiert. Hier mal die Schritt für Schritt Liste: 1) Neuste Eclipse Version installiert (Luna) 2) xPG-Webseite als Plugin-Repo angegeben und das dortige Plugin für den MSP430 installiert 3) Toolchain-Paket der xPG-Webseite runtergeladen und entpackt 4) In Eclipse über den Menüpunkt MSP430 auf das Toolchain-Paket verwiesen und auf aktivieren geklickt 5) Projekt nach Anleitung der xPG-Webseite erstellt und siehe da: Es kompiliert! Leider funktioniert das Debugging für mich nicht, wie es auf der xPG-Webseite beschrieben ist. Ich verwende den olimex JTAG-Tiny (v1) über USB. Daher jetzt das Vorgehen fürs Debugging aus einer anderen Anleitung (http://www.mikrocontroller.net/articles/Eclipse_und_MSPGCC_unter_Windows): 1) Altes Paket installiert und den msp430-gdbproxy gesichert 2) Altes Paket deinstalliert und neues Paket installiert, msp430-gdbproxy rückgesichert Danach - für die Einstellungen in eclipse - habe ich mich mehr an dieser Anleitung orientiert: http://www.mikrocontroller.net/articles/MSP430_eclipse_helios_mspgcc4_gdb-proxy Wenn ich den msp430-gdbproxy per Kommandozeile starte, dann findet er mein olimex-Board samt MSP430F5438. Wenn ich nun in eclipse auf "Debuggen" klicke, dann scheint die Kommunikation mit dem Proxy auch zu funktionieren (es erscheinen jede Menge Write/Read Ausgaben in der Kommandozeile). Eclipse wechselt daraufhin in die Debugansicht und jetzt kommt (meines Erachtens nach) der Fehler: In der Debug-Ansicht erscheint der rote Fehlertext: Can't find a source file at "../../../gcc-4.6.3/gcc/config/msp430/crt0.S Locate the file or edit the source lookup path to include its location Und genau hier komme ich nicht weiter... Ich schätze ich bin kurz vorm Ziel, aber der letzte Schritt hier bringt mich zur Verzweiflung. Sitze jetzt seit heute morgen daran die IDE aufzusetzen und würde mich über ein wenig Unterstützung echt freuen. Habt ihr eine Idee, wie man diesen Fehler beheben kann? Und noch eine andere Frage: Ist das überhaupt noch zeitgemäß eclipse mit MSPGCC zu benutzen? Oder sollte ich lieber den TI-Compiler (http://www.ti.com/tool/msp430-gcc-opensource) verwenden? Was benutzt ihr zum Programmieren? CodeComposer oder IAR? Ich bin mir halt nicht sicher, ob sich es sich lohnt noch weitere Arbeit darein zu investieren, wenn mich das Paket am Ende eh nur enttäuschen wird... Notfalls muss ich halt mir der 30-Tage Testversion von IAR ohne Codegrößenbeschränkung weiterarbeiten... Jedenfalls: Ich freue mich über jede Antwort und jeden hilfreichen Hinweis :-)
Aber auch Code Composer verfügt doch über eine Größenbeschränkung oder sehe ich das falsch?
Ist der CodeComposer nicht frei, wenn man das Launchpad nimmt? Ich dachte ich hätte mal sowas gelesen...
Ich versuche mich zur Zeit an STM32s, fuer (wer hat das DE-Layout geklaut ?) MSP430s habe ich Eclipse mit genau dem Plugin genommen. Ich habe aber nur Launchpads und einen TI MSP430-FET, das spielte alles ohne Probleme. CCSv6 kann mit einem RedHat mspgcc installiert werden, da sollte das Codelimit dann wegfallen. Ob da der Olimex JTAG einzubinden ist weisz ich nicht. Wenn es in die Tiefen geht bin ich genauso hilflos, nur eine Idee: Ein simples Projekt ist angelegt und kompiliert ? Zu den ganzen kommerziellen IDEs: Die basieren auch alle auf Eclipse.
Ja, ein einfaches Testprojekt mit main und endschlosschleife und ein, zwei Variablenzuweisungen ist angelegt. Es kompiliert fehlerfrei und wird (glaube ich) auch auf den Controller übertragen. Sobald eclipse in die Debugansicht wechselt, erscheint jedoch die obige Fehlermeldung... So lange ich hier keine weiteren Hinweise bekomme, werde ich mich ein wenig mit dem CodeComposer beschäftigen. Wenn ich das richtig lese, kann über das "App-Center" im CodeComposer der GCC-MSP angewählt werden, bei welchem dann die Größenbeschränkung wegfällt... Ich bin gespannt...
Ja sorry, hatte es beim zweiten Lesen erst unter Punkt 5 wahrgenommen. Bleibt immer noch das Problem mit dem JTAG Adapter. Zur Not ein billiges MSP430G2 Launchpad kaufen und den Onboard-Adapter verwenden. Es gibt einen Thread zum Plugin auf 43oh.com, xpg selbst gibt dort Antworten. http://forum.43oh.com/topic/1419-eclipse-plugin-for-mspdebug-and-msp430-gcc/
:
Bearbeitet durch User
Ich würde auf jeden Fall Code Composer Studio (CCS) nehmen, damit sollte alles einwandfrei funktionieren und der wird auch aktiv supported. Die kostenlose Version hat eine Codelimite von 16kB. Das sollte bei Dir ja vorerst reichen. Mit dem GCC und dem Thema Debuggen hatte ich früher auch nur Probleme; lieber Finger weg...
Ich werde mal nachschauen, ob mein JTAG Adapter mit dem Coder Composer Studio kompatibel ist. Ich schätze mal mit dem simplen Austauschen der DLLs ist es hier - ähnlich wie beim IAR EW - getan. Zur Codegröße: Bei meinem derzeitigen Projekt bin ich gerade 160 Byte unter dem Limit vom IAR EW. Daher bin ich halt auf der Suche nach Alternativen - möglichst auch ohne Limitierungen...
Es gibt übrigens eine Integration von gcc/gdb in Visual Studio (ab 2005) namens "Visual GDB", die als "Embedded"-Variante auch die Nutzung von MSP430 erlaubt. Das ist nicht kostenlos (64 EUR netto) und funktioniert vor allem nicht mit den kostenlosen "Visual Studio Express"-Varianten, aber im Rahmen von Arbeit o.ä. kann es ja vorkommen, daß man ein Visual Studio herumliegen hat und die Oberfläche gewohnt ist. Nein, ich habe es noch nicht getestet.
Em::Blocks ist vielleicht auch noch eine Alternative(nur Windows). http://www.emblocks.org/web/supported-emulators/others
Hallo zusammen, ein kurzes Update von mir: Ich habe mir das CodeComposerStudio in Version 6 runtergeladen und installiert. Nach der Installation habe ich alle Updates installiert und mir über das App-Center einige Zusatzfunktionen installiert (hauptsächlich den mspgcc-Compiler). Ohne mein Zutun kam die IDE daraufhin aber nicht mit meinem olimex JTAG Tiny zu Recht. Ich habe dann die DLL-Dateien im CodeComposer mit den DLL-Dateien von der olimex-Homepage ersetzt. Die neuste Version der Treiber funktioniert dann mit CodeComposer und meinem Programmieradapter soweit ganz gut. Ganz gut bedeutet: Das Programm wird auf den Mikrocontroller geladen. Inwiefern das Debugging funktioniert konnte ich noch nicht testen. Falls Interesse besteht, kann ich meine Erfahrungen aber im Laufe der Woche hier teilen... Viele Grüße, Roland
Stephan Goldenberg schrieb: > Em::Blocks ist vielleicht auch noch eine Alternative Das habe ich auch installiert und den mspgcc nach geladen. Das Ganze läuft soweit. Aber Debuggen über Launchpad funktioniert nicht, nur mit MSP-FET430UIF
Roland M. schrieb: > Ohne mein Zutun kam die IDE daraufhin aber nicht mit meinem olimex JTAG > Tiny zu Recht. Ich habe dann die DLL-Dateien im CodeComposer mit den > DLL-Dateien von der olimex-Homepage ersetzt. Die neuste Version der > Treiber funktioniert dann mit CodeComposer und meinem Programmieradapter > soweit ganz gut. Welche Version der Treiber hast du da benutzt? Ich hab nämlich auch noch einen V1-Tiny und hatte den unter CCS5 nicht zum Laufen bekommen. Wenn der jetzt mit der 6 und dem GCC gehen würde, wäre das ja ideal. Auf Arbeit nehmen wir nur noch CCE6 mit GCC, ideale Lösung. Man hat einen GCC Compiler und dazu den sehr guten Debugger von TI, und völlig kostenlos. Der GDB ist nämlich komplett unbrauchbar.
Christian R. schrieb: > Welche Version der Treiber hast du da benutzt? Ich hab nämlich auch noch > einen V1-Tiny und hatte den unter CCS5 nicht zum Laufen bekommen. Wenn > der jetzt mit der 6 und dem GCC gehen würde, wäre das ja ideal. Auf > Arbeit nehmen wir nur noch CCE6 mit GCC, ideale Lösung. Man hat einen > GCC Compiler und dazu den sehr guten Debugger von TI, und völlig > kostenlos. Der GDB ist nämlich komplett unbrauchbar. Tut mir Leid, das kann ich dir nicht mehr sicher sagen. Ich habe eher im Schnelldurchlauf alle durchprobiert von alt nach neu. Ich glaube, dass es der neuste (von der olimex-Homepage) war, der dann funktionierte. Noch ein kleiner Hinweis: Nach jedem Aktualisieren der Treiber wird ein Firmwareupdate auf dem Programmieradapter durchgeführt. Außerdem habe ich bei mir noch das seltsame Verhalten, dass zu Beginn des Debugvorganges immer erst eine Fehlermeldung kommt. Wenn man dann jedoch auf "Retry" drückt scheint alles zu funktionieren... Viele Grüße, Roland
Christian R. schrieb: > Auf > Arbeit nehmen wir nur noch CCE6 mit GCC, ideale Lösung. Man hat einen > GCC Compiler und dazu den sehr guten Debugger von TI, und völlig > kostenlos. Kann bei Verwendung von CCE6 + GCC noch mit der alten LPT Schnittstelle arbeiten?
wolle g. schrieb: > Kann bei Verwendung von CCE6 + GCC noch mit der alten LPT Schnittstelle > arbeiten? Keine Ahnung, wir haben die original TI USB Debugger auf Arbeit, also die UIF. Geht das denn überhaupt noch unter Windows 7 x64?
:
Bearbeitet durch User
So, ich hab eben mal probiert. Also prinzipiell läuft das Debugging mit dem alten JTAG-TINY V1 auch mit CCE 6.0 und der Olimex DLL 1.0.42, aber bei jedem Beenden der Debug Session schmiert Eclipse dann komplett ab. Mit dem 5er hatte ich den Olimex gar nicht zum Laufen bekommen, anscheinend haben die jetzt im 6.0 eine Erkennung drin, ob es die DLL Version 2 oder 3 ist. Ich teste das zu Hause auch noch mal. Schade, dass der V1 nicht mehr supported wird.
Hallo, das Problem scheint denke ich mal schon bekannt zu sein, allerdings erhoffe ich mir keinen Support von TI, da ich ja den olimex JTAG-Programmieradapter benutze. Hier ist jedoch von einem ähnlichem Verhalten die Rede: http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/291218.aspx Leider gibt es diese Dateien in CCS6 nicht mehr... Ich habe jedoch auch einen recht aufwändigen Workaround gefunden: Bevor man das Debugging in eclipse beendet einfach das USB-Kabel aus dem Adapter ziehen. Dann die Debug-Session beenden, ein wenig warten und wenn man im Code-Editor angekommen ist, dann kann man das Kabel wieder einstecken ;-)
Christian R. schrieb: > die UIF. Geht das denn überhaupt noch unter Windows 7 x64? Ja Ohne Probleme, Wir haben hier auf Arbeit mehrfach die Kompination WIN 7 64 Bit CCSV6 und den TI MSP430 USB Debug Interface UIF
Natürlich funktioniert der MSP-FET430-UIF auch unter x64-Versionen von Windows. Was zu Problemen führen dürfte, ist der veraltete Frickelportadapter MSP-FET430-PIF. Der aber ist sowieso unattraktiv, weil er kein SBW unterstützt, und damit bei neueren MSP430-Varianten in Gehäusen mit wenig Pins sehr unvorteilhaft ist -- anders als bei der Verwendung von SBW gehen beim klassischen 4-Draht-JTAG nämlich I/O-Pins verloren.
Tobias Korrmann schrieb: > Ja Ohne Probleme, Wir haben hier auf Arbeit mehrfach die Kompination WIN > 7 64 Bit CCSV6 und den TI MSP430 USB Debug Interface UIF Klar, dass das geht. Die Antwort bezog sich auf die Frage nach dem ollen LPT Debugger.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.