 |
AIROC™ BTSDK v4.8 - Documentation | |||
|
AIROC™ BTSDK v4.8 - Documentation | |||
This driver provides simplified access to the volatile section ("VS") of memory. More...
Modules | |
| Enumerated Types | |
| Functions | |
This driver provides simplified access to the volatile section ("VS") of memory.
The following APIs allow the application layer to easily read and write into VS section so that persistent data can be stored through a power cycle. The most common use of these APIs will be storing link keys of peer devices in order to bond with those devices.
The VS_ID's used as parameters to the read and write functions below are merely handles used to refer to the data stored by the app. They do not indicate the physical storage location of the memory. It is not necessary to use sequential VS_ID's, nor is it necessary to use them in ascending order. The VS_ID is nothing more than a file name and any VS_ID can be used that lies in the range 0x200 - 0x3fff.
The amount of available memory using the NVRAM APIs defaults to 4KB. This can be increased if more space is needed, but it will reduce the amount of memory available to the application.
In order to fully utilize the 4K of memory available, care must be taken by the developer. The 4K of memory is broken up into blocks of 512 bytes and the NVRAM APIs will not handle the wrap-around between these blocks. For small numbers of bytes written (1-50), this limitation is not of significant concern. Larger write sizes, must exercise caution. For example, if the NVRAM API is used to write eight 260 byte chunks in a row, then it will end up consuming all 4K of physical memory. Because two 260 byte chunks cannot fit into a single block, each one is allocated it's own page.
The max size that can be written to a single VS_ID is 500 due to the limitation of the 512 block size. The remaining 12 bytes are header space. The more VS_ID's used, the less overall space will be used because there will be less headers to store.
