#include <cfg/cs_Boards.h>
#include <common/cs_Types.h>

Include dependency graph for cs_StateData.h:

This graph shows which files directly or indirectly include this file:

Classes
struct	cs_state_data_t
	Author: Crownstone Team Copyright: Crownstone (https://crownstone.rocks) Date: Oct 9, 2019 License: LGPLv3+, Apache License 2.0, and/or MIT (triple-licensed) More...

Enumerations
enum class	PersistenceMode : uint8_t { FLASH , RAM , FIRMWARE_DEFAULT , STRATEGY1 , NEITHER_RAM_NOR_FLASH }
	Store values in FLASH or RAM. More...

Functions
cs_ret_code_t	getDefault (cs_state_data_t &data, const boards_config_t &boardsConfig)
	Gets the default. More...

PersistenceModeGet	toPersistenceModeGet (uint8_t mode)

PersistenceModeSet	toPersistenceModeSet (uint8_t mode)

PersistenceMode	DefaultLocation (CS_TYPE const &type)

Enumeration Type Documentation

◆ PersistenceMode

enum class PersistenceMode : uint8_t

strong

Store values in FLASH or RAM.

Load values from FIRMWARE_DEFAULT, FLASH or RAM.

Values that are written fairly often and are not important over reboots should be stored in and read from RAM. For example, we can measure continuously the temperature of the chip. We can also all the time read this value from one of the BLE services. There is no reason to do a roundtrip to FLASH.
Values like CONFIG_BOOT_DELAY should be known over reboots of the device. Moreover, they should also persist over firmware updates. These values are stored in FLASH. If the values are actually not changed by the user (or via the smartphone app), they should NOT be stored to FLASH. They can then immediately be read from the FIRMWARE_DEFAULT. They will be stored only if they are explicitly overwritten. If these values are stored in FLASH they always take precedence over FIRMWARE_DEFAULT values.
Most values can be written to and read from FLASH using RAM as a cache. We can also use FIRMWARE_DEFAULT as a fallback when the FLASH value is not present. Moreover, we can have a list that specifies if a value should be in RAM or in FLASH by default. This complete persistence strategy is called STRATEGY1.

NOTE. Suppose we have a new firmware available and we definitely want to use a new FIRMWARE_DEFAULT value. For example, we use more peripherals and need to have a CONFIG_BOOT_DELAY that is higher or else it will be in an infinite reboot loop. Before we upload the new firmware to the Crownstone, we need to explicitly clear the value. Only after we have deleted the FLASH record we can upload the new firmware. Then the new FIRMWARE_DEFAULT is used automatically.

Enumerator
FLASH
RAM
FIRMWARE_DEFAULT
STRATEGY1
NEITHER_RAM_NOR_FLASH

Function Documentation

◆ DefaultLocation()

PersistenceMode DefaultLocation ( CS_TYPE const & type )

◆ getDefault()

cs_ret_code_t getDefault	(	cs_state_data_t &	data,
		const boards_config_t &	boardsConfig
	)

Gets the default.

Note that if data.value is not aligned at a word boundary, the result still isn't.

There is no allocation done in this function. It is assumed that data.value points to an array or single variable that needs to be written. The allocation of strings or arrays is limited by TypeSize which in that case can be considered as MaxTypeSize.

This function does not check if data size fits the default value. TODO: check how to check this at compile time.

◆ toPersistenceModeGet()

PersistenceModeGet toPersistenceModeGet ( uint8_t mode )

◆ toPersistenceModeSet()

PersistenceModeSet toPersistenceModeSet ( uint8_t mode )

Classes

Enumerations