I would like to ask which is the optimal (or any feasible) way to compile acados for the STM NUCLEO-F767ZI MCU based on an ARM Cortex M7 processor. Before, I attempted to do this on a Cortex M4 based STM platform, which was not succesful due to missing floating-point vectorization, as suggested here . Therefore I switched to the Cortex M7 based STM mentioned above, which should not have this problem.
As a preliminary step, I managed to run acados on the Cortex A7 based Raspberry Pi2+. Now, I would like to move on to the truly embedded (no OS) Cortex M7 based STM NUCLEO-F767ZI MCU. The executable will be compiled on a standard x64-based PC. Therefore I would love to know what needs to be compiled (blasfeo, HPIPM, …) for the ARM architecture such that it will be possible to run acados on the target MCU.
I would appreciate your help. Thank you very much in advance.
I was trying to compile acados (and HPIPM+BLASFEO) for another Cortex M7, namely the platform Teensy 4.0, you can have a look here: https://github.com/tmmsartor/acados_teensy_template.
I was using the template (also this more official version is available now) already available for this board and modifying the Makefile of acados accordingly.
I was able to compile but I was still getting some runtime errors that need to be fixed.
Maybe a similar approach can work also for the NUCLEO board, I don’t have much experience with STM boards.
And the end acados software stack when using the GENERIC target is plain self-contained C code,
how to cross-compile it depend more on your platform than on the code of acados itself.
Did you already managed to cross-compile and run simpler C code on your NUCLEO board?
Thank you for your fast reply @tmmsartor.
I will start by cross-compiling and attempting to run a simpler C code on the NUCLEO board, as you suggested, and will let you know. I assume you meant some code not related to acados.
Btw, have you eventually suceeded to run acados on the Teensy board that you mentioned?
So I tried to compile acados for the STM Nucleo board. I copied the acados, acados_c and blasfeo folders to my project. When attempting to compile it, the compiler reported the a blasfeo related error, please see:
This specific issue is caused by the fact that BLASFEO code expect the macro LA to be defined by the compiler, you should be able to solve adding -DLA=HIGH_PERFORMANCE to your set of flags.
In general think is better to use the Makefile provided by acados which is defining the proper macro the codebase expect (default values are not handled in a nice way yet).
My approach was to include acados Makefile at the beginning of your platform specific Makefile
in order to override the relevant variables like a different compiler (CC variable in the Makefile) or similar tools and eventual platform specific flags.
I found thisMakefile for stm32, but I never tested it, maybe is a good template for you.
Please keep us update if you have other issues or if you manage to compile for stm32
NB: I will update this thread as soon I have some progress on the teensy4.0 but at the moment I busy on other tasks.
I set the compiler’s flag -DLA=HIGH_PERFORMACE which solved the previous problem. However, another issue arised that I have not been able to deal with so far; please see:
I also inspected the MakeFile that you sent. I do the programming in Atolic TrueStudio which does not use MakeFile. Do you think that it would be more suitable to compile it using MakeFile in Linux?
I don’t fully understand the reason for the error you posted yet.
One problem is that it seems that your are trying to compile the HASWELL TARGET,
(from the avx2 kernels folder)
which means use high-end intel CPU instructions that are not supported in your board,
you should use GENERIC on that board, with the flag -DTARGET=GENERIC
There is maybe another issue because it seems to complain about every assembly instructions,
maybe is because of different assembly syntax expected by Atolic (see GAS versus NASM)
I am not familiar with Atolic TrueStudio do you know if it supports CMake build system?
In TrueStudio I set the flag -DTARGET=GENERIC; Something changed, but it still throws an error. I have not found out how to use cmake in Atolic TrueStudio, and decided to rather compile it using Makefile. I have succeeded to compile libacados.so, libhpipm.so and libblasfeo.so with the arm-none-eabi-gcc compiler. However, I have a problem with libqpoases_e.so, which when trying to get compiled with arm-none-eabi-gcc leads to the following output:
Unfortunately, I dont know, why you get all these undefined references.
Maybe some include is missing.
Do you want to use qpOASES as your QP solver?
Because acados doesnt have it as a dependency, so you could just use acados without qpOASES and with HPIPM as a QP solver instead.
Interestingly, when I use the gcc compiler, there are no errors. I have not changed anything in the source codes, so it must be some include that arm-none-eabi-gcc cannot process.
I need libqpoases_e.so since I would like to compile the pendulum_example which requires qpoases in its Makefile. I would appreciate a lot if you can advise how to circumvent this.
I really have no idea what the problem with qpOASES is, but hopefully the following can help you circumvent it.
I see, that you refer to the example in examples/c.
I would recommend to use the C code generated by the Python example instead.
I remember that you asked something Python related before, so I guess this will be your workflow anyway.
Generate the C code corresponding to the example on your main machine.
With something like this:
# install Python interface, see docs
cd examples/acados_python
rm c_generated_code -rf # to be sure
python minimal_example_ocp.py
cd c_generated_code
make clean
Then you can copy the folder c_generated_code, which just contains the whole example with Makefile to your board.
You will have to set the some paths to your libraries/includes in the Makefile, but if you manage to do this, you will also have a workflow to do it with your own model.
Yes, I generate the C code using the python interface. I tried the approach that you recommended, and one problem arised. When I want to compile c_generated_code files with the arm-none-eabi-gcc compiler, I get the following output:
I guess you modified the Makefile by replacing gcc with arm-none-eabi-gcc .
I think you missed one instance though, where the model files are compiled, i.e. in this line:
( cd pendulum_ode_model; gcc -fPIC -c pendulum_ode_expl_ode_fun.c pendulum_ode_expl_vde_forw.c )
Hi @xzatkalik,
I had similar problems cross compiling to a rt system. I got help here, maybe this helps you?
Target = Generic, Ext_dep = off and math = c99 wre important.
I used a toolchain file to compile withg cmake, this worked well. Maybe you could consider using this? Is there a toolchain file available for your target system?
