Some of the drivers in ASF4 have RTOS support. RTOS support is selected as a use case in Atmel START.
Drivers designed for use in RTOSes are designed differently to take advantage of RTOS features. For example, drivers do not need to poll a signal or status, the RTOS provides synchronization mechanisms to notify the driver, releasing CPU resources for other tasks.
Semaphore
Semaphores are used as synchronization mechanism in the drivers since all RTOSes have them. Their behavior and interface are similar, making it easy to support various RTOSes. A typical process of using an RTOS driver looks like this:
The driver has an internal semaphore object for synchronizing between the ISR and the thread. The user thread may be suspended in the driver, and be woken up once the ISR finishes.
To be compatible with various RTOSes, an abstraction interface for semaphores is designed:
int32_t sem_init(sem_t *sem, uint32_t count); int32_t sem_up(sem_t *sem); int32_t sem_down(sem_t *sem, uint32_t timeout); int32_t sem_deinit(sem_t *sem);
To support an RTOS, these functions and the sem_t typedef must be implemented.
OS lock and OS sleep
These two features are useful and are added to the RTOS abstraction. The OS locks/unlocks and disables/enables the OS scheduler and is an easy way to protect shared code and data among threads. OS sleep suspends the current thread for a specified tick period.
Thread creation
ASF4 does not provide an abstract interface for thread creation. For pre-defined threads in middleware, the thread body function and thread stack usage size are provided to the user, allowing the user to easily create such threads in his application.
HAL and HPL
Since HPL is designed for hardware abstraction, while HAL contains software and algorithms, RTOS support is located in the HAL layer. RTOS-enabled drivers do not change the HPL layer. The figure below shows how these two layers work together in an RTOS.
