Hal

Analogin hal structure.

analogin_s is declared in the target's hal

Definition at line 32 of file analogin_api.h.

This is the set of operations constituting the Storage driver.

Their implementation is platform-specific, and needs to be supplied by the porting effort.

Some APIs within `ARM_DRIVER_STORAGE` will always operate synchronously: GetVersion, GetCapabilities, GetStatus, GetInfo, ResolveAddress, GetNextBlock, and GetBlock. 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: Initialize, Uninitialize, PowerControl, ReadData, ProgramData, Erase, EraseAll, can function asynchronously if the underlying controller supports it--i.e. 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.
     }

Driver Version.

General power states.

A storage block is a range of memory with uniform attributes.

Storage blocks combine to make up the address map of a storage controller.

Attributes of the storage range within a storage block.

Declaration of the callback-type for command completion.

Parameters:

[in]	status	A code to indicate the status of the completed operation. For data transfer operations, the status field is overloaded in case of success to return the count of items successfully transferred; this can be done safely because error codes are negative values.
[in]	operation	The command op-code. This value isn't essential for the callback in the presence of the command instance-id, but it is expected that this information could be a quick and useful filter.

Definition at line 240 of file Driver_Storage.h.

Storage Driver API Capabilities.

This data structure is designed to fit within a single word so that it can be fetched cheaply using a call to driver->GetCapabilities().

Storage information.

This contains device-metadata. It is the return value from calling GetInfo() on the storage driver.

These fields serve a different purpose than the ones contained in ARM_STORAGE_CAPABILITIES, which is another structure containing device-level metadata. ARM_STORAGE_CAPABILITIES describes the API capabilities, whereas ARM_STORAGE_INFO describes the device. Furthermore ARM_STORAGE_CAPABILITIES fits within a single word, and is designed to be passed around by value; ARM_STORAGE_INFO, on the other hand, contains metadata which doesn't fit into a single word and requires the use of pointers to be moved around.

Command opcodes for Storage.

Completion callbacks use these codes to refer to completing commands. Refer to ARM_Storage_Callback_t.

Device Data Security Protection Features.

Applicable mostly to EXTERNAL_NVM.

Operating status of the storage controller.

Generic buffer structure.

Analogout hal structure.

dac_s is declared in the target's hal

Definition at line 32 of file analogout_api.h.

GPIO IRQ HAL structure.

gpio_irq_s is declared in the target's HAL

Definition at line 40 of file gpio_irq_api.h.

Non-asynch I2C HAL structure.

Definition at line 56 of file i2c_api.h.

Port HAL structure.

port_s is declared in the target's HAL

Definition at line 32 of file port_api.h.

Pwmout hal structure.

pwmout_s is declared in the target's hal

Definition at line 32 of file pwmout_api.h.

Non-asynch serial HAL structure.

Definition at line 99 of file serial_api.h.

Non-asynch SPI HAL structure.

Definition at line 49 of file spi_api.h.

Ticker's event structure.

TRNG HAL structure.

trng_s is declared in the target's HAL

Definition at line 29 of file trng_api.h.

General power states.

Enumerator:

ARM_POWER_OFF	Power off: no operation possible.
ARM_POWER_LOW	Low Power mode: retain state, detect and signal wake-up events.
ARM_POWER_FULL	Power on: full operation at maximum performance.

Definition at line 50 of file Driver_Common.h.

Command opcodes for Storage.

Completion callbacks use these codes to refer to completing commands. Refer to ARM_Storage_Callback_t.

Definition at line 209 of file Driver_Storage.h.

GPIO IRQ events.

Definition at line 32 of file gpio_irq_api.h.

Send the microcontroller to deep sleep.

This processor is setup ready for deep sleep, and sent to sleep using __WFI(). This mode has the same sleep features as sleep plus it powers down peripherals and clocks. All state is still maintained.

The processor can only be woken up by an external interrupt on a pin or a watchdog timer.

Note:

The mbed interface semihosting is disconnected as part of going to sleep, and can not be restored. Flash re-programming and the USB serial port will remain active, but the mbed program will no longer be able to access the LocalFileSystem

Send the microcontroller to sleep.

The processor is setup ready for sleep, and sent to sleep using __WFI(). In this mode, the system clock to the core is stopped until a reset or an interrupt occurs. This eliminates dynamic power used by the processor, memory systems and buses. The processor, peripheral and memory state are maintained, and the peripherals continue to work and can generate interrupts.

The processor can be woken up by any internal peripheral interrupt or external pin interrupt.

Note:

The mbed interface semihosting is disconnected as part of going to sleep, and can not be restored. Flash re-programming and the USB serial port will remain active, but the mbed program will no longer be able to access the LocalFileSystem