Files and Items Sub-layer

The Files and Items sub-layer manages the following functionality:

• Organizes the storing/retrieving/deleting of MLS parameters
• Provides APIs to stack and application to perform PDS operations

The basic element in Files and Item abstraction is that an Item and a File is a collection of Items. Therefore, if the user identifies the File ID and Item ID one can easily store/retrieve/delete an item in PDS. The Item is a parameter or variable and is private to a layer in the stack, and is not exposed to the outside world. If the PDS must store an item it requires the following information about the parameter:

• RAM Address
• Size
• File ID mapping
• Item ID allocated to variable
• Items offset inside the File

The following operation can be performed for every Item in a File:

• Store
• Delete
• Restore

The above information is essential because storing or deleting of an Item takes a significant amount of time (unlike read operation in Flash) and these operations are not done synchronously, but instead scheduled by the Task Handler. For more information on the Task Handler execution, refer to Task Handler.

To perform these operations, stack or application must inform the PDS which operation needs to be performed along with Item information. For this purpose, stack or application needs to register in the PDS module during initialization with an array containing flags for each Item per File.

The information is organized in the form of arrays for each File ID and it is the duty of each layer to register this array with the following information to the PDS:

• File ID Item array address
• Array size
• File marks array address
• File marks array size

The PDS will just scan the array registered above to know about the operation to perform. So, from the PDS perspective, it just needs to know which File IDs are used and does not care what is inside them. It is the responsibility of each layer that needs PDS to create a mapping for each File to an Item and maintain offsets. The PDS needs to know for which File an operation is pending and not for individual items in a File. So, the PDS maintains a File mask which tracks the items that need an update and this File mask must be set by the individual layers using the File.

For example, if an item needs to be stored into PDS, the layer using the File ID posts a mask for that File ID to inform PDS that an action is pending and it needs to update the Files’ marks that the layer maintains. In this case it is store. Now when the PDS is scheduled, it checks the File mask and it recognizes that an action is pending for a File ID. Then it searches the File array data that the layer registered with PDS and knows about the action to be performed, i.e., store, the address of the Item in RAM, the offset within the File and the size of the File. So, with all this information the PDS will copy the data from RAM to the PDS buffer. This buffer may already contain data if the File is already present or an empty buffer, if it is the first time an operation is done for the File. After populating the buffer, it is sent to the Wear Leveling abstraction layer which adds increments the File counter. Then the buffer is passed to the NVM abstraction which adds the 16-bit CRC. Similarly, for PDS delete, except that the Delete bit is set and no RAM copy is performed.