Zephyr Software Requirements
SPDX-License-Identifier: Apache-2.0
1. Hardware Architecture Interface
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall provide an interface functionality to access memory while ensuring mutual exclusion. Note: Implementation by atomic variables and accessing them by APIs.
As a Zephyr RTOS user I want to read from or write into a memory areas without being disturbed by other threads or ISRs.
The Zephyr RTOS shall provide a mechanism for context switching between threads.
As a Zephyr RTOS user I want to execute code concurrently in one or more threads and when interrupted at a code location in a thread, to continue at the very same location.
The Zephyr RTOS shall provide an interface to implement software exceptions.
As a Zephyr RTOS user I want to catch any software exception and handle it according to my application needs.
The Zephyr RTOS shall provide an interface for managing processor modes.
If MCU power state was meant here: As a Zephyr RTOS user I want to control the MCU's power saving mode such e.g. operation, sleep, deep sleep or similar as supported by the selected MCU.
2. C library
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall support formatted output.
As a Zephyr RTOS user, I want to be able to printf with various output formats.
The Zephyr RTOS shall support floating point math libraries for processors where floating point is available.
As a Zephyr RTOS user, I want to be able to calculate with floating point numbers.
The Zephyr RTOS shall support boolean primitives.
As a Zephyr RTOS user, I want to be able to work with boolean values and logic.
The Zephyr RTOS shall support the standard UNIX time interface.
As a Zephyr User, I want to be able to use system time.
The Zephyr RTOS shall support an interface to manage strings.
As a Zephyr RTOS user, I want to be able to manipulate text strings.
The Zephyr RTOS shall support an interface to move contents between regions of memory.
As a Zephyr RTOS user, I want to copy the memory contents to different addresses.
The Zephyr RTOS shall support a file i/O based interface for driver communication.
As a Zephyr RTOS user, I want to be able to use File I/O functions.
The Zephyr RTOS shall support standard C99 integer types.
As a Zephyr RTOS user, I want to be able to calculate with C99 Integers.
The Zephyr RTOS shall support standard system error numbers as defined by IEEE Std 1003.1-2017.
As a Zephyr RTOS user, I want to be able to use IEE Std 1003.1-2017 Error Numbers for Interoperability.
The set of C Library functions required by Zephyr needs to be documented in the Zephyr Safety Manual.
As a Zephyr user, I want to know which C library functions are being called by the Zephyr OS safety scope code.
The Zephyr Safety Manual needs to specify how to configure the support of external C Libraries.
As a Zephyr User, I need to understand how to configure the external C libraries to align with the validation that has been performed.
3. Device Driver API
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall provide abstraction of device drivers with common functionalities as an intermediate interface between applications and device drivers, where such interface is implemented by individual device drivers.
Proposal for replacement: Zephyr shall provide an interface between application and individual device drivers to provide an abstraction of device drivers with common functionalities.
The Zephyr RTOS shall provide an interface for managing a defined set of hardware exceptions (including interrupts) across all systems.
As a Zephyr RTOS user I want hardware exceptions (hardware failures, programming mistakes) to be handled gracefully (no program crashes as far as possible).
4. Exception and Error Handling
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall provide default handlers for exceptions.
As a Zephyr RTOS user I want exceptions which I did not handle explicitly (by mistake or on purpose) to be caught by a default handler, defined either by Zephyr OS or by myself.
The Zephyr RTOS shall provide default handlers for fatal errors that do not have a dedicated handler.
The Zephyr RTOS shall provide an interface to assign a specific handler with an exception.
The Zephyr RTOS shall provide an interface to assign a specific handler for a fatal error.
5. System Initialization
SPDX-License-Identifier: Apache-2.0
TBD
6. File system
SPDX-License-Identifier: Apache-2.0
Zephyr shall provide file create capabilities for files on the file system.
As a Zephyr OS user I want to be able to create a new file or overwrite an existing file at the same filesystem location / identifier (e.g. path + name).
Zephyr shall provide file open capabilities for files on the file system.
As a Zephyr OS user I want to be able to open a file for writing or reading. When opened for writing, I want to have exclusive access to the file.
Zephyr shall provide read access to files in the file system.
As a Zephyr OS user I want to be able to read from an existing file, also while the file is read from multiple and write accessed from one other instances.
Zephyr shall provide write access to the files in the file system.
As a Zephyr OS user I want to be able to write to a file either from the beginning of the file or appending at the end.
Zephyr shall provide file close capabilities for files on the file system.
As a Zephyr OS user I want to be able to close a file after being finished with my file operations, unlocking any access restrictions.
Zephyr shall provide the capability to move files on the file system.
Zephyr shall provide file delete capabilities for files on the file system.
As a Zephyr OS user I want to be able to delete an existing file.
7. Interrupts
SPDX-License-Identifier: Apache-2.0
Zephyr RTOS shall provide a mechanism to initialize a static IRQ service routine (ISR), providing all parameters needed to configure the hardware and software.
The static IRQ shall be initially disabled.
Zephyr RTOS shall provide a mechanism to initialize a direct IRQ handler, providing all parameters needed to configure the hardware and software.
As the developer of low-power and low-latency applications, I need to implement ISRs that avoid the normal interrupt and power management overhead.
The direct IRQ shall be initially disabled.
Zephyr RTOS shall provide a mechanism to initialize a dynamic IRQ service routine, providing all parameters needed to configure the hardware and software.
The dynamic IRQ shall be initially disabled.
Zephyr RTOS shall provide a mechanism to uninstall a dynamic ISR.
Zephyr RTOS shall provide a mechanism to Disable all IRQs on a CPU, and return the state the IRQ hardware prior to being disabled.
Zephyr RTOS shall provide a mechanism to Enable all IRQs on a CPU and return them to thier previous state.
Zephyr RTOS shall provide a mechanism to Disable a specified IRQ.
Zephyr RTOS shall provide a mechanism to Enable a specified IRQ.
Zephyr RTOS shall provide mechanisms that returns the Enabled status of a specified IRQ, where the status is Enabled or Disabled.
Zephyr RTOS shall provide mechanisms that returns the execution context, where the context is In-ISR or Not In-ISR.
As the developer of functions that may run in either ISR or THREAD context, I need to know the current context to enable condition behavior.
The Zephyr RTOS shall support multi-level preemptive interrupt priorities, when supported by hardware.
8. Logging
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall support isolation of logging from other functionality.
As a Zephyr RTOS user I want to be able to configure logging of events so the execution of logging activities does have no or only a minimal impact to the timing behaviour of my application.
The Zephyr RTOS logging shall produce logs that are capable of being post processed.
As a Zephyr RTOS user I want the logging information to be stored in a format which allows to be read possibly converted or displayed by COTS tools.
The Zephyr RTOS logging shall support formatting of log messages to enable filtering.
As a Zephyr RTOS user I want to be able my application to format texts (printf alike) into the log message.
The Zephyr RTOS logging system shall support filtering based on severity level.
As a Zephyr RTOS user I want to be able to distinguish between different severity level for my log messages (e.g. DEBUG, INFO, WARN, ERROR, PANIC).
The Zephyr RTOS shall support logging messages to multiple system resources.
As a Zephyr RTOS user I want to be able to simultaneously log to different channels which may store / redirect the information on / to different hardware (EEPROM, Flash, FRAM, UART, Ethernet, USB etc.).
The Zephyr RTOS shall support deferred logging (TODO: need more detail about the constraints and limits on what can be deferred).
As a Zephyr RTOS user I want a minimal influence of logging activities to the timing behaviour of my application. Time consuming logging threads shall be done in the background.
9. Memory protection
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall support memory protection features to isolate a thread's memory region.
As a Zephyr RTOS user I want memory to be allocated and protected to my application threads preventing mistakenly access to foreign memory as far as the hardware allows.
The Zephyr RTOS shall provide a mechanism to grant user threads access to kernel objects.
As a Zephyr RTOS user I want, from the user space, under certain conditions, access to kernel objects.
The Zephyr RTOS shall be able to differentiate between user threads and kernel threads for memory access.
As a Zephyr RTOS user I want, from the kernel space, unconditioned access to kernel objects.
The Zephyr RTOS shall have a defined behaviour when an invocation of an unimplemented system call is made.
As a Zephyr RTOS user I want Zephyr OS to indicate any unimplemented system call by an appropriate error message.
The Zephyr RTOS shall have a defined behaviour when an invalid system call ID is used.
As a Zephyr RTOS user I want Zephyr OS to indicate invalid system call by an appropriate error message.
The Zephyr RTOS shall prevent user threads from creating new threads that are higher priority than the caller.
The Zephyr RTOS shall support revoking permission to a kernel object. User mode threads may only revoke their own access to an object.
As a Zephyr RTOS user I want to be protected against other user threads changing access to kernel objects of my thread.
The Zephyr RTOS shall prevent user threads from creating kernel threads.
As a Zephyr RTOS user I want to be protected against user threads creating higher privileged kernel/supervisor threads.
The Zephyr RTOS shall allow the creation of threads that run in reduced privilege level.
As a Zephyr RTOS user I want to be able to create lower privileged threads than my own.
The Zephyr RTOS shall provide system calls to allow user mode threads to perform privileged operations.
As a Zephyr RTOS user I want to be able to perform privileged operations in the kernel mode through a well defined interface.
The Zephyr RTOS shall support a defined mechanism for user mode handling a of detected stack overflow.
As a Zephyr RTOS user I want, when a stack overflow is detected, to be able to implement a graceful, application defined handling of the exception.
The Zephyr RTOS shall support detection of stack overflows.
As a Zephyr RTOS user I want to get an indication when a stack overflow occurs at least during debugging / the development phase, and for safety applications also in a release version of my application.
The Zephyr RTOS shall support configurable access to memory during boot time.
The Zephyr RTOS shall provide helper functions for system call handler functions to validate the inputs passed in from user mode before invoking the implementation function to protect the kernel.
As a Zephyr RTOS user I want Zepyhr OS to validate system call parameters passed from the user mode to the kernel mode to avoid crashes and undefined behaviour.
The Zephyr RTOS shall support system calls to be able to safely accept C strings passed in from user mode.
As a Zephyr RTOS user I want Zepyhr OS to validate system call string type parameters passed from the user mode to the kernel mode to avoid crashes and undefined behaviour.
e.g.
- verify the string length is smaller or equal to the syscalls defined max.
- verify that the length type does not overflow when allocating one more byte ???
The Zephyr RTOS shall track kernel objects that are used by user mode threads.
Note: this means Zephyr shall track the resources used by the user mode thread (associate this with a user story).
The Zephyr RTOS shall have an interface to request access to specific memory after initial allocation.
As a Zephyr RTOS user I want to be able to request read-only or read-write access to a dedicated memory area/pool during runtime.
The Zephyr RTOS shall support assigning a memory pool to act as that thread's resource pool.
As a Zephyr RTOS user I want to be able, during runtime from the kernel, to request a memory area/pool which is exclusively available to the requesting thread protected against access from other threads.
10. Memory Objects
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall allow threads to dynamically allocate variable-sized memory regions from a specified range of memory.
As a Zephyr RTOS user I want my application to be able to dynamically allocate memory of a application defined size.
The Zephyr RTOS shall allow threads to dynamically allocate fixed-sized memory regions from a specified range of memory.
As a Zephyr RTOS user I want a most efficient and least fragmentation prone dynamic memory allocation mechanism.
11. Data Passing
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall provide a kernel object that implements a traditional first in, first out (FIFO) queue, allowing threads and ISRs to add and remove a limited number of 32-bit data values.
As a Zephyr RTOS user I want to be able to exchange 1 to N data objects between different threads and ISR in a thread-safe manner with a first-in-first-out (queue) behaviour.
The Zephyr RTOS shall provide a kernel object that implements a traditional last in, first out (LIFO) queue, allowing threads and ISRs to add and remove a limited number of 32-bit data values.
As a Zephyr RTOS user I want to be able to exchange 1 to N data objects between different threads and ISR in a thread-safe manner with a last-in-first-out (stack) behaviour.
12. Mutex
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall support resource synchronization. (Note synchronization can be for memory access, and mutex may be one implementation, but not the only one).
As a Zephyr RTOS user I want to be able to sychonize threads when accessing common resources, where the thread shall have the option to: - wait eternally until the resources becomes available. - immediately return with a negative message if the resource is not available and allow the thread to continue. - wait for a given time for the resource to become available or return with a negative message.
13. Semaphores
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall provide a mechanism to define and initialize a semaphore at compile time.
The Zephyr RTOS shall provide a mechanism to define and initialize a semaphore at runtime.
The Zephyr RTOS shall define the maximum limit of a semaphore when the semaphore is used for counting purposes and does not have an explicit limit.
When initializing a counting semaphore, the maximum permitted count a semaphore can have shall be set.
When initializing a counting semaphore, the initial semaphore value shall be set.
The Zephyr RTOS shall provide a mechanism allowing threads to acquire a semaphore.
While the semaphore's count is greater than zero, the requesting thread shall acquire the semaphore and decrement its count.
While the semaphore's count is zero, the requesting thread shall be blocked until the semaphore is released by another thread.
When attempting to acquire a semaphore, the Zephyr RTOS shall accept options that specify timeout periods, allowing threads to set a maximum wait time for semaphore acquisition.
When attempting to acquire a semaphore, where the semaphore is not acquired within the specified time, the Zephyr RTOS shall return an error indicating a timeout.
When attempting to acquire a semaphore, where the current count is zero and no timeout time was provided, the Zephyr RTOS shall return an error indicating the semaphore is busy.
The Zephyr RTOS shall provide a mechanism allowing threads to release a semaphore.
The Zephyr RTOS shall increment the semaphore's count upon release.
When there are threads waiting on the semaphore, the highest-priority waiting thread shall be unblocked and acquire the semaphore.
The Zephyr RTOS shall provide a mechanism for threads to check the current count of a semaphore without acquiring it.
The Zephyr RTOS shall provide a mechanism that resets the semaphore count to zero.
When a semaphore is reset, the Zephyr RTOS shall abort all existing acquisitions of the semaphore returning a resource contention error code.
When initializing a counting semaphore, where the maximum permitted count of a semaphore is invalid, then the Zephyr RTOS shall return an error indicating invalid values.
14. Power Management
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall provide control over changes to system power states.
See ZEP104 + When the power state is changed I want to get an notification in order for specific parts of my application to react accordingly.
TBD
The Zephyr RTOS shall provide notification of changes to system power states.
15. Thread Communication
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall provide a mechanism for exchanging data between threads.
(Note: copying data may be needed here - what is Zephyr doing? is it configurable?)
The Zephyr RTOS shall provide mechanisms to enable waiting for results during communication between threads. (NOTE: waiting for results is really bad and dangerous, want to avoid if at all possible).
=N73
The Zephyr RTOS shall support a poll operation which enables waiting concurrently for any one of multiple conditions to be fulfilled.
As a Zephyr RTOS user I want my thread to wait for one of several defined events to occur and only continue when one of them has occurred.
The Zephyr RTOS shall provide a communication primitive that allows a thread to transfer a block of data to another thread.
As a Zephyr RTOS user I want to send a byte stream from one thread to another in a thread-safe manner.
The Zephyr RTOS shall provide a a communication primitive that allow threads and ISRs to asynchronously exchange fixed-size data items.
The Zephyr RTOS shall provide a communication primitive that allows threads to exchange messages of varying sizes asynchronously or synchronously.
As a Zephyr RTOS user I want a sending thread to deposit a message into the mailbox, and a receiving thread to be able to retrieve the message at its convenience. This allows for asynchronous communication, where threads do not need to synchronize their execution explicitly.
16. Thread Scheduling
SPDX-License-Identifier: Apache-2.0
16.1. Thread Scheduling
The Zephyr RTOS shall support operation on more than one physical CPU sharing the same kernel state.
The Zephyr RTOS shall provide an interface for running threads on specific sets of CPUs ( default is 1 CPU).
As a Zephyr RTOS user I want Zephyr OS to be able to specify the CPU core or the set of CPU cores on which a thread shall be executed.
The Zephyr RTOS shall provide an interface for mutual exclusion between multiple physical CPUs.
As a Zephyr RTOS user I want Zephyr OS to provide synchronization mechanisms between the CPU cores and the access to common resources.
16.2. Thread Scheduling
The Zephyr RTOS shall provide an interface to schedule a thread based on an event.
As a Zephyr RTOS user, I want to be able to execute work which reacts on events and interrupts the current executed work.
The Zephyr RTOS shall organize running threads by earliest deadline first priority.
As a Zephyr RTOS user, I want to be able to schedule threads by earliest deadline first.
The Zephyr RTOS shall provide a thread-pooled work queue utility capable of running preemptible work items with specific scheduler priorities.
As a Zephyr RTOS user, I want to be able to add work items in a thread work queue with different priorities and these shall be scheduled according their priorities.
The Zephyr RTOS shall provide an interface for running user-supplied functions.
As a Zephyr RTOS user, I want to be able to run functions in-order in a separated thread/threads.
The Zephyr RTOS shall organize running threads into a fixed list of numeric priorities.
As a Zephyr RTOS user, I want that the OS organize running threads in a fixed list of numeric priorities.
The Zephyr RTOS shall support preemption of a running thread by a higher priority thread.
As a Zephyr RTOS user, I want that the OS preempt running threads by a thread with higher priority.
The Zephyr RTOS shall support thread priorities which cannot be preempted by other user threads.
As a Zephyr RTOS user, I want to be able to configure thread prioritizes which cannot be preempted by other user threads.
The Zephyr RTOS shall support time sharing of CPU resources among threads of the same priority.
As a Zephyr RTOS user, I want to be able to configure my RTOS in the way, that the CPU resources are shared evenly among executed threads of the same priority.
17. Threads
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall provide an interface to create (start) a thread.
The Zephyr RTOS shall provide an interface to set a thread's priority.
The Zephyr RTOS shall provide an interface to suspend a thread.
The Zephyr RTOS shall provide an interface to resume a suspended thread.
The Zephyr RTOS shall provide an interface to resume a suspended thread after a timeout.
The Zephyr RTOS shall provide an interface to delete (end) a thread.
Threads shall have different states to fulfill the Life-cycle of a thread
As a Zephyr RTOS user, I want to know in what state a specific thread is.
Every Thread shall have it's own stack.
As a Zephyr RTOS user I want to be able to configure the stack size of a thread. And every thread shall have it's own dedicated stack.
The Zephyr RTOS shall provide an interface to create threads with defined privilege.
The Zephyr RTOS shall provide an interface to schedule multiple threads.
The Zephyr RTOS shall support a set of thread options.
As a Zephyr RTOS user, I want to be able to pass specific option to a thread.
Every thread shall have a custom data area.
As a Zephyr RTOS user, I want to be able to set a thread specific custom area for every thread I create and which can be used only by the thread itself or the can be used by the application
18. Timers
SPDX-License-Identifier: Apache-2.0
The Zephyr RTOS shall provide a mechanism to define and statically (i.e. compile time) initialize timers.
When initializing a timer, the Zephyr RTOS shall support setting a function that gets called when the timer expires.
When initializing a timer, the Zephyr RTOS shall support setting a function that gets called when a running timer is stopped.
The Zephyr RTOS shall provide a mechanism to define and initialize timers at run time.
The Zephyr RTOS shall provide a mechanism to start a timer for a specific duration and periodicity.
The Zephyr RTOS shall provide a mechanism to stop a running timer.
The Zephyr RTOS shall provide a mechanism to read the number of times a timer has expired and then reset this number to 0.
When a timer is initialized, started or synchronized to a thread, the Zephyr RTOS shall reset the timer number of times it has expired to 0.
The Zephyr RTOS shall provide a mechanism to synchronize a thread to a timer and then block the thread execution until any of the following conditions is satisfied: - The timer is stopped - The timer number of times it has expired is superior to 0
The Zephyr RTOS shall provide a mechanism to get a timer's next expiration time in system ticks.
The Zephyr RTOS shall provide a mechanism to get a timer's remaining time until its next expiry in system ticks.
The Zephyr RTOS shall provide a mechanism to get the timer's remaining time until its next expiry in milliseconds.
The Zephyr RTOS shall support adding user defined data to a timer.
The Zephyr RTOS shall support retrieving user defined data from a timer.
When a timer expiry function is called, the Zephyr RTOS shall do so in the interrupt context.
19. Tracing
SPDX-License-Identifier: Apache-2.0
Zephyr shall provide an interface to initialize a trace.
Zephyr shall provide an interface to trigger a trace.
Zephyr shall provide an interface to dump results from a trace.
Zephyr shall provide an interface to remove trace data.
Zephyr shall provide an interface to identify the objects being traced.
As a Zepyhr OS user, I want to be able to give each object which I create a name / label in order to be able to identify them in a trace log.
Zepyhr shall prevent the tracing functionality from interfering with normal operations.
As a Zepyhr OS user, I want that the trace functionality do not interfere or slow down the operation system functionality.
20. Condition Variables
The Zephyr RTOS shall provide a mechanism to define and initialize a condition variable dynamically (at runtime).
The Zephyr RTOS shall provide a mechanism to define and initialize a condition variable statically (at compile time).
The Zephyr RTOS shall provide a mechanism to signal the highest priorite waiting thread when a condition is met.
The Zephyr RTOS shall provide a mechanism to signal all waiting threads when a condition is met.
The Zephyr RTOS shall provide a mechanism for a thread to wait on a condition variable.
When waiting on a condition variable, the thread shall specify a timeout value.
When a timeout occurs while waiting on a condition variable, the thread shall be unblocked and a timeout error shall be returned.
If a thread is waiting on a condition variable, the thread shall release the current owned mutex independently.
henever some thread signals a condition variable the Zephyr RTOS shall unblock the highest priority thread currently waiting for this condition variable.
21. Tracing
The Zephyr RTOS shall provide a mechanism to define and initialize a queue at compile time.
The Zephyr RTOS shall provide a mechanism to define and initialize a queue at run time.
The Zephyr RTOS shall provide a mechanism to enqueue a data item to the back of a queue (i.e. append).
The Zephyr RTOS shall provide a mechanism to enqueue a data item to the front of a queue (i.e. prepend).
The Zephyr RTOS shall provide a mechanism to remove a specific data item from a queue.
The Zephyr RTOS shall provide a mechanism to get and dequeue a data item from the front of a queue, within a timeout.
The Zephyr RTOS shall provide a mechanism to check if a queue is empty.
The Zephyr RTOS shall provide a mechanism to peek at the data data item at the back of a queue.
The Zephyr RTOS shall provide a mechanism to peek at the data data item at the front of a queue.
The Zephyr RTOS shall provide a mechanism to insert a data item behind another specific data item in a queue.
The Zephyr RTOS shall provide a mechanism to append a list of data items to the back of a queue.
The Zephyr RTOS shall provide a mechanism to append a list of data items to the back of a queue and then empty the list.
The Zephyr RTOS shall provide a mechanism to append a data item uniquely to the queue.
The Zephyr RTOS shall provide a dedicated mechanism to implicite allocate memory from a thread when appending data items to a queue.
22. Tracing
The Zephyr RTOS shall provide a mechanism to define and initialize a LIFO at compile time.
The Zephyr RTOS shall provide a mechanism to enqueue a data item to the back of a LIFO (i.e. prepend).
The Zephyr RTOS shall provide a mechanism to allocate memory from a thread when enqueuing data items to a LIFO.
The Zephyr RTOS shall provide a mechanism to get and dequeue a data item from the back of a LIFO, within a timeout.
The Zephyr RTOS shall provide a mechanism to define and initialize a LIFO at compile time.
23. Tracing
The Zephyr RTOS shall provide a mechanism to define and initialize a FIFO at compile time.
The Zephyr RTOS shall provide a mechanism for the first thread waiting to get and dequeue a data item to return as if the timeout had expired.
The Zephyr RTOS shall provide a mechanism to enqueue a data item to the back of a FIFO (i.e. append).
The Zephyr RTOS shall provide a mechanism to allocate memory from a thread when enqueuing data items to a FIFO.
The Zephyr RTOS shall provide a mechanism to append a list of data items to the back of a FIFO.
The Zephyr RTOS shall provide a mechanism to append a list of data items to the back of a FIFO and then empty the list.
The Zephyr RTOS shall provide a mechanism to get and dequeue a data item from the front of a FIFO, within a timeout.
The Zephyr RTOS shall provide a mechanism to check if a FIFO is empty.
The Zephyr RTOS shall provide a mechanism to peek at the data data item at the front of a FIFO.
The Zephyr RTOS shall provide a mechanism to peek at the data item at the back of a FIFO.
The Zephyr RTOS shall provide a mechanism to define and initialize a FIFO at compile time.