To make use of it, as demonstrated in the embedding-full example:
- Include the word(s) "littlefs1" and/or "littlefs2" in EMBED_EXTRA in
micropython_embed.mk.
- Enable the desired MICROPY_*VFS* features in mpconfigport.h.
- Add include path "$(EMBED_DIR)/lib/littlefs" to your application build
system.
For demonstration, a block device implementation containing a small
read-only littlefs2 image is added to the embedding-full example. The block
device could have been written in C and interface to some external,
possibly writable storage medium, but was written in Python and frozen for
simplicity.
What makes this a bit awkward is the fact that the littlefs sources are
located in lib/ and do need to be compiled into the application, unlike all
previous .c files from lib/ that are #included by other C files and must
not be compiled separately. Therefore, introduce a new directory 'libsrc'
in the embed build output that contains these files and can be added to the
application build system as usual, while 'lib' can remain excluded. The
headers need to stay in 'lib' because vfs_lfs.c refers to them under that
path. I am also not entirely happy about having to add an additional
include path to the application build, but see no way around that as long
as vfs_lfs.c refers to "lib/littlefs/lfs2.h" while lfs2.c refers to
"lfs2.h".
Signed-off-by: Christian Walther <cwalther@gmx.ch>
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>
Christian Walther