The flash driver is update to support the new `mp_vfs_rom_ioctl()`
function, and the buffer protocol is added to `samd_flash_type` (it is
needed for VfsRom on devices without external flash).
For SAMD21, only boards with external SPI flash have VfsRom enabled, due
to size constraints. For such boards, the VfsRom filesystem has a size of
12k and is placed at the upper end of the flash. The `onewire`, `ds18x20`
and `dht` drivers have been removed from frozen bytecode as they can be
placed into the VfsRom files when needed.
For SAMD51, the VfsRom filesystem has a default size of 64k for SAMD51x19
and 256K for SAMD51x20. It is placed at the upper end of the flash.
For boards with external SPI flash, the code size is reduced from 496K to
432K. If that is not sufficient for some boards or configurations, it can
be changed for each board or board variant.
Tested with ADAFRUIT_ITSYBITSY_M0_EXPRESS, ADAFRUIT_ITSYBITSY_M4_EXPRESS,
SPARKFUN_SAMD51_THING_PLUS, SEEED_XIAO_SAMD21, SAMD_GENERIC_D51X19, and
SAMD_GENERIC_D51X20.
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: robert-hh <robert@hammelrath.com>
Use `self` (the first argument) instead of the global `samd_flash_obj` when
accessing the `flash_base` parameter. This allows there to be multiple
flash objects for various types of filesystem.
Signed-off-by: robert-hh <robert@hammelrath.com>
The STATIC macro was introduced a very long time ago in commit
d5df6cd44a. The original reason for this was
to have the option to define it to nothing so that all static functions
become global functions and therefore visible to certain debug tools, so
one could do function size comparison and other things.
This STATIC feature is rarely (if ever) used. And with the use of LTO and
heavy inline optimisation, analysing the size of individual functions when
they are not static is not a good representation of the size of code when
fully optimised.
So the macro does not have much use and it's simpler to just remove it.
Then you know exactly what it's doing. For example, newcomers don't have
to learn what the STATIC macro is and why it exists. Reading the code is
also less "loud" with a lowercase static.
One other minor point in favour of removing it, is that it stops bugs with
`STATIC inline`, which should always be `static inline`.
Methodology for this commit was:
1) git ls-files | egrep '\.[ch]$' | \
xargs sed -Ei "s/(^| )STATIC($| )/\1static\2/"
2) Do some manual cleanup in the diff by searching for the word STATIC in
comments and changing those back.
3) "git-grep STATIC docs/", manually fixed those cases.
4) "rg -t python STATIC", manually fixed codegen lines that used STATIC.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
Instead of being an explicit field, it's now a slot like all the other
methods.
This is a marginal code size improvement because most types have a make_new
(100/138 on PYBV11), however it improves consistency in how types are
declared, removing the special case for make_new.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
