What is the expected code size for a full featured GG Stack?
jagobagascon opened this issue · 2 comments
Hi! We are looking for an alternative to our current IoT communication stack and we just came across this project. I've been playing around with it for quite a while and it looks amazing.
I would like to propose this framework to our firmware department but I have some doubts regarding code size. According to your post in https://eng.fitbit.com/introducing-project-golden-gate/ the framework is prepared to work on "a few kilobytes of RAM and flash and low power MCUs" but I've been playing around with the provided examples and I feel like the size of the binaries I'm getting is a bit high.
"Gattlink blast over udp" binary for example takes 182 KB and even though I managed to get it down to 125 KB by modifying the provided linux profile (disabled some unused features like DTLS or Lwip), it's still heavier than our current stack (which does include DTLS). I'm not experienced in C, CMake or IoT devices so it can probably be reduced a lot more. Thats why I would like to know the sizes you are working with, what is the size I should expect for a full featured (CoAP, DTLS, Gattlink and Sockets) GG communication stack?. We are trying not to go past ~100 KB and knowing the binary sizes you are working with will be helpful.
Thanks a lot.
The runtime code size depends somewhat on what features you use, but here's what I can see for a typical use case: compiling the sample app for MyNewt (running on an ARM Cortex M-4) with DTLS and CoAP, looking at just the stack runtime (i.e not the test CoAP services used as a demo, like the Hello World resource or the internal blast test service), I get (code size):
- cross-platform lib: 43,710 bytes
- mbedtls: 44,206 bytes
- LWIP: 4,966
Total: 92,882 bytes
To this you need to add the code that interfaces with Bluetooth, which is very platform-dependent. On MyNewt with the Nimble stack, I think that's about 3-4kB.
The mbedtls library is of course about 50% of the code size here, so if you want to reduce the size significantly, swapping in a smaller library that may be more compact, with DTLS support (such as tinydtls) may help. The framework uses an internal abstraction layer for TLS (xp/tls/gg_tls.h), so swapping the TLS library from mbedlts library to something else should be fairly straightforward. The mbedtls implementation of that abstract API lives in xp/tls/ports/mbedtls.
Perfect, thank you so much!