It doesn't fit in the firmware image without disabling something else in turn in order to make room. When using the top of tree master branch I can create a build of v1.12-623-gf743bd3d2-dirty that has float support by adding the LIBM linking (as your application.mk suggests and other ports do), but in order for it to fit into an mcuimg.bin that is not rejected upon upload, I have to disable longint support (LONGINT_IMPL_NONE). (using the 2020-q2 gnu-arm-none-eabi compiler toolchain)sekil wrote: ↑Thu Mar 26, 2020 6:19 amthat is possible to make fw with working floating and math.. And no need reinvent crutches for floating values.. And no official info about how compile floating support on this board - only "due to ram limitation... bla bla" - but this working and with 45kb ram - and we need change cflags, ldflags and python configs..
At this point, the legacy wipy has shipped, complete with the set of expectations it came with. Disabling a feature to make room for a new one in default shipped builds would break existing code. People who want something different can dive into building their own micropython. This isn't a modern microcontroller.
Code: Select all
$ make BTARGET=application BTYPE=release BOARD=WIPY
...
LINK build/WIPY/release/application.axf
text data bss dec hex filename
196640 1200 64304 262144 40000 build/WIPY/release/application.axf
Create build/WIPY/release/application.bin
Create build/WIPY/release/mcuimg.bin
Code: Select all
>>> import machine
>>> machine.reset()
MicroPython v1.12-623-gf743bd3d2-dirty on 2020-07-12; WiPy with CC3200
Type "help()" for more information.
>>> import gc
>>> gc.mem_free()
39120
An unmodified build at that revision has an additional 13k of ram. floating point, after losing longint support, consumed 13k. Ouch. But not entirely surprising given the soft float implementation:
Code: Select all
>>> gc.mem_free()
52448