HAL code in native module

[jgpeiro]

I have payed a little bit with native modules, for fast filtering functions, matrix multiplications...all C code.
But now I want to configure a STM32 peripherial and I have some issues cause I cant link with the STM32 HAL.

It is possible? I can call to if if I have my image available during compile time? I need to include all HAL in the native module?
What about the stdlib?

[jimmo]

In theory you can link against the STM HAL. Your .mpy file can bring in any additional .c files, as well as your own functions from the stdlib (assuming they meet the other requirements described in https://docs.micropython.org/en/latest/develop/natmod.html, e.g. use of .data and static bss).

The limitation is that your .mpy file cannot dynamically link against any symbols in the device firmware other than what we make available in dynruntime.h. So for example, even if the firmware already has some STM HAL function, you have to duplicate it into your native module.

But you only need to include the functions that you actually use.

[jgpeiro]

Ok, I need to include all HAL files again. At least the compiler will optimized all unused fucntions.
And I found the info in the documentation: "It is thus not possible to simply call some arbitrary HAL/OS/RTOS/system function, for example."

So my task now is only create a CubeMX project with the fucntionality I want then add all the files and structure to the makefile...I can do it...
But now I think I have another problem, cause my HAL code should use some HW interrupts...and the interrupt vector on the CPU should be the interrupt vector fom the complete micropython firmware...

Ok, if I cant use interrupts, I can recompile all the upy code, it is not a big problem. I wanted to use a native mode mostly to speed up my development loop.

[jimmo]

And I found the info in the documentation: "It is thus not possible to simply call some arbitrary HAL/OS/RTOS/system function, for example."

Yes, the reality is a bit more nuanced. i.e. you have to also ensure the function and all dependencies are linked, and that they don't share .bss/.data variables etc with something from the firmware.
For the STM HAL at least, this shouldn't be too much of a problem.

But yes, the dynamic native module feature is about just providing fast code for computation, not so much about implementing low-level drivers etc. So interrupts are going to be difficult.