• State Not Answered
  • Replies 4 replies
  • Subscribers 69 subscribers
  • Views 1634 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 296671
Options

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

Parents
  • 0

    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

  • 0 in reply to Edvin

    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

  • 0 in reply to Induthings

    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

  • 0 in reply to Edvin
    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
Reply
  • 0 in reply to Edvin
    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
Children
No Data
Related