Wie am Ende jeden Quartales gibt es einen neuen Build der Arm Toolchain auf https://launchpad.net/gcc-arm-embedded. Binaries fuer verschiedene Systeme sind verfuegbar.
Danke für den Tip! Nur leider liegt es entweder an meiner Unfähigkeit oder dass da wieder irgendwie was anders ist als vorher. ZIP runtergeladen, stur über Emblocks GCC Verz drüberkopiert. => -mthumb kannte er nicht mehr bzw muss ausdrücklich definiert werden, auch wenn -march=cortex-m4 gesetzt wurde. => New Lib Nano Branch läuft nicht mehr mit sprintf zusammen _sbrk fehlte => _init fehlte auch irgendwo Erst das Verlinken der fetten StdLib brachte wieder ein Kompilierergebnis. => Alte Version zurück. Sicher ist sicher.
Hallo, ich habe nur festgestellt, dass man ein funktionierendes Dev System nicht einfach mit neuer Software "überbraten" soll in der Hoffung, das alles dann genauso ist wie vorher. Keines der Projekte war nämlich mehr kompilierbar ohne chirugische Eingriffe vorzunehmen, wie das Setzen von CFLAGS wie -mthumb (trotz -march=cortex-m4), die vorher nicht gesetzt werden mussten, eine Lib, die vorher lief aber nachher Fehler prodizierte, dass _sbrk und _init fehlen würden und damit syscalls.c nach installiert werden musste. Jedenfalls habe ich es mit meinem "Game Of Life" als Benchmark getestet und es lief deutlich langsamer mit den StdLibs als mit der Nano Branch bei Verdoppleung der Code Groesse. Also bleibe ich bei der August 2014 Version.
Irgendwas musst du definitiv falsch machen. Bei mir kompilieren verschiedene (umfangreichere) Projekte komplett problemlos mit der neuen Version. Und mit den Updates davor gab es auch keine Probleme. Einfach die neuere Version "rüberbraten" könnte ein Problem sein, da kann alles mögliche passieren. Ich verwende das Ubuntu-PPA und bekam das Update damit ganz automatisch.
drama schrieb: > Irgendwas musst du definitiv falsch machen. Bei mir kompilieren > verschiedene (umfangreichere) Projekte komplett problemlos mit der neuen > Version. Und mit den Updates davor gab es auch keine Probleme. > > Einfach die neuere Version "rüberbraten" könnte ein Problem sein, da > kann alles mögliche passieren. Und was sonst? Wenn ich das verzeichnis ganz lösche und es neu einspiele kriege ich noch viel mehr Fehlermeldungen. EmBlocks hat da einiges angepasst, vermutlich irgendwelche Konfigurationsdateien. Daher habe ich drüberkopiert. Und dann kommen Fehlermeldungen was die Libs angeht. _sbrk und _init sind beides Funktione aus syscalls.c. Die Meldungen verschwiden wenn ich ich stdlib.h nicht verwende aber das kann es ja nicht sein. Da ich in einer anderen IDE (Rowley Crossworks) noch mit einem 2008er GCC (7 Jahre alt) arbeite, der absolut lauffähigen Code erzeugt glaube ich nicht, dass das wichtig ist, ob der 1 oder 2 Jahre alt ist. Ich habe gestern den GCC aus Ubuntu installiert aber da war noch der alte 4.9.2 von 2014 drin.
Lesen bildet, das haben sie geändert. Und da verfluche ich mal wieder "fertige IDE", die einem nicht zeigen welche Optionen sie aus dem Klickfeld erzeugen. Trägt man es händisch ein und setzt neue Pfade klappt es auch. ------- This toolchain is released with two prebuilt C libraries based on newlib: one is the standard newlib and the other is newlib-nano for code size. To distinguish them, we rename the size optimized libraries as: libc.a --> libc_nano.a libg.a --> libg_nano.a To use newlib-nano, users should provide additional gcc link time option: --specs=nano.specs Nano.specs also handles two additional gcc libraries: libstdc++_s.a and libsupc++_s.a, which are optimized for code size. For example: $ arm-none-eabi-gcc src.c --specs=nano.specs $(OTHER_OPTIONS) This option can also work together with other specs options like --specs=rdimon.specs Please note that --specs=nano.specs is a linker option. Be sure to include it in linker options if compiling and linking separately. ** additional newlib-nano libraries usage Newlib-nano is different from newlib in addition to the libraries' name. Formatted input/output of floating-point number are implemented as weak symbol. If you want to use %f, you have to pull in the symbol by explicitly specifying "-u" command option. -u _scanf_float -u _printf_float
Christian J. schrieb: > Lesen bildet, das haben sie geändert. Noch nicht einmal das wurde geändert, denn genau das steht auch im readme.txt der alten Version! In der aktuellen sowie der alten Version ist/war es nötig, -mcpu=cortex-m4 zu übergeben, und eine syscalls.c mit _sbrk etc. zu definieren, um (s)printf zu verwenden. Wenn man also die alte Version direkt durch die neue ersetzt ohne den Compiler anders zuverwenden (d.h. plötzlich die syscalls.c oder -mcpu=cortex-m4 wegzulassen) funktionieren alle Projekte noch. Wenn da eine bestimmte IDE irgendwas komisches anstellt, können die GCC-Entwickler da nichts für. Das ist dann der Vorteil von IDE's wie eclipse, die den GCC nicht mitliefern und man den seperat herunterladen und den Pfad angeben muss (Hilfe, der Aufwand) - es ist kein Problem, einfach eine neue Version herunterzuladen und die zu verwenden. Die Compilerflags musste man vorher wie nachher sowieso angeben. Ich hatte keinerlei Probleme durch das Update mit meinen eclipse-Projekten...
Dr. Sommer schrieb: > Ich hatte keinerlei Probleme durch > das Update mit meinen eclipse-Projekten... Bei mir aber nicht. Und zwar weil EmBlocks da irgendein Ini File mit drin ablegt oder die was manuell angepasst haben, d.h. wenn man den ganzen Baum löscht und neu einspielt geht es nicht mehr. Und spielt man es einfach drüber geht es auch nicht. Ich habe keine syscalls.c derzeit, kann alle Libs einbinden. Also wurde das woh händisch irgendwo eingetragen. -mcpu=cortex-m4 reicht nicht mehr, bei mir muss auch noch -mthumb (march=armv7m-e auch), sonst meckert er dass er nicht weiss was er erzeugen soll. Ich schreibe das ja nicht, weil es nicht so wäre. Da allerdings nicht der geringste Unterschied bemerkbar ist hinsichtlich Codegröße oder "irgendwas" anderes bleibt alles so. Na egal, wayne interessierts....
Christian J. schrieb: > Ich schreibe das ja nicht, weil es nicht so wäre. Ist ja nicht so dass ich dir nicht glaube. Aber an diesem Problem sind dann die EmBlocks-Entwickler schuld, und nicht die GCC-ARM-Embedded-Entwickler. Christian J. schrieb: > -mcpu=cortex-m4 > > reicht nicht mehr Das hat es vorher auch nicht. Das hat nur EmBlocks das automatisch angegeben. Siehe hier das alte readme.txt: https://launchpadlibrarian.net/192227680/readme.txt Auch da steht in der Tabelle überall -mthumb, und die zur Verwendung von (s)printf nötigen Schritte. Hier kannst du die Änderungen der Version ansehen: https://launchpadlibrarian.net/192227680/readme.txt u.a. diverse Bugfixes.
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.