|
Anzeige
|
STM32 EntwicklungsumgebungHallo zusammen, Aufgrund längerer Abstinenz zu jeglichem Mikrocontroller gebastel bin ich leider ein wenig eingerostet ;-) Könnte mir evtl. jemand kurz auf die Sprünge helfen, was ich Einstellen oder per environment variable konfigurieren sollte, damit der Linker die libs und startup-files findet? Mein Compile-output zeigt derzeit:
Ich vermute, dass irgendwas am library path nicht stimmt. Vielen Dank, Patrick Das sollte nicht passieren. Welche Compiler-Distribution ist installiert? Bei GCC-ARM-Embedded ist das alles vorkonfiguriert und funktioniert: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm Die bei Linux-Distributionen mitgelieferten GCC-Pakete sind leider oft veraltet und/oder unvollständig. Ich nutze neuerdings openSuSE Tumbleweed (wegen der rolling releases und einem sehr aktuellen gnuradio, im Vergleich zu anderen Distributionen). Die aktuelle Toolchain heisst da "cross-arm-none-*", siehe:
Es ist also nicht empfehlenswert, diese zu nutzen? Gibt es "best practices" um ein brauchbares build-system zu bekommen? Patrick D. schrieb: > Es ist also nicht empfehlenswert, diese zu nutzen? Bei Suse weiß ich das nicht. Bei Ubuntu/Debian ist/war das jedenfalls problematisch. Patrick D. schrieb: > Gibt es "best practices" um ein brauchbares build-system zu bekommen? https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads Rechts auf Download klicken, Datei entpacken, "PATH" Variable anpassen, fertig. Ist dann auch konsistent zu dem was die meisten hier verwenden und was diverse IDEs mitliefern. Prima, danke, ich hätte einfach mal den Download-Links folgen sollen... Patrick D. schrieb: > Ich nutze neuerdings openSuSE Tumbleweed (wegen der rolling releases und > einem sehr aktuellen gnuradio, im Vergleich zu anderen Distributionen). Du hast gcc7 und gcc8 parallel installiert. An sich sollte das funktionieren, aber gelegentlich kommt da was durcheinander, so vielleicht auch bei Dir. Deinstalliere mal alle cross-arm-none-* Pakete und installiere dann nur cross-arm-none-gcc8 cross-arm-none-newlib-devel und deren Abhängigkeiten. Damit konnte ich gerade Black Magic Probe und OpenDPS problemlos compilieren. Falls Dir das auch nicht hilft, nimm mal statt der Tumbleweed-Pakete die Pakete für Leap 15 aus diesem Repository: https://download.opensuse.org/repositories/home:/duwe:/crosstools2/openSUSE_Leap_15.0/ cross-arm-none-eabi-gcc cross-arm-none-eabi-newlib cross-arm-none-eabi-binutils Ich habe jetzt die Toolchain installiert, die Niklas empfohlen hat. Einfacher geht es fast nicht. Dennoch: vielen Dank für die Tipps! Niklas G. schrieb: > Bei GCC-ARM-Embedded ist das alles vorkonfiguriert und > funktioniert: > > https://developer.arm.com/open-source/gnu-toolchain/gnu-rm und auch das noch: > Ist dann auch konsistent zu dem was die meisten hier verwenden > und was diverse IDEs mitliefern. und: Patrick D. schrieb: > Ich habe jetzt die Toolchain installiert, die Niklas empfohlen hat. > Einfacher geht es fast nicht. und direkt von der Quelle, ein Traum, das wäre ja perfekt für jeden... Aber hast du evt. auch einen Tipp, wo man ein ähnliches Paket für 32-Bit Linux bekommt? > Die bei Linux-Distributionen mitgelieferten GCC-Pakete sind leider oft > veraltet und/oder unvollständig. Bei Debian kann ich "veraltet" unterschreiben. Aber unvollständig nun wirklich nicht. Ich hab's installiert wie jedes andere Debian-Paket und alles funktioniert sofort, ohne jede Handarbeit. Für 32bit gibt es den 5er bei ARM. Ggf. kannst ja das bleeding edge script[1] nutzen. [1] https://github.com/FreddieChopin/bleeding-edge-toolchain
Gast
#5728780
Bauform B. schrieb: > Aber hast du evt. auch einen Tipp, wo man ein ähnliches Paket für 32-Bit > Linux bekommt? Wer benutzt denn noch 32bit Rechner... Man kann das Source Paket herunter laden und selbst kompilieren. Damit kann man sich unter Linux sehr einfach jede gewünschte GCC-Toolchain bauen: https://crosstool-ng.github.io/ Nico W. schrieb: > Für 32bit gibt es den 5er bei ARM. Naja, seit dem hat sich doch einiges getan... > Ggf. kannst ja das bleeding edge script[1] nutzen. > > [1] https://github.com/FreddieChopin/bleeding-edge-toolchain Das benutze ich, z.Zt. mit gcc-7.1. Es funktioniert, bis auf Kleinigkeiten. Zum Beispiel müssen Programme für den Cortex-M0 ohne Divisionen auskommen (undefined reference to `__aeabi_idiv' u.ä.). Und ich wage es nicht (mehr), lto einzuschalten. Sowas passiert mit dem fertigen Paket wahrscheinlich nicht. Harry L. schrieb: > Damit kann man sich unter Linux sehr einfach jede gewünschte > GCC-Toolchain bauen: > > https://crosstool-ng.github.io/ Das scheint mir das gleiche zu sein, nur hübscher verpackt. Ob ich damit besser klar komme? Jedenfalls danke für die Tipps. Niklas Gürtler schrieb: > Wer benutzt denn noch 32bit Rechner... Jemand, der Angst vor neuen, heimtückischen Fehlern hat - die sich ganz einfach komplett vermeiden lassen. Man kann eben nicht alles auf einmal haben. Das neue gcc-Paket ist doch der einzige Vorteil von 64 Bit. > Man kann das Source Paket herunter laden und selbst kompilieren. siehe oben
Gast
#5729356
Bauform B. schrieb: > Jemand, der Angst vor neuen, heimtückischen Fehlern hat - die sich ganz > einfach komplett vermeiden lassen. AMD64 ist etabliert genug dass man keine Angst mehr vor Kinderkrankheiten haben muss... Oder was für heimtückische Fehler meinst du? Für komplexe Projekte ist sogar ein 64bit GCC erforderlich weil die 32bit-Version nicht genug Speicher nutzen kann. Bauform B. schrieb: > Harry L. schrieb: >> Damit kann man sich unter Linux sehr einfach jede gewünschte >> GCC-Toolchain bauen: >> >> https://crosstool-ng.github.io/ > > Das scheint mir das gleiche zu sein, nur hübscher verpackt. Ob ich damit > besser klar komme? > Jedenfalls danke für die Tipps. Ich kann dir wirklich nur dazu raten, das zu verwenden, wenn du deine Toolchain aus den Sourcen selbst bauen willst. Es ist ja nicht damit getan, den GCC zu bauen - das ist ja auch nur ein Teil. Da kommen noch einige andere Pakete dazu, und Crosstool kümmert sich wirklich um Alles inkl. dem Download der erforderlichen Sourcen. Ich bin schon lange Linuxer, aber würde es dieses Script nicht geben, hätte ich mir sowas selbst bauen müssen. ;) Starte das Script mit den passenden Parametern, geh in die Mittagspause, und wenn du zurück kommst, ist deine Toolchain fertig. Also, Debian ist klarer Testsieger. Seit einer Woche gibt es den arm-none-eabi-gcc-7.3 in Debian-testing. Das Paket basiert auf der Vorgängerversion der 8.x von arm.com, ist also praktisch "original" und noch aktueller kann man nicht verlangen ;) + fertige Pakete für 10 Architekturen, z.B. i386, armhf = RPi bis s390 + extrem einfache Installation wie alles von Debian + funktioniert stand-alone (newlib, gdb müssen nicht installiert sein) - nicht aktuell https://aur.archlinux.org/packages/gcc-arm-none-eabi-bin/ + aktuell - nur für x86_64 https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads + Das Original + fertige Pakete für Mac OSX und Windows-32-Bit + aktueller geht's nicht - ein großes Paket ohne Auswahlmöglichkeit - kein Paket für 32-Bit-Linux als Source: + anscheinend extrem einfach zu bedienen, falls man viel Zeit hat - lässt sich nicht (so einfach) ohne newlib oder gdb bauen - braucht viele spezielle Pakete auf dem host https://github.com/FreddieChopin/bleeding-edge-toolchain + hat funktioniert o das Script lies sich einfach auf "ohne newlib" umbauen - dafür funktioniert beim Cortex-M0 keine Division - keine Ahnung, wie original der gebaute gcc werden könnte https://crosstool-ng.github.io/ + das Schweizer Messer für Toolchain-Bastler + baut gcc für über zwei Dutzend Targets + benutzt menuconfig von kernel.org + ist frei konfigurierbar - muss genau konfiguriert werden, auch wenn man ein sample benutzt - ist nicht dafür gedacht, das Original von arm nach zu bauen - die Lizenz ist etwas komplizierter - hat sich nach wenigen Schritten selbst gelöscht Niklas Gürtler schrieb: > AMD64 ist etabliert genug dass man keine Angst mehr vor > Kinderkrankheiten haben muss... Oder was für heimtückische Fehler meinst > du? Fehler in eigenen Programmen, die aus einer Zeit stammen, als es noch keine 64 Bit gab und die man bis jetzt nur einmal anfassen musste, als errno.h eingeführt wurde. Bauform B. schrieb: > Fehler in eigenen Programmen, die aus einer Zeit stammen, als es noch > keine 64 Bit gab und die man bis jetzt nur einmal anfassen musste, als > errno.h eingeführt wurde. Dann kompiliert man seine eigenen Programme halt als 32bit. STM32-Programme sind wenig überraschend auch immer nur 32bit. Dann kann man trotzdem einen GCC nutzen der selbst AMD64 ist... Korrekt geschriebenen C(++)-Programmen ist es komplett egal ob man jetzt für 8, 16, 32 oder 64bit kompiliert. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
