Seit ein paar Tagen gibts ja endlich mal eine neue Version des MSPGCC. Ich hab sie mal ausprobiert, allerdings kann ich aus Eclipse heraus ein laufendes Programm nicht unterbrechen. Wor kann das liegen? Debuggen an sich klappt, einzig komisch ist, dass dieses Cygwin Geraffel den Lookup-Path erst mal nicht findet. Muss man ihn mit der Nase drauf stoßen. Breakpoints anspringen geht auch, aber wenn ich auf Pause drücke, passiert nix. Kommt auch im Verbose-Mode keine Ausgabe des msp430-gdb. Kann da jemand helfen? Wäre ja gut, wenn man die aktuellen Chips auch benutzen könnte. Achso: Ich nutze Win XP SP2, Eclipse Europa 3.3.2 mit CDT 4.03 und den original TI-USB Debugger. Mit der Version von Mai 2006 klappt´s bestens, nur die aktuelle macht Probleme.
Hallo Supachris, Wenn Du die Antwort selbst nicht kennst, dann verspricht das nichts Gutes! Hast du das Problem des Anhaltens mittlerweile gelöst? Wenn ja beschreib doch bitte wie! Wenn nicht: Hast du das Problem nur in Kombination mit Eclipse oder auch wenn du über die Kommandzeile arbeitest? Liebe Grüße Raphael http://develissimo.net
Nee, Konsole hab ich bisher nicht getestet, ich bin Mausschubser. Aber könnte ich mal machen, da muss cih mir erst mal die GDB-Kommandos raussuchen...*grummel*
So, hab mal getestet. Im reinen GDB scheints zu klappen. Jedenfalls kann ich ein laufendes Programm mit Strg+C unterbrechen. Dann muss es ja irgendwie an Eclipse liegen. Haben die das MI-Protokoll irgendwie geändert oder was? Ich hab alle Angebote von Eclipse durchprobier: Cygwin, Standard, Windows, jeweils MI, MI1 und MI2. Keine Änderung. Am 29.5. gabs ja gleich nochmal eine neue Version, die vom 21.5. ist schon wieder verschwunden. Aber keine Besserung zu erkennen. Neues CDT gab´s auch nicht....schon komisch. Aber zumindest kann die neue Version For-schleifen debuggen. Ein Fortschritt :)
So....mit der aktuellen Test-Version vom 3.6. klappt´s theoretisch wieder mit Eclipse. Aber dafür zickt der Compiler offensichtlich rum. Die haben irgendwas an den StartUp Codes geändert, bei mir hängt der sich immer auf beim Löschen der BSS Section. Ich denke mal, der Watchdog funkt dazwischen, ein deaktivieren mit:
1 | void __low_level_init(void)__attribute__((__naked__, __section__(".init3"))); |
2 | |
3 | void __low_level_init(void) |
4 | {
|
5 | WDTCTL = WDTPW+WDTHOLD; //Sitz....gib leise. |
6 | }
|
hilft leider nicht (mehr). Naja, mal schauen, wann es wieder eine funktionierende Version gibt.
So, Chris Liechti war fleißig und hat die Fehler behoben. Jetzt klappts mit der aktuellen Test-Version vom 5.6.2008 in Verbindung mit Eclipse. Allerdings gibts einige Pferdefüße zu beachten. Die gdb-ini Datei muss geändert werden. Nur noch folgendermaßen: target remote localhost:3333 set remoteaddresssize 16 set remotetimeout 9999999 monitor erase main load D:/MSP430/GCC/xxx/Debug/xxx.elf Wichtig ist der absolute Pfad für das Elf-Image, sonst wird nix in den Flash geschrieben. Desweiteren muss der Interne Builder verwendet werden, make ist ja nicht mehr inbegriffen. Eventuell selbst angepasste Linker-Scripte müssen geändert werden, die haben eine neue Syntax jetzt. Getestet unter Windows XP. Am Wochenende schau ich mal, ob´s unter Vista auch klappt. Viel Spaß!
So. Klappt auch unter Vista einwandfrei. Absolute Pfade für die Elf-Datei sind doch nicht notwendig, nur muss es ein richtiger Slash sein, kein Backslash, wie bei den alten Versionen mit CygWin.
@Chris Du bist eindeutig ein Pro, was soll ich noch dazu sagen? Wuerde mich freuen, wenn wir Dich baldigst auch als Tester für die Linux-Version begeistern könnten. Könnte auch dir Vorteile bringen, denn ich schätze Dich als Non-Gamer ein. Kauf Dir ne Spielkonsole wenn du gamen willst. Ist ja eh schon fast alles Kompatibel! trau Dich mal Liebe Grüße Raphael
LOL. Nee, ganz bestimmt nicht. Erst wenn´s einen Treiber/Lib für den olimex USB Debugger gibt. Mein Rechner hat keinen Par-Port mehr, und den Olimex hab ich da. Und auf Arbeit spielt Linux keine Rolle. Ich hab ja einen Linux Server hier noch, der macht für mich Internet verteilen, Mail-Server, Homepage, VDR... Aber mein "Arbeits"- System bleibt Windows.
tja das stört mich auch. Derzeit läufts auf Grund der Treiber/so's (dll's) nur mit dem TI USB FET. Das liegt vorallem daran, dass sich die Leute bei Olimex vorallem auf die EPAs (die EinkommensProduzierendenArbeiten) konzentrieren. Soviel zur angepriesenen Kompatibilität und 100%tigen Übereinstimmung der OLIMEX USB Programmer MSP430-jtag-tiny und MSP430-jtag-iso. Aber angeblich sind sie ja deutlich schneller als die von TI. Nur bringt das der Linuxwelt leider auch nicht viel. liebe Grüße Raphael
Ja, der JTAG Tiny ist viel schneller als der original FET. Allerdings eben ohne Optokoppler und sonstige Schutzmaßnahmen. Aber ich denke mal, dass die wenigsten, die den MSP430 produktiv einsetzen, Linux am Laufen haben. Das werden wohl hauptsächlich die Privatanwender und vielleicht Unis sein. Ich arbeite im Institut ja auch viel mit dem MSP430, da nehme ich ebenfalls Eclipse und MSPGCC, einfach weil die Eclipse viel mehr Erweiterung-Möglichkeiten hat als IAR. Sonst hätt ich schon längst den IAR bestellt. Nun ja, also ich kann und will nicht zu Linux wechseln, werde die Windows Versionen aber weiterhin gerne benutzen.
ich konnte und habe zu Linux gewechselt! schon vor Jahren ;-)
Wenn ich mich da mal in euren Dialog einklinken darf.... Ich habe ebenfalls schon vor Jahre zu Linux gewechselt, und besitze mittlerweile bereits seit ca. 3 Jahre keine Windowsinstallation mehr. Allerdings möchte ich hier keinesfalls einen Glaubenskrieg vom Zaun brechen. Immerhin besitzen beide Betriebssysteme bzw. das damit verbundene Arbeiten ganz klare und objektive Vor- und Nachteile. An Tagen wie heute wünschte ich sogar, ich hätte noch irgendwo eine Windows-CD rumliegen... ;-) @Raphael: Ich vermute mal du hast den msp430-gdb unter eclipse (unter Linux) laufen, oder? Ich kann zwar auf der Konsole wunderbar debuggen, unter eclipse erhalte ich allerdings immer folgende Fehlermeldung:
1 | 294-gdb-set auto-solib-add on |
2 | &"No symbol \"auto\" in current context.\n" |
3 | 294^error,msg="No symbol \"auto\" in current context." |
Mein gdbinit sieht folgendermaßen aus:
1 | set remoteaddresssize 64 |
2 | set remotetimeout 999999 |
3 | set download-write-size 512 |
4 | set remote memory-write-packet-size 512 |
5 | set remote memory-write-packet-size fixed |
6 | set remote memory-read-packet-size 512 |
7 | set remote memory-read-packet-size fixed |
8 | |
9 | target remote localhost:2000 |
10 | |
11 | monitor erase |
12 | |
13 | load /home/user/MSP430F2131.hex |
14 | symbol-file /home/user/MSP430F2131.elf |
Löschen und Flashen klappt auch, aber danach kommt besagte Fehlermeldung und gdb beendet die Verbindung zum proxy. Könntest du mir verraten welche Version von gdb bzw. gdbproxy du verwendest? Wenn ich es richtig verstanden habe funktioniert ja nicht jede unter eclipse.... Besten Dank im Vorraus, odic
Also ich verwende den GDB 6.8 derzeit. Aber das tut nichts zur Sache denn der Fehler denke ich liegt hier bei Eclipse! Wenns in der Konsole klappt, dann funktioniert es unter Eclipse auch. Hast du Eclipse Europa installiert!? Solltest du nämlich!!! schau dir mal mein Tutorial an www.develissimo.net Da ist alles ausführlich beschrieben. Liebe Grüße Raphael
Mit der aktuellen Version vom 5. juni 2008 funktioniert das alles. Die erste Fehlermeldung hat nix zu sagen, die kommt beim mir auch manchmal. Das Beenden der Verbindung nach dem Flashen hatte ich mit den Versionen des GDb nach Mai 2006 und vor Juni 2008. Ob das jetzt direkt auf Linux übertragbar ist, weiß ich nicht.
@Chris: Ich habe folgende Versionen des msp430-gdbproxy mit dem gleichen Ergebnis getestet: - http://sourceforge.net/project/showfiles.php?group_id=42303 2006-11-14 - http://www.soft-switch.org/downloads/mspgcc/ 2006-07-08 Weißt du zufällig, woher ich eine ältere Version für linux bekommen kann? @Raphael: Danke für den Hinweis, ich werde heute abend mal einen Blick in dein Tutorial werfen. Installiert habe ich eclipse aus den Debian-Paketquellen (lenny). Soweit ich es aber aus dem Kopf sagen kann müßte es 3.2.2 sein. Viele Grüße, odic
Also bei den 2006er Versionen lief das generell nicht oder nicht stabil. Gibts denn die aktuelle Version nicht für Linux?
Konnte sie zumindest noch nirgends finden. Wobei.... reden wir jetzt eigentlich vom gdb oder gdbproxy??
Der GDB war immer das Problem. Aber für Windows gibts bei mir immer eine setup.exe fg
Ok, das heißt ich muß nicht mehr nach einer anderen Version des proxy suchen.... Irgendwie beginnt mich das ganze Thema langsam zu nerven. Eigentlich wollte ich Applikationsentwicklung betreiben und nicht IDE-Reengineering. Ich arbeite ja wirklich zu einem gewissen Grad aus Idealismus mit Open Source Software, aber machmal muß man schon arge Klimmzüge machen bis alles läuft. Allein bis ich die binutils soweit gepatched hatte daß der Linker meinen MSP430F2131 kennt.... Sorry, es soll sich bitte niemand angesprochen fühlen, aber das mußte einfach mal raus...
>Ich arbeite ja wirklich zu einem gewissen Grad aus >Idealismus mit Open Source Software, aber machmal muß man schon arge >Klimmzüge machen bis alles läuft. Das Nervige ist ja, dass man sich immer alles zusammensuchen muss. Eclipse hier, Plugins dort, Compiler wieder an einem anderem Ort. Dann ellenlange Anleitungen, die sich meistens auf ältere Versionen beziehen. Ist es eigentlich generell unter OpenSource so schwierig, eine Komplette Lösung anzubieten mit einer kurzen knackigen Anleitung, wo welche Pfade gesetzt werden müssen (falls dies nicht über die Enviroments automatisch gemacht werden kann). Ich habe über 2 Wochen benötigt, um Eclipse mit dem MSP430 und Debugger zum laufen zu bewegen. Den Debugger verwende ich eh nicht mehr. Das kaputte Ding gehört in die Tonne. Als Debugausgabe habe ich entweder ein Display oder die RS232-Schnittstelle.
Jo, unter Linux scheint das noch bissl grauenhaft zu sein. Unter Windows installiert man das MPSGCC Paket, installiert Eclipse und das PlugIn und dann klappts prinzipiell schon. Klar, sonderlich komfortabel ist das Erstellen eines neuen Projektes nicht, aber wenn man das einmal durchhat, kann man gut arbeiten. In der aktuellen Version ist auch der GDB endlich mal stabil. Bisher keine Abstürze mehr.
Jetzt muß ich mal blöd fragen... welches Plugin? CDT?
odic wrote: > Jetzt muß ich mal blöd fragen... welches Plugin? CDT? Nee, CDT ist bei Eclipse Europa ja dabei. Das hier: http://homepage.hispeed.ch/py430/mspgcc/index.html
@Gast: Ich denke, man muß hier immer nach den Ursachen fragen. Es gibt viele gute OpenSource Projekte die auch gut strukturiert sind und hinter denen einiges an Man-Power steht. In diesem Fall ist einfach die Konstellation ungünstig. Manche Komponenten die man benötigt werden noch voll weiterentwickelt, andere ruhen (oder sterben?) gerade, manches muß gepatcht werden (siehe binutils), ... Hinzu kommt, daß fast alle Teile die man benötigt von unterschiedlichen Personen / Gruppen entwickelt werden: binutils + patches, gcc + port + patches, eclipse + (embedded)CDT, gdbproxy inkl. TI-Geraffel, .... Ich persönlich finde die wichtigste Information in einem Tutorial immer diejenige welche mir sagt, welche Version von was womit zusammenspielt. Das Ganze drum herum (Optionen, Pfade, ...) ist nice-to-have, aber das würde man zur Not auch durch das Studium von Man-Pages und ähnlichem selbst hinbekommen. @Chris: Ich werde das Plugin mal ausprobieren. Wobei sich mir auf den ersten Blick nicht erschließt, wofür man es benötigt....
Ich werd Euch jetzt mal was erzählen :-) Das das ganze so ist wies ist, dafür sind die von Texas Instruments verantwortlich. Kein Wunder, sie haben eine sagen wir mal Tochterfirma die da IAR entwickelt, jedoch weil es sich auch gut macht Open Source zu unterstützen tun Sie es. Jedoch nur halbherzig! Trotzdem sind die Open Source Entwickler so gut, dass es sich lohnt damit zu arbeiten. Denkt Ihr wirklich das IAR Zeugs ist tatsächlich aus anderem Holz geschnitzt!? In Wirklichkeit haben die Teile die selbe Basis. Ist meistens so. Die IAR kochen auch nur mit Wasser! Das Problem bei der MSPGCC Toolchain ist, dass das ganze sehr unübersichtlich ist. Grund dafür ist, weil es eigentlich nur einen Core Entwickler gibt der das ganze betreibt. Er bräuchte ein Team, aber so wie ich das jetzt mitbekommen habe, ist der Typ selbst Texas Instruments Mitarbeiter, es scheint als wollen die TI Leute den Ball flach halten um ordentlich Kohle mit IAR Embedded Workbench zu machen. (verständlich) Jedoch nicht mit mir ;-) denn wie Ihr auf meiner HP sehen könnt, läufts unter Eclipse ordentlich und sauber. Hat zwar ne Ewigkeit gedauert, aber wenn man weiss wies geht, dann läufts ganz gut. So wie Chris schon sagte! Und zieht mir ja nicht über Open Source her, ich gebe zu bezüglich der MSPGCC Toolchain ist die Arbeit heavy, aber ich schreibe euch hier von einem Ubuntu Betriebssystem und das ist der HAMMER. Die ganze kommerzielle Software hat gravierende Schattenseiten. Lizenzurwald ohne Ende. Und wenn mal eine Firma pleite geht, dann geben Sie trotzdem sehr oft das Kochrezept nicht preis. Wenn bei einem Open Source Projekt mal einer keine Lust mehr hat, na dann machen eben andere weiter! Ich liebe Open Source. Ich finde die MSPGCC Toolchain jedoch auch umständlich. Aber der Grund ist, eigentlich ist es ja keine Open Source, sondern Closed Source und da müssen wir uns bei TI beschweren. Ein Open Source Entwickler der mit Freude nach der Arbeit 4 Stunden arbeitet bringt um einiges mehr weiter, als irgend ein bezahlter Nasenbohrer der 8 Stunden in der Arbeit auf den Feierabend wartet! Ist übertrieben, aber ich denke Ihr versteht wie ichs meine. Freue mich über Eure Meinungen / Berichtigungen. Liebe Grüße Raphael
Hallo Raphael, ist doch immer wieder eine interessante Diskussion, wenn auch schon hunderte Male im Netz geführt. Ich hoffe ich konnte verständlich machen, daß ich bei OpenSource prinzipiell sehr differenziere. Ich habe selbst schon mehrere meiner Projekte veröffentlicht und kann daher nachvollziehen, welchen Pflegeaufwand dies nach sich zieht. Auch hat man nicht immer genügend Zeit (und manchmal auch Lust) die teilweise an Unverschämtheit grenzende Anspruchshaltung der Nutzer zu befriedigen. Leider wird OpenSource häufig als eine Art Glaubensfrage disskutiert und das halte ich persönlich (obwohl ich auch ein OpenSource-Fan bin) für wenig sinnvoll. Es gibt sowohl aus Entwicklersicht als auch aus Nutzersicht sehr plausible Gründe sowohl für als auch gegen OpenSource. Ebenfalls existieren viele professionell entwickelte OpenSource-Produkte genauso, wie es eine Unmenge Schrott in diesem Bereich gibt. Der Begriff OpenSource sagt lediglich etwas über die Quellen, sowie teilweise etwas über Verbreitungswege und Lizenzmodelle aus, aber in keinem Fall etwas über Produktqualität (Code-Qualität, Kompatibilität, Benutzerfreundlichkeit, usw.). Im Falle des MSPGCC stehen einfach zu viele Entwicklungen bzw. Interessen einer einheitlichen und vor allem einfachen Nutzung im Wege. Das hat aber (mal abgesehen von irgendwelchen lizenzrechtlichen Geschichten bei TI) nichts mit OpenSource zu tun. Es steht einfach kein ökonomisches Interesse dahinter welches für einen gewissen Zug sowie die nötige Koordination sorgt. (Ohne jetzt behaupten zu wollen daß dieser bei proprietären Lösungen immer existiert.) Auch sage ich gar nicht daß das so gut oder schlecht ist, es ist einfach Fakt. Ich bin froh daß es diese Lösungen gibt und nehme den Aufwand teils aus finanziellen und teils aus idealistischen Gründen in Kauf. Was man hingegen vielen kommerziellen Lösungen zugute halten muß ist die Integration der Komponenten und die einfache Installation. Woher Compiler, Debugger, Hardwareabstraktion oder GUI beim IAR kommen kann ich natürlich nicht nachvollziehen. Allerdings kann ich (nach rechtmäßigem Erwerb) einfach eine CD einlegen und das Teil installieren. Genauso wie bei Tasking, Cosmic, Greenhills, CodeComposer, Lauterbach oder wie sie alle heißen. Ich habe beruflich verschiedene andere Compiler und Entwicklungsumgebungen im Einsatz und muß leider sagen, daß deren Anschaffungskosten teilweise geringer sind als das was die Inbetriebnahme des MSPGCC gekostet hätte, wäre es nicht nicht meine Freizeit gewesen. (Wobei ich auch noch die so lange für eine Inbetriebnahme gebraucht habe wie in diesem Fall. Und es läuft immer noch nicht.... :-( ) Patchen ist eine feine Sache wenn man es KANN, aber unheimlich lästig wenn man es MUSS. In diesem Sinne einen schönen Tag, odic
ja sehr oft geführt. Ich hab mich hinreissen lassen :-) Wie auch immer, bei mir läufts sehr gut. Bin sehr froh ohne IAR auszukommen. Es sieht auch noch GUI-mässig sehr schön aus. Gefällt mir. Eclipse ist mächtig und es ist klasse, da ich alles Programmiertechnische mit Eclipse erledige. C, Java, MSPGCC etc... Ich stimme Dir im Großen und Ganzen zu, jedoch was Du bezüglich der Kosten geschrieben hast ist relativ zu sehen. Denn kannst Du das System einmal installieren, dann wirst du es "vermutlich" auch die nächsten Male bewältigen. => Lizenzgebühren werden nicht nur einmal fällig, sondern meist bei jeder "neuen" Version. Somit können je nach Anwendung die Kosten der aufwändigeren Installation langfristig doch gegen fast NULL berechnet werden. OpenSource ist an einem Level angekommen, ab dem man tatsächlich gut damit arbeiten kann. Macht richtig Spaß und begeistert. Ganz toll!!! Schöne Sommertage Raphael
Hallo! Wollte heute die neue Version von mspgcc 2008 testen. Hab erst die Version vom 15.06. und dann die vom 05.06. probiert, allerdings klappt das nicht so richtig. Ich bekomme in der Console folgende Fehlermeldung: warning: Remote failure reply: E00 Im msp430-gdbproxy (USB) Dos-Fenster bekomme ich diese Meldung: debug: MSP430_Breakpoint(ADD) debug: Set breakpoint in BP reg 0 to 0x2c42 debug: MSP430_RUN() error: msp430: Could not run device (to breakpoint)(17) Eigentlich sollte der Debuger bei main halten, tut er aber nicht. Ansonsten sind keine Breakpoints oder der gleichen gesetzt. Im Debug Fenster bekomme ich noch ein "neues" Register: 2 InterruptVectors() 0x0000ffff mit dem Text: No source available for "InterruptVectors()" Das hatte ich aber glaub bei der 2006er Version auch schon und hat nicht weiter gestört. Der Source Code lies sich mit der Version von 2006 einwandfrei debugen. Daran sollte es also nicht liegen. Woran kann es liegen? Hatte jemand einen ähnlichen Fehler? Ich verwende den MSP430x149 und den OLIMEX USB-Tiny mit der Treiber Version 1.12. Diese Kombination hat wie gesagt mit der mspgcc von 2006 funktioniert. Olimex Treiber habe ich auch in den Bin Ordner kopiert. In den Einstellungen habe ich nen Internen Builder ausgewählt. Eclipse Version: 3.2.2 Danke schon mal! Gruß Andi
Wird das Programm geladen? Im Gegensatz zur alten version von 2006 müssen die Pfadnamen in der gdb-ini Datei jetzt / statt \ haben. Und einige remote Befehle versteht der nicht mehr. bei mir sieht das nur noch so aus: target remote localhost:3333 set remoteaddresssize 16 set remotetimeout 999999 monitor erase main load Debug/Test.elf Funktioniert mit dem USB JTAG TINY von Olimex unter Vista Business 32 Bit, Eclipse Europa 3.3.2 einwandfrei und schnell. Die allerneuste Version vom 19.6. kannte ich noch gar nicht, gleich mal testen.... Edit: Die MSPGCC Verison vom 19.6. funktioniert genauso gut bei mir. Eben getestet.
Hi! Danke, fehler gefunden! Ich hatte den \ in der gdb-ini nicht auf / geändert! Jetzt läuft es ebenfalls. Werde dann auch wieder auf die neuere Version umsteigen. Wo kann man eigentlich nachlesen welche Derivate alles unterstützt werden? Was mich allerdings noch interessieren würde, bei der IAR KickStart Version konnte man sich die ganzen Register z.B. TACTRL, TAR, TACCRx, TAIV, PxOUT usw. anschaun, geht das mit mspgcc auch irgendwie? Das habe ich jetzt schon ein paar mal vermisst
Einfach bei -mmcu in den Compiler-Settings was unsinniges reinschreiben, dann spuckt der gcc aus, welche unterstützt werden. Solche Register geht leider nicht ganz so komfortabel wie bei IAR oder CCE, aber bei Eclipse kannst du einfach bei Watch Expression da oben rechts in der Debug-View den Registernamen eingeben, da holt der sich den Wert.
Hab bei den Expressions mit "Add Watch Expression" -> TAIV, TAR, TACCR0 hinzugefügt. Bekomme jedes mal: Target request failed: mi_cmd_var_create: unable to create variable object. P3OUT wiederum funktioniert.
Dann musst du mal in die Header-Files gucken, ich glaub die heißen minimal anders: TA0CCR0 meines Wissens statt TACCR0.
ok, mit TA0IV und TA0CCR0 geht. Allerdings steht im Headerfile:
1 | #define TAIV TA0IV
|
1 | #define CCR0 TA0CCR0
|
verstehe ich nicht ganz warum er dann die "kurzen" schreib weisen nicht mag. Im Source Code nimmt er ja CCR0 auch an. Aber gut, das andere geht. Danke
Nach einigen stressigen Tagen melde ich mich wieder zurück.... leider immernoch mit dem selben Problem. Mittlerweile habe ich eclipse auf die aktuelle Ganymede upgedated, leider ohne daß dies eine Veränderung gebracht hat. Da ich nun die Versionen vor und nach Europa getestet habe, vermute ich mal nicht daß es an eclipse liegt. So langsam gehen mir die Ideen aus....
auch ich wollte es mal mit eclipse + mspgcc versuchen. zunächst zwei Fragen: a) was ist der Unterschied zwischen debug und release b) was ist ein TCP- Anschluss bzw. wo stelle ich auf einen LPT-Anschluss ein verwendet habe ich: eclipse-cpp-ganymede-win32.zip net.sf.mspgcc.zip mspgcc-20080605.exe MfG Wolfgang
Hallo, also, zwischen Debug und Realease ist kein großartiger Unterschied, zumindest nicht in dem Programm, was für den MSP erzeugt wird. Eventuell sind im Compiler-Ausgabe-File keine Debug-Informationen enthalten, weiß ich aber nicht. Der TCP-Anschluss ist halt ein Anschluss zur Verbindung zwischen dem Deubug-Server (msp430-gdb) und dem Debug-Proxy (msp430-gdbproxy). Da die ganze Sache aus der Linux-welt kommt, ist das halt etwas komplizierter. Im Prinzip ist die Kommunikation folgendermaßen: MSP430 <---JTAG---> JTAG-Debugger <---LPT/USB---> msp430-gdbproxy <---TCP---> msp430-gdb <---> Eclipse. Du kannst den TCP Anschluss nicht direkt auf den LPT umstellen, da muss immer der gdbproxy dazwischen sitzen. Den startest du außerhalb von Eclipse über das Startmenü. Der muss auch die ganze Zeit geöffnet sein, wenn du Debuggen willst. Nur der versteht JTAG nach unten und die gdb-kommandos nach oben hin. Eclipse kann nur mit dem gdb-server sprechen. Übrigens ist die Version des MSPGCC Paktetes nicht funktionsfähig, du musst die vom 15.6 oder 19.6. nehmen. Da wo Test dran steht. Die geht dann.
Vielen Dank für die Beantwortung meiner Fragen. Ich bin jetzt ein Stück weitergekommen. Zunächst habe ich, wie von Dir beschrieben, msp430-gdbproxy gestartet und versucht das Programm in den µC zu laden. Nach einer gewissen Zeit kam die Fehlermeldung: MSP430 error: Could not determine device state (18) Danach habe ich zunächst eine *.elf Datei erzeugt und diese mit msp430-downloader.exe in den µC geladen. Jetzt konnte ich auch mit Eclipse das Programm übertragen und das Programm mit Run starten. Bei Einzelschrittbetrieb kam der Absturz dann aber schon nach 2. oder 3 Zeile. Für mich ist das noch nicht das Gelbe vom Ei. Aber vielleicht habe ich auch zu wenig Ahnung vom Programmieren. Diesmal verwendet: mspgcc-20080619.exe MfG Wolfgang
Die Fehlermeldung kommt, wenn an der Hardware was nicht stimmt, und die JTAG-Verbindung zwischen Debugger und µC nicht OK ist. Das luegt nicht am MSPGCC. Ich hab das immer mal bein instabiler Versorgungsspannung oder so. Das Programm kannst du über den GDB beim Start des Debuggen auch aufspielen, in der .ini Datei für den GDB ist das der Load Befehl.
Hallo Christian, die Bedienung der CCE-Eclipse-Oberfläche von TI erschien mir benutzerfreundlicher als das, was man da mit den oft nicht mehr so ganz zutreffenden älteren Anleitungen zu Eclipse so zustandebringt. TI hat mir soeben mitgeteilt, daß es eine Möglichkeit gibt den MSPGCC GNU Compiler in die CCE zu integrieren. Angeblich sei dies im Web zu finden. Weißt Du oder jemand anders etwas darüber oder kennst Du den Link? Gruss Matthias
Nein, kenne ich nicht. Aber das eigentlich gute am CCE ist ja der Debugger und dessen hervorragende Integration in Eclipse. Da könnten sich viele eine Scheibe abschneiden (AVR-Studio...). Und das Elf file vom GCC wird wohl kaum kompatibel zum COFF-Format des TI-Kompilers machbar sein.
Hallo Christian, hältst Du es für sinnvoll die CCE von TI zu kaufen, um den ganzen Ärger loszuwerden? Sicher - es sind ein paar Hundert EUR. Die sind aber auch weg, wenn man ewig rummacht und Support hat man bei TI dann vermutlich auch. Alternativ gäbe es ja noch Crossworks Rowley. Macht MSPGCC wirklich froh, wenn man die ganzen Umstände berücksichtigt? Was meinst Du?
Jo, also den CCE werden wir wohl auch kaufen demnächst. Kann zwar keine 64 Bit Variablen, und ist nicht so flexibel, wie der GCC aber wesentlich stabilder und effektiver beim Arbeiten. Vom Preis/Leistungsverhältnis dürfte das der beste sein.
Moin, ist es wirklich so schlimm? Ich werde demnächst auch etwas größere Sachen mit dem MSP machen und wollte hierzu den von mir sehr geschätzten GCC in Eclipse nehmen. Als Debugger das USB-Teil von TI. Mal gesetzt den Fall, dass man eine saubere bzw. stabile hardwaremäßige Verbindung vom Debugger zum MSP bekommt - wo ganau liegen die Schwächen der Toolchain? Ich dachte, dass GDB, Eclipse & Co. gut miteinander können...
Naja. Stabil ist es schon, zumindest mit der aktuellen Windows-Release vom 19.6.2008. Der Kompiler ist super, keine Frage. Aber das Debuggen ist halt nicht besonders komfortabel: Der gdbproxy muss immer manuell gestartet werden, und quasi im Hintergrund laufen. Klar, kann man in Eclipse einbinden, ist aber trotzdem unpraktikabel. Es gibt keinen Reset, man muss immer komplett das Debuggen beenden und neu starten, dann halt immer mit flash schreiben. Die Projekterstellung und besonders die Erstellung einer Debug-Konfig ist alles andere als komfortabel. Es gibt keine so schöne Register-Ansicht, wie im CCE. Die Step-Over Funktion funktioniert nicht. Variablen zur Laufzeit manuell ändern klappt nur manchmal. Es gibt keine Watchpoints. Funktionen im RAM (naja, kommt höchst selten vor) lassen sich nur in ASM Debuggen. Aber prinzipiell ist es nicht ganz schlecht. Ist halt kostenlos, und wird kaum gepflegt. Ein schönes Eclipse-Plugin könnte da viel helfen, aber ich hab leider auch keinerlei Java-Ahnung und wie man Eclipse PlugIns programmiert, weiß ich auch nicht. Achja, die neuen MSP430F5xx werden nicht unterstützt. Debugger klappen eigentlich alle, ich arbeite zu Hause mit dem olimex USB unter Vista 32, auf Arbeit mit dem TI USB unter XP. Klappen beide. Der Olimex ist sogar viel viel schneller als der TI-FET.
Ließt sich ja nicht so schön. Die Geschichte mit dme Proxy kann man nicht etwa umgehen indem man viele der vielen Einstellmöglichkeiten unter Eclipse nutzt (sowas wie "Run/Debug Settings" oder "Auto-Launch")? Habe mich noch nicht mit beschäftigt, daher die Frage.
Wenn ich mich mit Eclipse wirklich auskennen würde wäre manches einfacher. Dann würde ich vielleicht selbst ein Plugin schreiben. Eclipse ist nett anzusehen - und es ist/wird eine Art Standard. Nur leider ist die Unterstützung der einzelnen CPU`s und der Einrichtung eines Projekts aus meiner Sicht stark suboptimal. Mit der Anleitung in der Hand saß ich da lange bis mal was lief. Wenn ich dann eine neue Version erstellen wollte ging der Zirkus wieder von vorne los - ätzend. Vielleicht liegt es an meinem begrenzten Verständnis der Eclipse-Umgebung. Ein Hersteller wie TI kann da etwas verbessern und ein vernünftiges Plugin schreiben, so wie bei der CCE. Man kann allerdings nicht erwarten, daß der MSPGCC dann davon unterstützt wird, wenn TI sich keinen Nutzen davon verspricht. Vieles wäre anders, wenn die Kunden massiv danach fragen würden. Dann ginge da sicher etwas. Der Kunde will und muss produktiv arbeiten. Also muss TI eine solche Umgebung bereitstellen. TI wird sicher auch die neuen CPU`s rasch unterstützen, weil das ja im eigenen Interesse liegt. TI will natürlich dann Geld für den Compiler, wenn man größere Dinge tun möchte.
Moin Leute, ich hatte heute das Vergnügen die Toolchain für den MSP zu testen. Leider hat's nicht funktioniert (irgendwie habe ich es geahnt ;^) ). Also habe ich einen Schritt zurück gemacht und die Kommandozeile bemüht. Bisher hatte ich noch nicht viel Zeit zu fummeln, aber wie es aussieht bekommt der Proxy keine Verbindung zum MSP (Windoze, mspgcc-20081230, TI USB FET). Ich muss dazusagen, dass ich Spy-Bi-Wire benutze, der Proxy scheint es ja auch zu unterstützen. Oder irre ich mich? msp430-gdbproxy --debug msp430 --spy-bi-wire "error: Could not find device" ist die Quittung. Mit der original TI-IDE klappts testweise, einen Hardwarefehler schließe ich also aus. BTW: Weiss jemand, ob der Elprotronic FlashPro mit den Tools funktioniert? Cheers TH
So: msp430-gdbproxy --port=3333 msp430 --spy-bi-wire TIUSB
Hallo! So funktioniert der neue MSPGCC wunderbar mit Eclipse. benötigt kein Cygwin mehr, die neueste Version des MSP430-gdb ist für MinGW kompiliert. GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. This GDB was configured as "--host=i686-pc-mingw32 --target=msp430". Ausführliche Beschreibung: http://matthias-hartmann.blogspot.com/2009/02/use-... Gruss Matthias
Der link im letzten beitrag wurde kepappt, daher hier in 2 Teilen Teil 1 : http://matthias-hartmann.blogspot.com Teil 2 : /2009/02/use-eclipse-and-mspgcc-easy-way.html
Hallo Matthias, mit Deiner Anleitung hat es auf Anhieb funktioniert. Vielen Dank für die Mühe, die Du Dir gemacht hast, um sie uns zu ersparen! Schade, daß das Debuggen etwas langsam ist (mit OLIMEX- und TI-USB) und vor allem, daß "Step Over" und "Step Return" nicht funktioniert. So muß man halt etwas mehr mit einzelnen Breakpoints und "Resume" arbeiten. Darüber hinaus bin ich aber froh, diese GNU-Lösung zu haben. Viele Grüße! Gerrit Buhe
Hallo Gerrit, schön von Erfolgen zu hören. Kannst Du sagen mit welcher CPU Du gearbeitet hast? Matthias
Hallo Matthias, oje, entschuldige bitte, daß ich Deine Frage erst jetzt realisiere! Falls es noch interessant ist, die CPUs, mit denen ich gearbeitet habe: MSP430x1232, MSP430x2012, MSP430x1611. Viele Grüße und entschuldige bitte meine Nachlässigkeit! Gerrit
Danke Gerrit. Mittlerweile gibt es von TI ja auch eine neuere CCE-Umgebung. Dummerweise fehlt mir momentan die Zeit mich mit diesen Dingen näher zu beschäftigen, so interessant das auch wäre. Matthias
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.