• State Verified Answer
  • Replies 5 replies
  • Subscribers 62 subscribers
  • Views 2140 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?

Parents
  • 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

Reply
  • 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

Children
No Data
Related