Guten Abend zusammen, nachdem ich auf http://gcc.gnu.org las, dass der MSP430 unterstützt wird, fand ich das ganz interessant und habe versucht, das bei mir zum laufen zu bekommen. Leider habe ich das nicht hinbekommen. Dass die ganzen Prozessorspezifischen Include-Files ja wohl nicht dabei sind, und dass ich die MSP430-binutils noch brauchte, hab ich mir schon fast gedacht. Nachdem ich über homebrew (http://brew.sh) den neusten GCC, also 4.9, geladen habe, hat wie erwartet natürlich nichts funktioniert. Alle möglichen -mmcu Varianten hatte ich ausprobiert, also mit msp430 einfach oder dem speziellen Device. Ganz genau bin ich mir aber nicht mal sicher, welche Optionen ich alle wie setzen muss. Gut, dann hab ich eben versucht, die einzige meiner Meinung schlechte Anleitung, die ich gefunden habe, (http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Install:redhat) ausprobiert, aber das bricht bei mir auch ab, weil irgendein sbrk deprecated ist (im Schritt 'Install Binutils for MSP430' beim make). Hat das vielleicht schon irgendjemand am laufen? Und was habe ich eigentlich für prinzipielle Vorteile gegenüber der Variante einfach den msp430-gcc zu installieren? Ich mein die MSP-binutils brauch ich ja auch im 4.9er GCC. Hab leider noch nicht so den genauen Durchblick. Weil wenn der einzige Vorteil ist, dass ich anstatt dem msp430-gcc dann eben in der Kommandozeile die paar Buchstaben spare, und ich quasi nur die Universalität der GNU Compiler Collection als Vorteil habe, dann mache ich mir die ganze Mühe glaube ich doch nicht. Vielen Dank schonmal für eure Antworten!
Fabio W. schrieb: > Alle möglichen -mmcu Varianten hatte ich ausprobiert, also mit msp430 > einfach oder dem speziellen Device. Ganz genau bin ich mir aber nicht > mal sicher, welche Optionen ich alle wie setzen muss. Der msp430-gcc kennt wohl viele Optionen; zur Codeerzeugung haben die aber keinen Effekt, außer ebem msp430, msp430x und msp430xv2. http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/msp430/msp430.c?revision=203520&view=markup#l112 Wobei "msp430" nur in der Doku auftaucht, nicht aber in der Compilerquelle.
Hmm, und wie soll das dann funktionieren, die richtige Include-Datei zu finden? Denn angeblich ist alles was nicht "#include <msp430.h>" heißt doch deprecated, also alles was denn speziellen Device-Namen angeht. Oder läuft das im GCC anders als beim msp430-gcc. Ich gehe mal davon aus, dass auch ersterer gemeint war am Anfang der Antwort, und nicht tatsächlich der msp430-gcc. Irgendwie steh ich jetzt aber noch mehr auf dem Schlauch, was denn nun der Unterschied zwischen dem msp430-gcc und dem MSP430-Support im GCC ist? Kann mir da mal jemand helfen?
Letztendlich war der Grund dafür, dass ich es mit GCC 4.9 ausprobieren wollte, dass ich mir dachte, dass es ja sinnvoll und platzsparend sowie eleganter aufzurufen ist, wenn ich ein Kommadozeilenprogramm aufrufe, egal ob ich jetzt für meinen Mac kompilieren möchte oder Cross-Platform für einen MSP430. Auf die Idee bin ich auch nur gekommen, weil ich etwas davon las, dass die GNU Compiler Collection in Version 4.9 wohl von sich aus MSP430-Support mitbrächte. Aus benannten Gründen wollte ich das eben ausprobieren, ob ich das hinbekomme, auch um wieder etwas mehr Kommandozeilen-Erfahrunz zu erlangen. Allerdings ist mir nicht ganz klar, was jetzt dieser ominöse MSP430-Support genau bedeutet. Ich habe bisher die Vermutung, dass es nur eine Schnitstelle in der Compiler Collection neu gibt, die es ermöglicht, auch für die genannte Prozessorfamilie zu kompilieren. Deswegen gehe ich davon aus, dass die ganzen Assembler und Linker-Geschichten (also das Back-end ?) noch nicht dabei ist. Deswegen wird in dem Link auch der binutils-Kram extra geladen. Ist das soweit richtig? Und dann sind da natürlich noch beispielsweise die Include-Files, die ja wahrscheinlich auch nicht mit jeder GCC-Installation mitkommen? Letztendlich kann ich mir natürlich auch alles wieder so installieren, wie ich es vorher hatte, sodass ich eben dann in der Kommandozeile den msp430-gcc aufgerufen habe. Aber das wär ja auch eigentlich langweilig, wenn alles funktioniert. Dann hab ich ja nichts neues gelernt.
Fabio W. schrieb: > Letztendlich war der Grund dafür, dass ich es mit GCC 4.9 ausprobieren > wollte, dass ich mir dachte, dass es ja sinnvoll und platzsparend sowie > eleganter aufzurufen ist, wenn ich ein Kommadozeilenprogramm aufrufe, > egal ob ich jetzt für meinen Mac kompilieren möchte oder Cross-Platform > für einen MSP430. > Auf die Idee bin ich auch nur gekommen, weil ich etwas davon las, dass > die GNU Compiler Collection in Version 4.9 wohl von sich aus > MSP430-Support mitbrächte. Aus benannten Gründen wollte ich das eben > ausprobieren, ob ich das hinbekomme, auch um wieder etwas mehr > Kommandozeilen-Erfahrunz zu erlangen. > Allerdings ist mir nicht ganz klar, was jetzt dieser ominöse > MSP430-Support genau bedeutet. Ich habe bisher die Vermutung, dass es > nur eine Schnitstelle in der Compiler Collection neu gibt, die es > ermöglicht, auch für die genannte Prozessorfamilie zu kompilieren. Ja. Dazu muß GCC als Cross-Compiler configuriert und generiert werden, d.h. beim configure setzt du u.a. --target=msp430. Dito für die Binutils. GCC ist ein Open-Source-Projekt, es stellt keine Binärdateien, Executables oder Distributionen zur Verfügung. > Deswegen gehe ich davon aus, dass die ganzen Assembler und > Linker-Geschichten (also das Back-end ?) noch nicht dabei ist. Das ist Sache der Binutils, die du ebenfalls aus den Quellen für msp430 erzeugen mußt. Da 4.9 die aktuelle Entwicklungsversion des GCC ist, wirst du vermutlich vergeblich nach einer fertigen msp430-Toolchain suchen. > wird in dem Link auch der binutils-Kram extra geladen. > Ist das soweit richtig? foo-gcc arbeitet als Text-Text-Transformator: C-Code rein, Assembler-Code raus. Danach ruft der Compiler-Treiber die Binutils auf zum Assemblieren und Linken. > Und dann sind da natürlich noch beispielsweise die Include-Files, die ja > wahrscheinlich auch nicht mit jeder GCC-Installation mitkommen? Solche Include-Dateien gehören weder zu GCC noch zu Binutils oder der libc. IdR werden sie in eigenen Projekten zur Verfügung gestellt. Beim avr-gcc werden entsprechende Header wie avr/io.h durch das AVR-Libc-Projekt geliefert; dies geht aber über den Umfang einer reinen Linc hinaus, was man schon daran erkennt, daß avr/io.h -- oder eben msp430.h -- nicht Teil des C-Standards sind. > Letztendlich kann ich mir natürlich auch alles wieder so installieren, > wie ich es vorher hatte, sodass ich eben dann in der Kommandozeile den > msp430-gcc aufgerufen habe. Aber das wär ja auch eigentlich langweilig, > wenn alles funktioniert. Dann hab ich ja nichts neues gelernt. D.h. du hast bereits einen funktionierenden msp430-gcc? Sag doch endlich mal KLAR ob die die Toolchein generieren willst oder nur verwenden!
Johann L. schrieb: > Sag doch endlich mal KLAR ob die die Toolchein generieren willst oder > nur verwenden! Er hat sich den neuesten gcc (4.9) für seinen MAC geholt. Und weil er zum 4.9 irgendwo "supports MSP430" gelesen hat, dachte er, er könne damit sowohl Code für den MAC, als auch für den MSP430 generieren. Er dachte, er müsse für den MSP430 nur noch das "Drumherum" dazu packen, und schon hätte er Native- und Cross-Compiler in Einem.
Johann L. schrieb: > Ja. Dazu muß GCC als Cross-Compiler configuriert und generiert werden, > d.h. beim configure setzt du u.a. --target=msp430. Dito für die > Binutils. Okay, das wusste ich nicht, dass man das extra angeben muss, aber macht ja Sinn. Dann kann das ja auch nicht funktionieren.. Johann L. schrieb: > GCC ist ein Open-Source-Projekt, es stellt keine Binärdateien, > Executables oder Distributionen zur Verfügung. Auch wenn ich nicht so viel Ahnung habe, das weiß ich wohl. Johann L. schrieb: > Das ist Sache der Binutils, die du ebenfalls aus den Quellen für msp430 > erzeugen mußt. Das habe ich ja gerade oben geschrieben, dass Linker, Assembler etc in den Binutils sind. Verstehe ich dann jetzt richtig, dass ich diese mit entsprechenden Flags beim Configure direkt aus den GCC-Quellen erzeuge? Ich dachte, die muss ich extern holen. Johann L. schrieb: > Da 4.9 die aktuelle Entwicklungsversion des GCC ist, wirst du vermutlich > vergeblich nach einer fertigen msp430-Toolchain suchen. Das suche ich auch nicht, ich wollte mir die Toolchain schon selber kompilieren. Johann L. schrieb: > Solche Include-Dateien gehören weder zu GCC noch zu Binutils oder der > libc. IdR werden sie in eigenen Projekten zur Verfügung gestellt. Beim > avr-gcc werden entsprechende Header wie avr/io.h durch das > AVR-Libc-Projekt geliefert; dies geht aber über den Umfang einer reinen > Linc hinaus, was man schon daran erkennt, daß avr/io.h -- oder eben > msp430.h -- nicht Teil des C-Standards sind. Dass es beim AVR so ist, ist mir bewusst, und deswegen sagte ich ja auch, dass die wohl nicht mitkommen. Wie ist das denn beim MSP430? Sind die da auch bei einem Libc-Projekt dabei? Johann L. schrieb: > D.h. du hast bereits einen funktionierenden msp430-gcc? Hatte ich, bevor ich mein Notebook neu aufgesetzt habe. Ich könnte das auch wieder so ans Laufen bekommen, aber dann kann ich es ja nicht über 'gcc -mmcu=cc430f6137 main.c ...' aufrufen, sondern muss 'msp430-gcc' verwenden. Letztendlich ist ja auch nur das der Vorteil, den ich von dem 4.9er Support für MSP430s habe? (ich weiß, ich wiederhole mich). Denn die binutils und libs brauch ich für den MSP430 ja sowieso neu, sodass ich letztendlich auch nichts an Platz sparen werde? Johann L. schrieb: > Sag doch endlich mal KLAR ob die die Toolchein generieren willst oder > nur verwenden! Naja, ich schrob, dass ich den neusten GCC über homebrew geladen habe. Ich hab natürlich nicht bedacht, dass man das auch für vorgefertigte Kompilate halten kann. Ist aber nicht so, es wird immer alles neu kompiliert. Stefan Ernst schrieb: > Er hat sich den neuesten gcc (4.9) für seinen MAC geholt. Und weil er > zum 4.9 irgendwo "supports MSP430" gelesen hat, dachte er, er könne > damit sowohl Code für den MAC, als auch für den MSP430 generieren. Ja, so ungefähr ist es. Dass ich natürlich noch die msp430-binutils benötige, hab ich aber auch im Eingangspost schon erwähnt. Ich ging nicht davon aus, dass man mit GCC standardmäßig für alle unterstützten Plattformen crosskompilieren kann.
Stefan Ernst schrieb: > Er > dachte, er müsse für den MSP430 nur noch das "Drumherum" dazu packen, > und schon hätte er Native- und Cross-Compiler in Einem. Je nach Definition von "Drumherum" denke ich das auch immer noch, zumindest lese ich das hier raus so: http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Install:redhat Das Problem was ich hier nur habe, ist, dass im Binutils-Schritt der Error mit sbrk() deprecated kommt. Dass mein auf gut Glück Versuch mit homebrew nicht funktioniert hat mangels --target und soweiter sehe ich ja jetzt ein.
Fabio W. schrieb: > Das Problem was ich hier nur habe, ist, dass im Binutils-Schritt der > Error mit sbrk() deprecated kommt. Dann poste doch mal die genaue Kommandozeile, die zu dem Fehler (bzw. zur Warnung) führt und die exakte Fehlermeldung.
Jörg Wunsch schrieb: > Fabio W. schrieb: >> Das Problem was ich hier nur habe, ist, dass im Binutils-Schritt der >> Error mit sbrk() deprecated kommt. > > Dann poste doch mal die genaue Kommandozeile, die zu dem Fehler (bzw. > zur Warnung) führt und die exakte Fehlermeldung. Okay, ich habe mal die Ausgabe angehangen. Diese Ausgabe erscheint, wenn ich 'make' in dem Schritt 'Install Binutils for MSP430' von folgender Webseite ausführe: http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Install:redhat Ich gehe davon aus, dass wenn ich in irgendeinem Makefile rumsuche und dann -Werror abschalte, es bei einem Warning bleibt und trotzdem kompiliert wird? Kann das Problem daran liegen, dass sich hinter meinem Standard-Aufruf 'gcc' clang befindet, und es mit 'normalem' gcc funktionieren würde, weil -Werror bei clang vielleicht per default gesetzt ist?
Fabio W. schrieb: > Ich gehe davon aus, dass wenn ich in irgendeinem Makefile rumsuche und > dann -Werror abschalte, es bei einem Warning bleibt und trotzdem > kompiliert wird? Naja, das ist ein Problem deines Betriebssystems. Das autoconf versucht ja schon herauszufinden, ob es im jeweiligen System ein sbrk() gibt. Wenn es das nicht gibt, wird die entsprechende Funktionalität gar nicht eincompiliert (das wird nur zum Erzeugen der Speicher-Statistik benutzt). Dummerweise gibt es aber in deinem System die Funktionalität zwar, aber anschließend heult das System herum, dass man sie gar nicht benutzen solle ... du kannst auch nach dem configure einfach das HAVE_SBRK im generierten config.h auskommentieren, dann müsste es auch gehen.
Eigentlich sollte doch ein $ make CFLAGS="-Wno-error" reichen?
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.