How crop some function in espidf.c file?

Micropython
,
1

Hi,
In this blog explain that we can reduce the espidf generated API by two ways.

  • Disable some of the includes (by defining some include guard, for example)
  • Or write a separate C API header file that delegates the calls to the real API. (the calls would be on the C file which is not considered by the script). This requires more work but has the advantage of letting you control the API and make it more “python-friendly”.

Have any example for thi?The first way it seems like have some example,but I did’t see any link or somethings.
In my case,I just need the generated API begin with “heap”.

2

There is no automatic way to generate binding only to functions that begin with “heap”.
The way it currently works is that you provide the script an H file and the script generates binding for all functions in this H file.

If you just want a small subset of the original API, you can write an H file with a dedicated C API that delegates the calls to the real API.
There isn’t any complete example of such delegating API because I never needed to do it, but it’s very simple.
Here is a simple example:

#ifdef PYCPARSER
...
static inline void get_ccount(int *ccount);

#else // PYCPARSER

// Helper function to measure CPU cycles
//
static inline void get_ccount(int *ccount)
{
	asm volatile("rsr.ccount %0" : "=a"(*ccount));
}

#endif //PYCPARSER

This example creates Micropython API for get_ccount function.
When the binding script runs it first preprocesses the file with PYCPARSER macro defined, and generates a C stub needed for calling get_ccount from Micropython.
When the Micropython itself is built with the generated stub, the code above is built with PYCPARSER undefined, which provides the implementation for get_ccount.

In case you don’t want to write and maintain C API wrappers, it’s possible to provide the entire original API to the script.
This is what we do with LVGL and with LODEPNG which have their entire API exposed on Micropython.
When the original API changes (and LVGL changes a lot!) there is no need to maintain the API unless there are special cases the script cannot handle.

However, sometimes the API becomes too big.
The cost of a big API is only flash/rom (where the binding code is stored) and not ram, so if you have plenty of flash you usually don’t worry too much about it.
But there are cases where we still want to reduce the Micropython API size. For example, in case of stm32 where flash is smaller, or in case of esp32 where the entire esp-idf API is just too large and also includes some code that the binding script cannot handle.

In such cases we can try to reduce the API using the C preprocessor.
In case of LVGL, we can remove features and widgets by editing the LVGL configuration file.
In case of esp-idf, the hack is to include parts of the API but exclude others by defining their include guards.
It’s a hack - if an include guard changes then it breaks, but it works good enough so far.

3

Hi @amirgon,
Thank you very much for your explanation,I solved this problem.At present, the occupancy of flash has been reduced by tens of KB.It is a very huge space!

Thanks for help me again.
Have a nice day(or night)!