From 9f95ff5b6ba01db09552b84a0ab79607060a2666 Mon Sep 17 00:00:00 2001 From: Ali Labbene Date: Wed, 11 Dec 2019 08:59:21 +0100 Subject: Official ARM version: v5.4.0 Add CMSIS V5.4.0, please refer to index.html available under \docs folder. Note: content of \CMSIS\Core\Include has been copied under \Include to keep the same structure used in existing projects, and thus avoid projects mass update Note: the following components have been removed from ARM original delivery (as not used in ST packages) - CMSIS_EW2018.pdf - .gitattributes - .gitignore - \Device - \CMSIS - \CoreValidation - \DAP - \Documentation - \DoxyGen - \Driver - \Pack - \RTOS\CMSIS_RTOS_Tutorial.pdf - \RTOS\RTX - \RTOS\Template - \RTOS2\RTX - \Utilities - All ARM/GCC projects files are deleted from \DSP, \RTOS and \RTOS2 Change-Id: Ia026c3f0f0d016627a4fb5a9032852c33d24b4d3 --- .../Driver/html/group__StorageDriverFunctions.html | 169 +++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 docs/Driver/html/group__StorageDriverFunctions.html (limited to 'docs/Driver/html/group__StorageDriverFunctions.html') diff --git a/docs/Driver/html/group__StorageDriverFunctions.html b/docs/Driver/html/group__StorageDriverFunctions.html new file mode 100644 index 0000000..1c86a7d --- /dev/null +++ b/docs/Driver/html/group__StorageDriverFunctions.html @@ -0,0 +1,169 @@ + + + + + +Use of Storage APIs +CMSIS-Driver: Use of Storage APIs + + + + + + + + + + + + + + +
+
+ + + + + + + +
+
CMSIS-Driver +  Version 2.6.0 +
+
Peripheral Interface for Middleware and Application Code
+
+
+ +
+
    + +
+
+ + + +
+
+ +
+
+
+ +
+ + + + +
+ +
+ +
+
+
Use of Storage APIs
+
+
+

Function pointers within ARM_DRIVER_STORAGE form the set of operations constituting the Storage driver. Their implementation is platform-specific, and needs to be supplied by the porting effort.

+

Some of these APIs will always operate synchronously:

+ +

This means that control returns to the caller with a relevant status code only after the completion of the operation (or the discovery of a failure condition).

+

The remainder of the APIs:

+ +

can function asynchronously if the underlying controller supports it; that is if ARM_STORAGE_CAPABILITIES::asynchronous_ops is set. In the case of asynchronous operation, the invocation returns early (with ARM_DRIVER_OK) and results in a completion callback later. If ARM_STORAGE_CAPABILITIES::asynchronous_ops is not set, then all such APIs execute synchronously, and control returns to the caller with a status code only after the completion of the operation (or the discovery of a failure condition).

+

If ARM_STORAGE_CAPABILITIES::asynchronous_ops is set, a storage driver may still choose to execute asynchronous operations in a synchronous manner. If so, the driver returns a positive value to indicate successful synchronous completion (or an error code in case of failure) and no further invocation of completion callback should be expected. The expected return value for synchronous completion of such asynchronous operations varies depending on the operation. For operations involving data access, it often equals the amount of data transferred or affected. For non data-transfer operations, such as EraseAll or Initialize, it is usually 1.

+

Here's a code snippet to suggest how asynchronous APIs might be used by callers to handle both synchronous and asynchronous execution by the underlying storage driver:

+
ASSERT(ARM_DRIVER_OK == 0); // this is a precondition; it doesn't need to be put in code
+
+
int32_t returnValue = drv->asynchronousAPI(...);
+
+
if (returnValue < ARM_DRIVER_OK) {
+
// handle error.
+
+
} else if (returnValue == ARM_DRIVER_OK) {
+
ASSERT(drv->GetCapabilities().asynchronous_ops == 1);
+
// handle early return from asynchronous execution; remainder of the work is done in the callback handler.
+
+
} else {
+
ASSERT(returnValue == EXPECTED_RETURN_VALUE_FOR_SYNCHRONOUS_COMPLETION);
+
// handle synchronous completion.
+
}
+

THis example is mixing synchronous and asynchronous APIs: Sample Use of Storage Driver

+
+
+ + + + -- cgit