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?

[Petter Myhre]

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.

[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.