The following code examples show the typical usage of Flash Data Storage in an application.
Initialization, like all other operations in FDS that involve writing or erasing flash memory, is an asynchronous operation. Completion of the operation is reported to the application through a callback.
The following example code shows how to register a simple event handler with FDS and initialize the module:
The init operation will return an event notification upon success.
In the Peer Manager, fds_init is part of the initialization function pm_init. The module can be initialized multiple times, with no side effects.
The following example code shows how to write a record:
The command is queued up, and the success or failure is indicated through event callbacks. Upon success, the fds_record_write function returns a descriptor for the record, which can be used to further manipulate the record.
See Restrictions on keys and IDs for information about valid record keys and file IDs.
The following example code shows how to use the find record functionality to retrieve record descriptors for all records that match a specific key and file ID and read their contents:
Closing a record with fds_record_close will not invalidate the record descriptor or the fds_flash_record_t structure. The record descriptor can still be used to manipulate the record to, for example, open it again or delete it. However, the data pointed to by the fds_flash_record_t structure might change at any time after the record is closed. So if you need to access the data after closing the record, you must open it again.
The following example code shows how to delete a record:
The operation is queued up, and the success or failure is indicated through event callbacks.
Calling fds_record_delete will not free the flash memory used by the record. To reclaim the flash space used by records that were deleted, run a garbage collection (fds_gc).