search

u-blox / ubxlib

Portable C libraries which provide APIs to build applications with u-blox products and services. Delivered as add-on to existing microcontroller and RTOS SDKs.
Apache License 2.0
301 stars 90 forks source link

Disable certain features at compile time #30

Closed ghost closed 3 years ago

ghost commented 3 years ago

We are considering using ubxlib with a cellular modem and will not need WiFi or BLE features. Unfortunately, there are some calls to the BLE layer in the common library, specifically in the network component. The socket layer will presumably have the same issue with WiFi once that is implemented.

Do you intend to add compile time options to disable support for certain device classes or devices? That would allow us to reduce the amount of flash memory required for ubxlib.

RobMeades commented 3 years ago

Hi there: it is not properly documented but the way this is intended to work is to use the xxx_stubs.c files in network/src which should allow the linker to drop the unused code, see also the bit in our test system where we check that the stubs at least compile, u_run_lint.py.

It so happens that we have some guys internally developing a cellular application in a very limited code space that are using exactly this mechanism at the moment (@qasim-ublox), in fact I thought your issue was a pull request coming in from them because our stubbing wasn't working properly, so if the stub files don't do what you need watch this space as those guys will have exactly the same problem.

Can I ask which toolchain you are using?

ghost commented 3 years ago

Hey, thanks for the quick response! I missed the stub files, that should be good for us. I did not try to use them so far, so I have no idea if they are working for us or not. We are actually not that limited on code space, but having to include a complete WiFi and BLE driver seemed a bit too wasteful even if it is not a problem on our current platform.

Regarding the toolchain question: So far, I only did a quick evaluation run on an STM32F4 with the STM32CubeIDE project you provide. The real project will use another STM32 variant on a CMake + ARM-GCC toolchain and a different RTOS. Since that will require some work to create the port, I want to evaluate the library on the STM32F4 platform first.

RobMeades commented 3 years ago

Understood, thanks for the background info. Very happy to receive any feedback after your investigations, we may well be able to accommodate any changes you think we need.

RobMeades commented 3 years ago

I've added some documentation for the stubs in 4dc1b, closing this on that basis; please re-open if you disagree and certainly open new issues with any requests if you think there are things we should improve for you.

ghost commented 3 years ago

Great, I just tried that procedure. Only replacing the files with the stub files did not have much of an effect in the Stm32CubeIDE, I guess it either does not optimize unused functions at link time or it was because of the examples.

When I removed the corresponding internal files for BLE, GNSS and WiFi along with the tests, I was able to reduce the memory footprint by 60kB, so it seems like this is working when you properly adjust the build system.

RobMeades commented 3 years ago

Hmm, interesting, there are some directives (here and here) we employ in the nRF5 makefile which GCC needs to drop unused sections, I'm not sure if the STM32F4 Eclipse IDE files (which are mostly standard boilerplate from ST) have those.

Anyway, glad you've been able to progress.