Hallo liebes Forum, ich versuche momentan die gnu scientifc library (gsl) in einem embedded projekt zu benutzen. Hintergrund: möchte simples curve fitting auf einem nrf52 SoC durchführen , arbeite dabei mit Segger Embedded Studio und habe die gsl schon in manchen applikationen vorher benutzt. als erstes habe ich gemerkt dass ich die gsl mal für arm cross compilen muss, das habe ich mit ein paar hürden geschafft, jetzt habe ich also ein libgsl.a und ein libgslcblas.a file die ich in mein projekt importieren kann um sie dann zu linken. jetzt bekomme ich aber einen fehler von SES -> undefined reference to `_impure_ptr' wahrscheinlich ein fehler weil ich im projekt nicht newlib verwende. Das habe ich auch noch nie gemacht, deshalb stocke ich hier schon weil ich nicht genau weiss was der beste Weg ist newlib in ein SES projekt zu importieren. Ich weiss wo ein nano-newlib h file liegt (im gcc compiler pfad) aber mehr auch nicht. Hat hier jemand damit erfahrung und einen hinweis was ich am besten machen soll? ich weiss dass man normalerweise mit --specs=nano.specs den compiler anweist dnewlib zu verwenden aber da gibt es keinen input pfad in SES und es kann auch sein dass die dann vielleicht mit float-abi=soft läuft während ich aber hard brauche LG und danke im Voraus, J
Die LibC Header, die beim conifgure / build von GSL verwendet werden, sollten diejenigen sein, die auch später in der Appliktion verwendet werden. Zu versuchen, unterschiedliche LibC-Implementierungen gleichzeitig zu verwenden, ist offensichtlich keine gute Idee... Selbst wenn die Applikation buildet ist nicht ausgeschlossen, dass sie beim Laufen crasht.
okay das verstehe ich, ich hab es leider nicht hinbekommen gsl zu cross-compilen ohne --specs=nano.specs zu verwenden und somit müsste ich ja jetzt nano auch in meinem projekt verwenden, aber das funktioniert nicht so wirklich aus den genannten Gründen
Die erste Anlaufstelle wäre ja die Mailing-Liste in https://www.gnu.org/software/gsl/#mailinglists Wenn du nen Klotz wie GSL verwendest, dann tut wahrscheinlich auch eine vanilla Newlib nicht weh? Also warum willst du überhaupt nano verwenden? Und dann mal schauen ob man aus config.sub schlau wird, was da an $os geboten wird. linux-newlib vermutlich nicht :-) Also wird configured für arm-unknown-none oder so? Und der verwendete GCC verwendet Newlib oder nur per Hacks wie -specs= ?
also ich benutze aus der GSL ja nur ganz wenige funktionen und ich habe leider keine alternative gefunden mit der ich levenberg marquardt algorithmen in C effizient laufen lassen kann. Ja gsl mailing liste habe ich auch schon probiert, sie haben mir eh bei der kompilierung für ARM M4 sehr geholfen Ich muss nicht unbedingt nano verwenden, für mich wäre es ok wenn einfach alles zusammenpasst und dann kann es irgendwas sein. ich habe in meiner config mit '--specs=nano.specs' und '--specs=nosys.specs' probiert, nosys hilft aber leider auch nicht. ja es wird konfiguriert für arm-none-eabi, das ist meine configuration: ./configure CC=/usr/local/gcc/bin/arm-none-eabi-gcc CXX=/usr/local/gcc/bin/arm-none-eabi-gcc LD=/usr/local/gcc/bin/arm-none-eabi-gcc AR=/usr/local/gcc/bin/arm-none-eabi-ar OBJCOPY=/usr/local/gcc/bin/arm-none-eabi-objcopy RANLIB=/usr/local/gcc/bin/arm-none-eabi-ranlib CFLAGS="-mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard" CXXFLAGS="-mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard" LDFLAGS="--specs=nosys.specs -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard" LIBRARY_PATH="/usr/local/Cellar/gsl/2.7.1/lib" C_INCLUDE_PATH="/Users/algorithm/lib/gsl-2.7.1/gsl" --target=arm-none-eabi --host=arm-none-eabi
Julius D. schrieb: > also ich benutze aus der GSL ja nur ganz wenige funktionen Nur den dafür benötigten Sourcecode aus de Lib zu extrahieren ist keine Lösung? Oliver
an sich ein guter input, ich habe es auch probiert, die gsl ist aber sehr komplex und ich fahre in so viele fehler rein. Vielleicht probiere ich das nochmal, bisher ist das aber eher eine nachgestellte Lösung.
Julius D. schrieb: > ./configure CC=... > CXX=... > LD=... > AR=... > OBJCOPY=... > RANLIB=... Das sollte doch alles automatisch gefunden werden per --host=arm-none-eabi ? D.h. arm-none-eabi-gcc verwendet nicht die Newlib? Da würd ich mich ersma darum kümmern, dass die Toolchain ne gescheite LibC hat, die ohne Hacks funktioniert. Also Newlib als In-Tree target Lib des arm-gcc, evtl auch die Libgloss.
leider nein, ich habe es ohne die Flags probiert, dann wird z.B. die native ranlib meiner build machine genutzt und wirft fehler. okay also in SES wird ja emRun benutzt soweit ich weiß, muss ich zwangsweise die gleiche libc benutzen für die toolchain?
Julius D. schrieb: > leider nein, ich habe es ohne die Flags probiert, dann wird z.B. die > native ranlib meiner build machine genutzt und wirft fehler. Das sieht dann aber wie ein Bug im confifure.ac der GSL aus. Aber egal, wenn der Workaround geht. > okay also in SES wird ja emRun benutzt soweit ich weiß, muss ich > zwangsweise die gleiche libc benutzen für die toolchain? Keine Ahnung was SES ist. Wenn man sich die GCC Toolchain generiert, dann kann man die Newlib in-Tree mitgenerieren lassen, so wie z.B. andere Target-Libs auch automatisch mitgeneriert werden (libgcc, libatomic, ...). Dazu linkt man Newlib/newlib als "newlib" ins Top-Level Source-Verzeichnis des GCC, dito für Newlib/libgloss wenn man auch die Libgloss will. Dann configure trallala und man hat eine Toolchain mit Newlib.
Julius D. schrieb: > ich habe leider keine alternative gefunden mit der ich levenberg > marquardt algorithmen in C effizient laufen lassen kann. Wo hast Du denn schon geschaut? "Numerical Recipes in C" und "A Numerical Library in C for Scientists and Engineers" von Lau haben Implementationen von Levenberg-Marquardt. gnuplot verwendet Marquardt-Levenberg zum Fitten und der code ist opensource. Evtl. kann man den extrahieren. Auf github gibt es auch einiges: https://github.com/search?q=levenberg-marquardt++language%3AC&type=repositories&l=C z.B. https://users.ics.forth.gr/~lourakis/levmar/
:
Bearbeitet durch User
Johann L. schrieb: > Keine Ahnung was SES ist. Julius D. schrieb: > arbeite dabei mit Segger Embedded Studio
hey, um das noch kurz 'aufzulösen' ich habe am ende den src code der gsl ein bisschen modifiziert (die stellen an denen _impure_ptr vorkommt, waren nur 4 recht irrelevante funktionen) und nochmal von neuem cross kompiliert. Dadurch lässt sich die funktionalität anwenden. Ich laufe gerade schon in die nächsten 'probleme': 1. man sollte möglichst alle funktionen aus den verwendeten c files, die man NICHT verwendet löschen, da ja .o files komplett verlinkt werden kann das zumindest ein bisschen memory sparen 2. auf dem nrf muss man schon einiges an tweaks veranstalten um mit hoher frequenz rechnen zu können ich brauche grad keine Hilfe mehr damit aber wollte das nur anmerken falls in Zukunft jemand auf die Idee kommt sowas zu machen und auf diesen Faden stößt.
Julius D. schrieb: > da ja .o files komplett verlinkt werden > kann das zumindest ein bisschen memory sparen Kommt auf den verwendeten Linker an. Wenn der "function level linking" kennt, ist das nicht der Fall.
da hast du recht, ist beim segger studio integrated linker nicht der fall.
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.