4 Usage Recommendation of Asynchronous and Synchronous Drivers

Synchronous drivers are suitable for use in an RTOS environment, whereas Asynchronous drivers are suitable in a Bare-metal environment.

Asynchronous drivers (Non-Blocking API) are suitable for an application which runs in a Bare-metal or non-RTOS based environment. In a Bare-metal environment, the suggested way to implement an application is by implementing the state machine programming model. In a state machine programming model, an application avoids busy waiting loops so as to not waste CPU bandwidth. Therefore, the module’s functions must not block waiting for an external operation to complete (especially on anything that has any possibility of never completing) or it may block the entire system. If the function must wait for an external operation, the module must break up the operation into smaller tasks to be performed later. The multiple smaller tasks run in the super loop. The task running in the super loop includes application tasks and driver tasks. The application task checks the completion of the driver operations through status flags.

MPLAB Harmony v3 drivers running in Asynchronous mode provide the ability to acquire the driver task completion status through the implementation of Asynchronous callback events (as discussed in Callback Functions) that the application registers with the driver. In addition to the callback mechanism the MPLAB Harmony v3 drivers running in Asynchronous mode provide status functions for the application task to check the driver task completion status. For example, the SPI driver provides the status check API, DRV_SPI_TransferStatusGet().

Synchronous driver (Blocking API) is suitable in an RTOS-based application environment. In an RTOS-based application environment, the blocking interface is acceptable and desirable. When the Synchronous driver API in a thread blocks waiting for the completion of a task (for example, the I²C driver API, DRV_I2C_WriteTransfer(), blocks for the transfer of bytes), the RTOS scheduler ensures that the thread in contention does not block the control flow indefinitely. The RTOS, particularly with preemptive scheduling, ensures that the next high-priority thread runs immediately when the current thread has blocked. Refer to the Interrupt Safety, Thread Safety, Synchronization and Blocking API for additional information on blocking behavior and the implementation using MPLAB Harmony v3 Synchronous drivers.