FLASH and RAM memory analysis

[JF002]

Now that we've just released version 1.0 of this project, I think it would be useful to take some time to analyze the memory (RAM and FLASH) usage.
Indeed, both memory are nearly full right now : firmware is ~410KB out of the 460KB available, and it's becoming harder and harder to find RAM memory to allocate buffers when needed.

FLASH memory usage should be fairly easy to map using the .map file.

RAM memory usage is a bit more difficult to figure out. I've already done a bit of researches :

• There is a global stack and heap regions allocated by the linker script. I think both are 8KB. How full are they? Can we shrink or are they already full?
• FreeRTOS use a 16KB buffer as a heap for its own use (memory allocation, stack for tasks,...)
• LVGL has its own 14KB memory buffer.
• NimBLE probably use a good amount of RAM memory too. How much? And where is it allocated?

Mapping memory usage will allow us to see what's need to be optimized and which solutions we can implement to be able to continue to add new features and applications.

[ObiKeahloa]

Can we try reducing the FreeRTOS heap size or is it already at its smallest.

We could also try to remake NimBLE but that would require a lot of handwork and isn't guaranteed to succeed.

[kieranc]

This shows the reduction in the DFU file size that I saw when disabling each of the following components:

[DavidVentura]

I did some quick analysis using a fork of linkermapviz

  105596 liblvgl.a
  101668 libnimble.a
   19443 lv_font_navi_80.c.o
   18872 libnrf-sdk.a
   14428 bg_clock.c.o
   11901 libc_nano.a
    9682 Navigation.cpp.o
    7422 SystemInfo.cpp.o
    7080 libgcc.a
    6780 bma423.c.o

I uploaded the results of running linkermapviz vs develop: Full and without nimble and lvgl (they take 50% of space by themselves and skew perspective)

[ObiKeahloa]

We could try to remake the heavy hitters (The Navigation and AnalogWatchface) from scratch and see if it helps.

[ObiKeahloa]

About NimBLE , we could again try replacing parts of it with our own custom made variant or we could try to completely ditch it and make our own stack based on it.(It does seem to use a WHOLE lot of memory)

[DavidVentura]

it is possible that we are linking the entire static libs while we only use part of them.

i spent a while playing with LTO to try and shake the unused bits off, but i did not succeed (managed to get linking working but the resulting file was larger, so probably it both mangled LTO and disabled linker GC pass)

[ObiKeahloa]

it is possible that we are linking the entire static libs while we only use part of them -- i spent a long while playing with LTO to try and shake the unused bits off, but it did not work (linking worked but the resulting bin file was larger)

True , is there anyway to find out which static libs are being used?

[DavidVentura]

Check the links i posted, the ones ending in `.a` are static

…

On Tue, 4 May 2021 at 13:06, MysteriousLog6 ***@***.***> wrote: it is possible that we are linking the entire static libs while we only use part of them -- i spent a long while playing with LTO to try and shake the unused bits off, but it did not work (linking worked but the resulting bin file was *larger*) True , is there anyway to find out which static libs are being used? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#313 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA33I3TO26S2G5P6LBNMXATTL7WMNANCNFSM43PEJMVQ> .

-- *Stack* is the new term for "I have no idea what I'm actually using".

[Avamander]

About NimBLE , we could again try replacing parts of it with our own custom made variant or we could try to completely ditch it and make our own stack based on it.(It does seem to use a WHOLE lot of memory)

Absolutely not, I'm very against this. This is not a maintenance burden that's reasonable to take.

[Avamander]

it is possible that we are linking the entire static libs while we only use part of them -- i spent a long while playing with LTO to try and shake the unused bits off, but it did not work (linking worked but the resulting bin file was larger)

As discussed, incorrect linker/compiler flags or their combinations, but yes it is difficult to achieve correct results. Correct LTO doesn't add size.

[Avamander]

We could try to remake the heavy hitters (The Navigation and AnalogWatchface) from scratch and see if it helps.

No, that's unlikely to help in any significant way. Just store the used resources on external storage. Code is very very dense and ultra rarely the actual issue (that automated tools can't optimize).

[DavidVentura]

it is possible that we are linking the entire static libs while we only use part of them -- i spent a long while playing with LTO to try and shake the unused bits off, but it did not work (linking worked but the resulting bin file was larger)

As discussed, incorrect linker/compiler flags or their combinations, but yes it is difficult to achieve correct results. Correct LTO doesn't add size.

yea that was implied in my message - now i see it was unclear; sorry for the noise. will update the comment

[ObiKeahloa]

We could try to remake the heavy hitters (The Navigation and AnalogWatchface) from scratch and see if it helps.

No, that's unlikely to help in any significant way. Just store the used resources on external storage. Code is very very dense and ultra rarely the actual issue (that automated tools can't optimize).

About NimBLE , we could again try replacing parts of it with our own custom made variant or we could try to completely ditch it and make our own stack based on it.(It does seem to use a WHOLE lot of memory)

Absolutely not, I'm very against this. This is not a maintenance burden that's reasonable to take.

Well , is there anyway we can reduce the memory usage of NimBLE? I do understand why your against an entirely new Bluetooth stack , removing parts of it might work.

[DavidVentura]

Compiling with size optimization (-Os) brings ~80KB savings (see this comment for details), down to ~320KB. I can't notice any performance difference when using the watch.

Another 35-40KB can be moved to flash (fonts + analog clock bg), although adding LittleFS support would bring ~20KB making net gains ~20KB