GATT (Services and Characteristics) at runtime and memory consumption on Zephyr

[Induthings]

Dear Sir.

we are porting some projects from nRF5 to Zephyr and the UUID/handlers table consume more memory. What is the best practice? we are trying to do the same things that we did on Softdevice on small MCUs like 52820, but as we suspect on Zephyr the memory consumption could be a problem.

https://github.com/zephyrproject-rtos/zephyr/issues/20707

Thanks in advance, best regards

[Edvin]

Hello,

I would think that the applications running in NCS/Zephyr that have the similar functionality of an nRF5 SDK Example will have a larger footprint. For reference, the ble_app_uart example from the nRF5 SDK is roughly 0x22337 bytes ( approx. 140 kB):

This is including the SoftDevice.

The peripheral_uart sample found in NCSv2.1.0\nrf\samples\bluetooth\peripheral_uart doesn't build for nRF52820, because it is too big. It does have bonding, which the ble_app_uart example doesn't have, but disabling this, and reducing the heap and workqueue stack size makes me able to build it:

Using 190kB, and 32 (!) kB of RAM. 

I don't know whether you need DFU, but in NCS you need space for 2x application, while in the nRF5 SDK you can separate the BLE stack and the application. Other than that, I think you just need to try to implement the application that you need to see whether or not it will fit on the nRF52820.

Best regards,

Edvin

[Induthings]

sorry I was not clear, I referred to RAM memory consumption. Using your example:

	Zephyr	Softdevice S140		Diff [bytes]	Diff [KB]
FLASH	191348	181496		9852	9.6
SRAM	32457	18096		14361	14.0

we are migrating a nRF5 code with 37 characteristics in 6 services, and the code generated in Zephyr has not enough RAM (the complete old code will need more RAM).

my point is, if I'm doing something wrong or the conclusion is that we can't migrate to Zephyr the nRF5 code for small MCUs? Thanks in advance

[Edvin]

Well, You can run simple applications on the smaller MCUs as well, but there is a limit, of course. And having an RTOS (Zephyr) will typically require more resources than a bare metal approach (nRF5 SDK). 

I am not saying it will not work, or that it will work to have 37 characteristics, 

If you want to give it a go with a template project that I have (which has one service and two characteristics), you can check out this project:

remote_controller.zip

Disabling logging in prj.conf will probably also reduce the size of the application (flash and RAM).

But I don't know whether you will fit 37 characteristics. You simply need to test it.

Best regards,

Edvin

[Induthings]

My original question was, how to improve the use of RAM on services and characteristics implementation. But the analysis resulted in a better understanding of the RAM and FLASH requirements for Zephyr projects. I think as generalization a Zephyr project needs the double size of RAM and FLASH. Many of our old developments are not suitable to migrate. It will be very hard to fit medium complex tasks on small MCUs. Thanks for your support