I will be setting this from my cmodule like so:

CFLAGS_USERMOD += -DMEM_USER_MAXLEN=0

I have just verified that this patch fixes my issue. By using the CFLAGS_USERMOD line above in my cmodule Makefile. Once this PR is merged, I can start building from upstream again.

I mostly work with the stm32 port, where there's lots of this kind of #ifdef for overriding during build, so the concept should be fine.

Most of the build defines there though follow a common pattern like MICROPYTHON_PY_XYZ, as seen in https://github.com/micropython/micropython/blob/master/ports/stm32/boards/B_L072Z_LRWAN1/mpconfigboard.h for example.

I'm not sure if this pattern (or similar) is also common in esp port, but I'd suggest it's good to follow either way to highlight the fact this is intended and a build variable (with hard coded default).

Hi @andrewleech

I don't see anything called mpconfigboard.h. For the ESP32 we do use an sdkconfig file which essentially sets up the underlying system on the ESP32 image. I suspect its similar.

I do like the idea of having a common place to configure MicroPython for each port, and we do have mpconfigport.h which is probably the most similar thing we have. We just don't have different configs for different boards (other than those with and without external PSRAM, which the sdkconfig handles).

I'm happy to move some defaults to elsewhere, but for the moment I don't think there is a home for this sort of thing on the ESP32 port. It would also still need to be an #ifndef because I'm trying to make zero changes to MicroPython repository when building, so I need to declare the variable as a C_FLAG.

ESP32 doesn't currently have the concept of a board like STM32; the mpconfigboard.h is akin to the mpconfigport.h but for board-level configuration.

I've started looking in to extending the ESP32 port to handle boards; it would make sense given the glut of different boards that have appeared. Could use some help though because my first priority was bringing that concept to the ESP8266 (primarily to make it easy for a beginner to start with the popular Wemos boards and their distinct "Dx" naming of pins).

Sorry my intention when linking to that file wasn't so much meaning to use a board config file, but just an example of #define naming conventions.

Still, I'm not sure if that convention is used elsewhere on the esp ports, but I think it's a good idea for consistency nonetheless.

I was talking to @zrecore this morning regarding his D2WD board issues. You're right @mattytrentini that with the increase in ESP32 boards I'd like to see an approach to having board configs. Similar to the way stm32 port is handling it. We have a board directory. We should have subfolders for board configurations/community boards with their own sdkconfig, defines, and partition.csv so that when someone wants to compile uPy for a board they have purchased from Tindie or wherever, they can just make BOARD=tinypico and it builds as recommend

@jimmo Is there anyway to achieve this with your changes in #4991 ? I'd really like my small change to land in master but if I can achieve the same with your changes, I'll do that and either rebase on top of what you have, or just wait for that to land and create a new PR.

Seems like the typical thing is to have vars prefered with MICROPY_ and they should be set somewhere before build, probably in a board Makefile. So I guess it would be better to follow convention and change the name of this variable. I'll do that.

@nevercast Yes, this is exactly the intention of #4991. You would set this variable in boards/BOARD/mpconfigboard.h (not the makefile).

Note: the convention seems to be to name it MICROPY_HW_, and generally you don't see port-specific (e.g. _ESP32_) parts. I'd call it MICROPY_HW_RTC_USER_MEM_MAX.

I see, _HW_ is anything that is port specific?

Rebased and applied recommendations. Is it worth adding any documentation regarding this? Or a board config to demonstrate that this can be configured in mpconfigboard.h ?

Spoke with @jimmo and he seemed happy with this. Is there anything blocking this being merged, @dpgeorge ?

Can I please get some feedback on this? I am using this feature so I can't use mainline upy. Cheers.

Rebased and squashed. Had to do it at my end anyway so pushed the change upstream.

I will present this pull request better in the future, and add examples or tests.

Followed up in #5349