I suggest do it like stm32 and near the top of mpconfigport.h have:

#ifndef MICROPY_CONFIG_ROM_LEVEL
#define MICROPY_CONFIG_ROM_LEVEL (MICROPY_CONFIG_ROM_LEVEL_EXTRA_FEATURES)
#endif

That will default it to extra features, like rp2 and stm32. But boards can let a lower level if needed.

Any board with 1M or more of flash could use extra features?

I do understand that this will change the default features on pretty much every nrf board however, is there something we should do to ease any transision for users?

If it's only enabling features, and only done on boards that have enough flash, then it should be an easy transition (because nothing is removed).

The way @jimmo was converting existing ports to use this feature was to make a commit that was a no-op in terms of features changes. That would then allow you to see exactly what was the difference between the existing config and one of the pre-defined feature levels.

I've updated the PR to keep it generally in mpconfigport.h but keep nrf51 set to CORE by default as I doubt it'll even build on extra.

I'm not too sure about nrf52832 - it's only 512/256 KB Flash, 64/32 KB RAM. Is EXTRA appropriate here, or should it be left lower as well?

I've essentially copied all the define's from EXTRA into mpconfigboard in a61e120 to show changes, I hope this is generally what you were suggesting? The duplications of these / other things set to default were then cleaned up in the later commit.

I'm not too sure about nrf52832 - it's only 512/256 KB Flash, 64/32 KB RAM. Is EXTRA appropriate here, or should it be left lower as well?

Good question. It should probably be BASIC (although that is pretty much the same as CORE, but it will change in the future). I suggest BASIC for nrf52832.

I've essentially copied all the define's from EXTRA into mpconfigboard in a61e120 to show changes, I hope this is generally what you were suggesting?

Not really... is that first commit a no-op in terms of feature change, even for nrf51822? Anyway, doesn't really matter, just leave it as you have it.

Not really... is that first commit a no-op in terms of feature change, even for nrf51822? Anyway, doesn't really matter, just leave it as you have it.

Yeah I broke nrf51 in that commit, fixed later, it's a bit of a mess. I'd like to do this properly, so I'll scan through the git log for one of @jimmo's previous ones as a pattern to follow.

For esp32 example, see c8cd5a9 and then 5935fa2

For rp2 see b1a0ce4

I've reworked this PR to make a much cleaner change.

The first commit ports/nrf: Set MICROPY_CONFIG_ROM_LEVEL defines for each core now presents a zero overall change to the configuration. This was confirmed by running make show-config from #8437 before and after the commit and comparing the outputs.
This was done for the configurations:

• make show-config BOARD=microbit (NRF51822)
• make show-config SD=s110 BOARD=microbit BUILD=build-microbit_sd (NRF51822 & BLUETOOTH_SD)
• make show-config BOARD=pca10040 (NRF52832)
• make show-config BOARD=pca10056 (NRF52840)
• make show-config BOARD=pca10090 (NRF9160)

The second commit enables extra features from the ROM levels and further simplifies mpconfigport.h.

• NRF51822 & BLUETOOTH_SD -> MICROPY_CONFIG_ROM_LEVEL_MINIMUM - no changes
• NRF51822 -> MICROPY_CONFIG_ROM_LEVEL_CORE_FEATURES
  • MICROPY_PY_IO = 1
• NRF52832 -> MICROPY_CONFIG_ROM_LEVEL_BASIC_FEATURES

• MICROPY_PY_IO = 1

• NRF52840 -> MICROPY_CONFIG_ROM_LEVEL_EXTRA_FEATURES
  • MICROPY_COMP_MODULE_CONST = 1
  • MICROPY_COMP_TRIPLE_TUPLE_ASSIGN = 1
  • MICROPY_OPT_MPZ_BITWISE = 1
  • MICROPY_PY_ALL_SPECIAL_METHODS = 1
  • MICROPY_PY_BUILTINS_EXECFILE = 1
  • MICROPY_PY_BUILTINS_SLICE_ATTRS = 1
  • MICROPY_PY_BUILTINS_STR_CENTER = 1
  • MICROPY_PY_BUILTINS_STR_PARTITION = 1
  • MICROPY_PY_BUILTINS_STR_SPLITLINES = 1
  • MICROPY_PY_CMATH = 1
  • MICROPY_PY_COLLECTIONS_ORDEREDDICT = 1
  • MICROPY_PY_FRAMEBUF = 1
  • MICROPY_PY_IO = 1
  • MICROPY_PY_MATH_SPECIAL_FUNCTIONS = 1
  • MICROPY_PY_SYS_STDIO_BUFFER = 1
  • MICROPY_PY_UCTYPES = 1
  • MICROPY_PY_UHEAPQ = 1
  • MICROPY_PY_UJSON = 1
  • MICROPY_PY_URE = 1
  • MICROPY_PY_UZLIB = 1
  • MICROPY_REPL_EMACS_KEYS = 1
• NRF9160 -> MICROPY_CONFIG_ROM_LEVEL_EXTRA_FEATURES
  • Same list of changes as NRF52840

An additional minor commit was then needed to support building/using MICROPY_PY_IO.
Lastly, nrf/moduos: Convert module to use extmod version. was needed for compatibility.

Lastly, nrf/moduos: Convert module to use extmod version. was needed for compatibility.

I'm not sure about this commit, it looks like it completely removes the nrf's moduos.c code? That means uos will lose sep, uname, urandom, sync, and dupterm (and maybe others). These need to be enabled via specific options like MICROPY_PY_UOS_SEP. And for urandom the port needs to provide the actual implementation.

Also, the biggest issue with uos is that if MICROPY_MBFS is enabled then it won't really work to use extmod/moduos.c....

So I suggest to just drop that last commit for now and do the moduos conversion later/separately.

Also, please rebase on latest master (that will bring up a few conflicts, but shouldn't be too hard to resolve).

Thanks for updating. Rebased and merged in 13f5d38 through 494e8ba