What’s on your mind for AtomVM v0.7?

[bettio]

It’s time to start thinking about AtomVM v0.7. What’s missing? What should we add or improve before tagging a new stable release?

[elsbiet]

maybe you've already guessed - the call overhead, which hurts, should be significantly reduced.

[petermm]

tooling esp32, pico: (believe both are ready - and that the pico one is a blocker)
#1163
#1826

esp32 wifi improvements (scan, reconnect/disconnect etc): (needs rebasing/updating)
#1181
#1165
#1457

Elixir genserver and supervisor: (just need minor polish)
#1476

[UncleGrumpy]

This covers most of my “list”, those would be my highest priorities too.

I also would not mind seeing getting the error returns from the gpio driver to be consistent across the various MCU platforms:

#1448
#1408

It would also be great to see support for esp32 light sleep make it into this release:

#1789

[UncleGrumpy]

I would like to propose rearranging the ESP32 partition table. I believe it would be beneficial to move the nvs partition to after the the boot.avm partition. This should not cause any breakage with default release images, and will have several advantages. When flashing a new image, the nvs partition would not be erased, unless explicitly done so by the user. The partition could also be removed, allowing the freed flash space to be used by user applications.

I am working on a set of tools that can be added as dependencies to atomvm_rebar3_plugin and exatomvm to allow generating and flashing provisioned NVS partitions, and editing the esp32 partition table. If the nvs partition is moved to after the main.avm (AtomVM binary) and boot.avm (esp32boot - libraries), users would be able to opt not to have an nvs partition, and free more flash space for their application, or generate a larger nvs partition if needed. These tools will work with custom builds or release images, and allow devices with larger flash space to rewrite the release image partition table to use all of the available space. Uses will also have the option deleting the boot.avm library partition in favor of packing (and optionally pruning unused library modules) into their applications, allowing for maximum flexibility in how flash space is used.

My proposed partition tables would look like this:

partitions.csv

# Name,   Type, SubType,   Offset,       Size, Flags
phy_init, data, phy,       0x9000,     0x1000,
factory,  app,  factory,   0xA000,   0x1C0000,
boot.avm,  data, phy,    0x1CA000,    0x40000,
nvs,      data, nvs,     0x20A000,     0x6000,
main.avm, data, phy,     0x210000,   0x100000,

partitions-elixir.csv

# Name,   Type, SubType,   Offset,       Size, Flags
phy_init, data, phy,       0x9000,     0x1000,
factory,  app,  factory,   0xA000,   0x1C0000,
boot.avm, data, phy,     0x1CA000,    0x80000,
nvs,      data, nvs,     0x24A000,     0x6000,
main.avm, data, phy,     0x250000,   0x100000,