• State Verified Answer
  • Replies 5 replies
  • Subscribers 62 subscribers
  • Views 2127 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 122132
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

peer manager database : N_WRITE_BUFFERS = number of connected peers?

DerPMO

I didn't find any documentation in the peer manager for the need of this write buffers. I do understand, that peer device data is stored there before written to flash. But how big has this buffer to be? I'm looking for RAM space to free and the pm's buffer_memory along with m_write_buffer_records take up HUGE chunks of it, and both are defined by N_WRITE_BUFFERS = 8 in the sdk So the question is, what is this buffer for?

  • Store all devices found while scanning? (seems like a waste of RAM). Reducing the buffer then would mean not to be able to find more then N devices at a time when scanning.
  • Store all devices that are actually connected/bonded. Then N could be reduced to fit the application.
  • Store device information UNTIL it is written into flash. This would mean even more waste of RAM, are there any applications where one would connect/bond to 8 peers at a time?

I guess the second one is true, so is it safe to assume reducing N_WRITE_BUFFERS to the number of (potential) peers (peripheral & central) of the actual application?

  • 0

    First one is not true. I think N_WRITE_BUFFERS limits the number of peers that can bond concurrently, but I will have to confirm that. The buffers are for keeping peer data that hasn't been written to flash, but the buffer is freed after the peer data has been written to flash. Have you tried to reduce it? Did you experience any odd behavior?

  • 0

    First one is not true. I think N_WRITE_BUFFERS limits the number of peers that can bond concurrently, but I will have to confirm that. The buffers are for keeping peer data that hasn't been written to flash, but the buffer is freed after the peer data has been written to flash.

    Did some more testing that confirms my statement above. It seems to be safe to reduce N_WRITE_BUFFERS to the number of concurrent connections (that bonds). Please let me know if you experience something else.

  • 0 in reply to Petter Myhre

    Yes, I can confirm that reducing it to fit my application (1 peripheral + 1 central) is working. Haven't tried going lower than that, but I don't think it would work then.

    As a general suggestion: there are some similar situations where a buffer size is "hardcoded" into the SDK that waste a lot of RAM, forcing me to modify the SDK files (which has to be carefully documented so as to replicate when the SDK gets updated!) It would be nice if e.g. in this case there was a global definition for COUNT_OF_PERIPHERALS, CENTRALS etc. to fit this to the application, or a macro in the sdk_config.h file.

    Personally I have alread changed the following things:

    • BLE_DB_DISCOVERY_MAX_SRV in ble_db_discovery.h
    • BLE_GATT_DB_MAX_CHARS in ble_gatt_db.h

    And it would be nice if one wouldn't have to do all this digging to find the screws to turn the RAM usage down if not needed.

  • 0 in reply to Petter Myhre

    You have a good point, and I totally agree with you. I have reported this back to the developers internally. Thank you for your feedback.

  • 0

    I have found a few other places to edit, maybe of interest for you or others out there, so here is the complete list:

    • N_WRITE_BUFFERS in /components/ble/peer_manager/peer_database.c, reduce to actual concurrent connections/bondings
    • IM_MAX_CONN_HANDLES in /components/ble/peer_manager/id_manager.c, same as above
    • BLE_GAP_WHITELIST_IRK_MAX_COUNT in /components/softdevice/s130/headers/ble_gap.h (My guess is that this also can be reduced to max count of actual concurrent bondings. Not yet testet!
    • BLE_GAP_WHITELIST_ADDR_MAX_COUNT in /components/softdevice/s130/headers/ble_gap.h, same as above, not yet tested!
    • BLE_DB_DISCOVERY_MAX_SRV in /components/ble/ble_db_discovery/ble_db_discovery.h, Number of Services that can be discovered by the application, can be reduced to fit actual application
    • PM_PEER_ID_N_AVAILABLE_IDS in /components/ble/peer_manager/id_manager.c, probably the number of devices (connected, paired and discovered) that can be handled at a time? Have reduced to 64 without any effects (yet)

    can reduce RAM usage up to a few 100 byte depending on the application

Related