Zephyr Software Requirements
ZEP-SRS-19-1: Atomic Operations
The Zephyr RTOS shall provide an interface to access memory while ensuring mutual exclusion.
- Status:
Draft
- Type:
Functional
- Component:
Hardware Architecture Interface
- User Story:
As a Zephyr RTOS user I want to read from or write into a memory areas without being disturbed by other threads or ISRs.
- Parents:
ZEP-SRS-19-2: Thread Context Switching
The Zephyr RTOS shall provide a mechanism for context switching between threads.
- Status:
Draft
- Type:
Functional
- Component:
Hardware Architecture Interface
- User Story:
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.
- Parents:
ZEP-SRS-19-3: Software Exceptions
The Zephyr RTOS shall provide an interface to implement software exceptions.
- Status:
Draft
- Type:
Functional
- Component:
Hardware Architecture Interface
- User Story:
As a Zephyr RTOS user I want to catch any software exception and handle it according to my application needs.
- Parents:
ZEP-SRS-19-4: Processor Mode Support
The Zephyr RTOS shall provide an interface for managing processor modes.
- Status:
Draft
- Type:
Functional
- Component:
Hardware Architecture Interface
- User Story:
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.
- Parents:
ZEP-SRS-18-1: Formatted output
The Zephyr RTOS shall support formatted output.
- Status:
Draft
- Type:
Functional
- Component:
C Library
- User Story:
As a Zephyr RTOS user, I want to be able to printf with various output formats.
- Parents:
ZEP-SRS-18-2: Floating Point Math Support
The Zephyr RTOS shall support floating point math libraries for processors where floating point is available.
- Status:
Draft
- Type:
Functional
- Component:
C Library
- User Story:
As a Zephyr RTOS user, I want to be able to calculate with floating point numbers.
- Parents:
ZEP-SRS-18-3: Boolean Primitives Support
The Zephyr RTOS shall support boolean primitives.
- Status:
Draft
- Type:
Functional
- Component:
C Library
- User Story:
As a Zephyr RTOS user, I want to be able to work with boolean values and logic.
- Parents:
ZEP-SRS-18-4: Standard Unix time interface
The Zephyr RTOS shall support the standard UNIX time interface.
- Status:
Draft
- Type:
Functional
- Component:
C Library
- User Story:
As a Zephyr User, I want to be able to use system time.
- Parents:
ZEP-SRS-18-5: Strings support
The Zephyr RTOS shall support an interface to manage strings.
- Status:
Draft
- Type:
Functional
- Component:
C Library
- User Story:
As a Zephyr RTOS user, I want to be able to manipulate text strings.
- Parents:
ZEP-SRS-18-6: Moving/copying regions of memory
The Zephyr RTOS shall support an interface to move contents between regions of memory.
- Status:
Draft
- Type:
Functional
- Component:
C Library
- User Story:
As a Zephyr RTOS user, I want to copy the memory contents to different addresses.
- Parents:
ZEP-SRS-18-7: I/O based interface
The Zephyr RTOS shall support a file I/O based interface for driver communication.
- Status:
Draft
- Type:
Functional
- Component:
C Library
- User Story:
As a Zephyr RTOS user, I want to be able to use File I/O functions.
- Parents:
ZEP-SRS-18-8: C99 integer types
The Zephyr RTOS shall support standard C99 integer types.
- Status:
Draft
- Type:
Functional
- Component:
C Library
- User Story:
As a Zephyr RTOS user, I want to be able to calculate with C99 Integers.
- Parents:
ZEP-SRS-18-9: Standard System Error Numbers (IEEE Std 1003.1-2017)
The Zephyr RTOS shall support standard system error numbers as defined by IEEE Std 1003.1-2017.
- Status:
Draft
- Type:
Functional
- Component:
C Library
- User Story:
As a Zephyr RTOS user, I want to be able to use IEE Std 1003.1-2017 Error Numbers for Interoperability.
- Parents:
ZEP-SRS-18-10: Document set of Zephyr OS required C library functions in Safety Manual
The set of C Library functions required by Zephyr shall be documented in the Zephyr Safety Manual.
- Status:
Draft
- Type:
Functional
- Component:
C Library
- User Story:
As a Zephyr user, I want to know which C library functions are being called by the Zephyr OS safety scope code.
- Parents:
ZEP-SRS-18-11: Support external C libraries documentation in Zephyr Safety Manual
The Zephyr Safety Manual shall specify how to configure the support of external C Libraries.
- Status:
Draft
- Type:
Functional
- Component:
C Library
- User Story:
As a Zephyr User, I need to understand how to configure the external C libraries to align with the validation that has been performed.
- Parents:
ZEP-SRS-14-1: Device Driver Abstraction
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.
- Status:
Draft
- Type:
Functional
- Component:
Device Driver API
- Parents:
ZEP-SRS-14-2: Expose kernel to hardware interrupts
The Zephyr RTOS shall provide an interface for managing a defined set of hardware exceptions (including interrupts) across all systems.
- Status:
Draft
- Type:
Functional
- Component:
Device Driver API
- User Story:
As a Zephyr RTOS user I want hardware exceptions (hardware failures, programming mistakes) to be handled gracefully (no program crashes as far as possible).
- Parents:
ZEP-SRS-16-1: Fatal Exception Error Handler
The Zephyr RTOS shall provide default handlers for exceptions.
- Status:
Draft
- Type:
Functional
- Component:
Exception and Error Handling
- User Story:
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.
- Parents:
ZEP-SRS-16-2: Default handler for fatal errors
The Zephyr RTOS shall provide default handlers for fatal errors that do not have a dedicated handler.
- Status:
Draft
- Type:
Functional
- Component:
Exception and Error Handling
- Parents:
ZEP-SRS-16-3: Assigning a specific handler
The Zephyr RTOS shall provide an interface to assign a specific handler for an exception.
- Status:
Draft
- Type:
Functional
- Component:
Exception and Error Handling
- Parents:
ZEP-SRS-16-4: Assigning a specific handler for a fatal error
The Zephyr RTOS shall provide an interface to assign a specific handler for a fatal error.
- Status:
Draft
- Type:
Functional
- Component:
Exception and Error Handling
- Parents:
ZEP-SRS-17-1: Create file
Zephyr shall provide file create capabilities for files on the file system.
- Status:
Draft
- Type:
Functional
- Component:
File System
- User Story:
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).
- Parents:
ZEP-SRS-17-2: Open files
Zephyr shall provide file open capabilities for files on the file system.
- Status:
Draft
- Type:
Functional
- Component:
File System
- User Story:
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.
- Parents:
ZEP-SRS-17-3: Read files
Zephyr shall provide read access to files in the file system.
- Status:
Draft
- Type:
Functional
- Component:
File System
- User Story:
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.
- Parents:
ZEP-SRS-17-4: Write to files
Zephyr shall provide write access to the files in the file system.
- Status:
Draft
- Type:
Functional
- Component:
File System
- User Story:
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.
- Parents:
ZEP-SRS-17-5: Close file
Zephyr shall provide file close capabilities for files on the file system.
- Status:
Draft
- Type:
Functional
- Component:
File System
- User Story:
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.
- Parents:
ZEP-SRS-17-6: Move file
Zephyr shall provide the capability to move files on the file system.
- Status:
Draft
- Type:
Functional
- Component:
File System
- Parents:
ZEP-SRS-17-7: Delete file
Zephyr shall provide file delete capabilities for files on the file system.
- Status:
Draft
- Type:
Functional
- Component:
File System
- User Story:
As a Zephyr OS user I want to be able to delete an existing file.
- Parents:
ZEP-SRS-7-1: Installing static IRQ service routines (ISR).
Zephyr RTOS shall provide a mechanism to initialize a static IRQ service routine (ISR), providing all parameters needed to configure the hardware and software.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-2: Static IRQ initial status.
The static IRQ shall be initially disabled.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-3: Installing direct IRQ service routines (ISR).
Zephyr RTOS shall provide a mechanism to initialize a direct IRQ handler, providing all parameters needed to configure the hardware and software.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- User Story:
As the developer of low-power and low-latency applications, I need to implement ISRs that avoid the normal interrupt and power management overhead.
- Parents:
ZEP-SRS-7-4: Direct IRQ initial status.
The direct IRQ shall be initially disabled.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-5: Installing dynamic IRQ service routines (ISR).
Zephyr RTOS shall provide a mechanism to initialize a dynamic IRQ service routine, providing all parameters needed to configure the hardware and software.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-6: Dynamic IRQ initial status.
The dynamic IRQ shall be initially disabled.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-7: Uninstalling dynamic IRQ service routines (ISR).
Zephyr RTOS shall provide a mechanism to uninstall a dynamic ISR.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-8: Global IRQ disable
Zephyr RTOS shall provide a mechanism to disable all IRQs on a CPU and return the state of the IRQ hardware prior to being disabled.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-9: Global IRQ enable
Zephyr RTOS shall provide a mechanism to enable all IRQs on a CPU and return them to their previous state.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-10: Specific IRQ disable
Zephyr RTOS shall provide a mechanism to disable a specified IRQ.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-11: Specific IRQ enable
Zephyr RTOS shall provide a mechanism to enable a specified IRQ.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-12: IRQ Enabled status
Zephyr RTOS shall provide a mechanism that returns the enabled status of a specified IRQ, where the status is enabled or disabled.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-13: ISR Context status
Zephyr RTOS shall provide a mechanism that returns the execution context, where the context is In-ISR or Not In-ISR.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- User Story:
As the developer of functions that may run in either ISR or THREAD context, I need to know the current context to enable conditional behavior.
- Parents:
ZEP-SRS-7-14: Multi-level interrupts
The Zephyr RTOS shall support multi-level preemptive interrupt priorities, when supported by hardware.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-15: Interrupt service routine invocation
When an enabled IRQ that has a connected interrupt service routine is asserted, the Zephyr RTOS shall invoke the associated interrupt service routine.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-7-16: Interrupt service routine parameter
When the Zephyr RTOS invokes a static or dynamic interrupt service routine, it shall pass to the routine the parameter that was registered with it.
- Status:
Draft
- Type:
Functional
- Component:
Interrupts
- Parents:
ZEP-SRS-11-1: Dedicated Logging Thread Support
The Zephyr RTOS shall support isolation of logging from other functionality.
- Status:
Draft
- Type:
Functional
- Component:
Logging
- User Story:
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.
- Parents:
ZEP-SRS-11-2: Logs available for post processing
The Zephyr RTOS logging shall produce logs that are capable of being post processed.
- Status:
Draft
- Type:
Functional
- Component:
Logging
- User Story:
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.
- Parents:
ZEP-SRS-11-3: Formatting log messages
The Zephyr RTOS logging shall support formatting of log messages to enable filtering.
- Status:
Draft
- Type:
Functional
- Component:
Logging
- User Story:
As a Zephyr RTOS user I want to be able my application to format texts (printf alike) into the log message.
- Parents:
ZEP-SRS-11-4: Logging Filtering Support
The Zephyr RTOS logging system shall support filtering based on severity level.
- Status:
Draft
- Type:
Functional
- Component:
Logging
- User Story:
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).
- Parents:
ZEP-SRS-11-5: Multiple Backend Logging Support
The Zephyr RTOS shall support logging messages to multiple system resources.
- Status:
Draft
- Type:
Functional
- Component:
Logging
- User Story:
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.).
- Parents:
ZEP-SRS-11-6: Deferred Logging Support
The Zephyr RTOS shall support deferred logging.
- Status:
Draft
- Type:
Functional
- Component:
Logging
- User Story:
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.
- Parents:
ZEP-SRS-8-1: Memory Protection
The Zephyr RTOS shall support memory protection features to isolate a thread’s memory region.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
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.
- Parents:
ZEP-SRS-8-2: Granting access to kernel objects
The Zephyr RTOS shall provide a mechanism to grant user threads access to kernel objects.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
As a Zephyr RTOS user I want, from the user space, under certain conditions, access to kernel objects.
- Parents:
ZEP-SRS-8-3: Separation between user and kernel threads for memory access
The Zephyr RTOS shall be able to differentiate between user threads and kernel threads for memory access.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
As a Zephyr RTOS user I want, from the kernel space, unconditioned access to kernel objects.
- Parents:
ZEP-SRS-8-4: Safely handle unimplemented calls or invalid system calls
The Zephyr RTOS shall have a defined behaviour when an invocation of an unimplemented system call is made.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
As a Zephyr RTOS user I want Zephyr OS to indicate any unimplemented system call by an appropriate error message.
- Parents:
ZEP-SRS-8-5: Response to invalid system call IDs
The Zephyr RTOS shall have a defined behaviour when an invalid system call ID is used.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
As a Zephyr RTOS user I want Zephyr OS to indicate invalid system call by an appropriate error message.
- Parents:
ZEP-SRS-8-6: Prevent user threads creating higher priority threads
The Zephyr RTOS shall prevent user threads from creating new threads that are higher priority than the caller.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- Parents:
ZEP-SRS-8-7: Revoking threads permissions on a kernel object
The Zephyr RTOS shall support revoking permission to a kernel object. User mode threads may only revoke their own access to an object.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
As a Zephyr RTOS user I want to be protected against other user threads changing access to kernel objects of my thread.
- Parents:
ZEP-SRS-8-8: Prevent user threads creating supervisor threads
The Zephyr RTOS shall prevent user threads from creating kernel threads.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
As a Zephyr RTOS user I want to be protected against user threads creating higher privileged kernel/supervisor threads.
- Parents:
ZEP-SRS-8-9: Reduced Privilege Level Threads
The Zephyr RTOS shall allow the creation of threads that run in reduced privilege level.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
As a Zephyr RTOS user I want to be able to create lower privileged threads than my own.
- Parents:
ZEP-SRS-8-10: User Mode Threads Performing Privileged Operations
The Zephyr RTOS shall provide system calls to allow user mode threads to perform privileged operations.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
As a Zephyr RTOS user I want to be able to perform privileged operations in the kernel mode through a well defined interface.
- Parents:
ZEP-SRS-8-11: User mode handling of detected stack overflow
The Zephyr RTOS shall support a defined mechanism for user mode handling a of detected stack overflow.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
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.
- Parents:
ZEP-SRS-8-12: Stack Overflow Detection
The Zephyr RTOS shall support detection of stack overflows.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
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.
- Parents:
ZEP-SRS-8-13: Boot Time Memory Access Policy
The Zephyr RTOS shall support configurable access to memory during boot time.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- Parents:
ZEP-SRS-8-14: System Call Handler Functions
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.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
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.
- Parents:
ZEP-SRS-8-15: System Call C strings in user mode
The Zephyr RTOS shall support system calls to be able to safely accept C strings passed in from user mode.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
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 ???
- Parents:
ZEP-SRS-8-16: Tracking kernel objects in used by user mode threads
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).
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- Parents:
ZEP-SRS-8-17: Granting threads access to specific memory
The Zephyr RTOS shall have an interface to request access to specific memory after initial allocation.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
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.
- Parents:
ZEP-SRS-8-18: Assigning memory pools to act as a thread resource pool
The Zephyr RTOS shall support assigning a memory pool to act as that thread’s resource pool.
- Status:
Draft
- Type:
Functional
- Component:
Memory Protection
- User Story:
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.
- Parents:
ZEP-SRS-9-1: Dynamic Memory Allocation
The Zephyr RTOS shall allow threads to dynamically allocate variable-sized memory regions from a specified range of memory.
- Status:
Draft
- Type:
Functional
- Component:
Memory Objects
- User Story:
As a Zephyr RTOS user I want my application to be able to dynamically allocate memory of a application defined size.
- Parents:
ZEP-SRS-9-2: Memory Slab Object
The Zephyr RTOS shall allow threads to dynamically allocate fixed-sized memory regions from a specified range of memory.
- Status:
Draft
- Type:
Functional
- Component:
Memory Objects
- User Story:
As a Zephyr RTOS user I want a most efficient and least fragmentation prone dynamic memory allocation mechanism.
- Parents:
ZEP-SRS-15-1: Traditional FIFO Queue
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.
- Status:
Draft
- Type:
Functional
- Component:
Data Passing
- User Story:
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.
ZEP-SRS-15-2: Traditional LIFO queue
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.
- Status:
Draft
- Type:
Functional
- Component:
Data Passing
- User Story:
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.
ZEP-SRS-6-1: Mutex Kernel Object
The Zephyr RTOS shall provide a mutex that allows threads to obtain mutually exclusive access to a shared resource.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- User Story:
As a Zephyr RTOS user I want to be able to synchronize threads when accessing common resources, where the thread shall have the option to: - wait indefinitely until the resource becomes available. - immediately return with an error if the resource is not available and continue. - wait for a given time for the resource to become available or return with an error.
- Parents:
ZEP-SRS-6-2: Mutex definition at compile time
The Zephyr RTOS shall provide a mechanism to define and initialize a mutex at compile time.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- Parents:
ZEP-SRS-6-3: Mutex definition at run time
The Zephyr RTOS shall provide a mechanism to initialize a mutex at run time.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- Parents:
ZEP-SRS-6-4: Locking a mutex
The Zephyr RTOS shall provide a mechanism for a thread to lock a mutex and become its owner.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- Parents:
ZEP-SRS-6-5: Locking an unowned mutex
While a mutex is not owned by any thread, a thread that locks it shall acquire ownership of the mutex.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- Parents:
ZEP-SRS-6-6: Locking a mutex owned by another thread
While a mutex is owned by another thread, a thread that attempts to lock it shall be blocked until the mutex becomes available or the specified timeout elapses.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- Parents:
ZEP-SRS-6-7: Mutex lock timeout
When locking a mutex, the Zephyr RTOS shall accept a timeout that specifies the maximum time to wait for the mutex to become available.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- Parents:
ZEP-SRS-6-8: Mutex lock timeout expiry
When a mutex does not become available within the specified time, the Zephyr RTOS shall return an error indicating that the mutex was not locked.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- Parents:
ZEP-SRS-6-9: Recursive mutex locking
While a thread owns a mutex, the Zephyr RTOS shall allow that thread to lock the same mutex again, and shall require the thread to unlock it the same number of times before it is released.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- Parents:
ZEP-SRS-6-10: Unlocking a mutex
The Zephyr RTOS shall provide a mechanism for the owning thread to unlock a mutex.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- Parents:
ZEP-SRS-6-11: Unlocking by a non-owner
If a thread that does not own a mutex attempts to unlock it, then the Zephyr RTOS shall return an error and shall not release the mutex.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- Parents:
ZEP-SRS-6-12: Priority inheritance
While a higher-priority thread is blocked waiting on a mutex, the Zephyr RTOS shall raise the priority of the owning thread to that of the highest-priority waiting thread until the mutex is released.
- Status:
Draft
- Type:
Functional
- Component:
Mutex
- Parents:
ZEP-SRS-5-1: Counting Semaphore Definition At Compile Time
The Zephyr RTOS shall provide a mechanism to define and initialize a semaphore at compile time.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-2: Counting Semaphore Definition At Run Time
The Zephyr RTOS shall provide a mechanism to define and initialize a semaphore at runtime.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-3: Maximum limit of a semaphore
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.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-4: Initialialization with maximum count value
When initializing a counting semaphore, the maximum permitted count a semaphore can have shall be set.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-5: Initial semaphore value
When initializing a counting semaphore, the initial semaphore value shall be set.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-6: Semaphore acquisition mechanism
The Zephyr RTOS shall provide a mechanism allowing threads to acquire a semaphore.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-7: Semaphore acquisition with count greater than zero
While the semaphore’s count is greater than zero, the requesting thread shall acquire the semaphore and decrement its count.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-8: Semaphore acquisition with zero count
While the semaphore’s count is zero, the requesting thread shall be blocked until the semaphore is released by another thread.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-9: Semaphore acquisition timeout
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.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-10: Semaphore acquisition timeout error handling
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.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-11: Semaphore acquisition no wait error handling
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.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-12: Semaphore release
The Zephyr RTOS shall provide a mechanism allowing threads to release a semaphore.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-13: Semaphore count increment on release
The Zephyr RTOS shall increment the semaphore’s count upon release.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-14: Highest-priority waiter unblocked on release
When there are threads waiting on the semaphore, the highest-priority waiting thread shall be unblocked and acquire the semaphore.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-15: Checking semaphore count
The Zephyr RTOS shall provide a mechanism for threads to check the current count of a semaphore without acquiring it.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-16: Semaphore reset
The Zephyr RTOS shall provide a mechanism that resets the semaphore count to zero.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-17: Semaphore acquisitions abort after reset
When a semaphore is reset, the Zephyr RTOS shall abort all pending take operations on the semaphore, returning to the affected threads the same error used to indicate a wait timeout.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-18: Semaphore Initialization Option Validation
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.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-19: Semaphore release at maximum count
When a semaphore is released while its count is already at the maximum permitted count, the Zephyr RTOS shall leave the count unchanged.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-5-20: Semaphore operations from interrupt context
The Zephyr RTOS shall allow a semaphore to be released from an interrupt service routine, and to be acquired from an interrupt service routine when no waiting is requested.
- Status:
Draft
- Type:
Functional
- Component:
Semaphore
- Parents:
ZEP-SRS-13-1: Power State Control
The Zephyr RTOS shall provide control over changes to system power states.
- Status:
Draft
- Type:
Functional
- Component:
Power Management
- User Story:
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.
- Parents:
ZEP-SRS-13-2: Power Management
TBD
- Status:
Draft
- Type:
Functional
- Component:
Power Management
- Parents:
ZEP-SRS-13-3: Notification of changes to system power states
The Zephyr RTOS shall provide notification of changes to system power states.
- Status:
Draft
- Type:
Functional
- Component:
Power Management
- Parents:
ZEP-SRS-3-1: Exchanging data between threads
The Zephyr RTOS shall provide a mechanism for exchanging data between threads.
- Status:
Draft
- Type:
Functional
- Component:
Thread Communication
- User Story:
(Note: copying data may be needed here - what is Zephyr doing? is it configurable?)
ZEP-SRS-3-2: Waiting for results during communication
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).
- Status:
Draft
- Type:
Functional
- Component:
Thread Communication
- User Story:
=N73
ZEP-SRS-3-3: Poll Operation Support
The Zephyr RTOS shall support a poll operation which enables waiting concurrently for any one of multiple conditions to be fulfilled.
- Status:
Draft
- Type:
Functional
- Component:
Thread Communication
- User Story:
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.
ZEP-SRS-3-4: Pipe Communication Primitive
The Zephyr RTOS shall provide a communication primitive that allows a thread to transfer a block of data to another thread.
- Status:
Draft
- Type:
Functional
- Component:
Thread Communication
- User Story:
As a Zephyr RTOS user I want to send a byte stream from one thread to another in a thread-safe manner.
ZEP-SRS-3-5: Message Queue
The Zephyr RTOS shall provide a a communication primitive that allow threads and ISRs to asynchronously exchange fixed-size data items.
- Status:
Draft
- Type:
Functional
- Component:
Thread Communication
ZEP-SRS-3-6: Mailbox Kernel Primitive
The Zephyr RTOS shall provide a communication primitive that allows threads to exchange messages of varying sizes asynchronously or synchronously.
- Status:
Draft
- Type:
Functional
- Component:
Thread Communication
- User Story:
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.
ZEP-SRS-2-1: Support operation on more than one CPU
The Zephyr RTOS shall support operation on more than one physical CPU sharing the same kernel state.
- Status:
Draft
- Type:
Functional
- Component:
Multi Core
ZEP-SRS-2-2: Running threads on specific CPUs
The Zephyr RTOS shall provide an interface for running threads on specific sets of CPUs ( default is 1 CPU).
- Status:
Draft
- Type:
Functional
- Component:
Multi Core
- User Story:
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.
ZEP-SRS-2-3: Exclusion between physical CPUs
The Zephyr RTOS shall provide an interface for mutual exclusion between multiple physical CPUs.
- Status:
Draft
- Type:
Functional
- Component:
Multi Core
- User Story:
As a Zephyr RTOS user I want Zephyr OS to provide synchronization mechanisms between the CPU cores and the access to common resources.
ZEP-SRS-2-4: Scheduling a thread based on an event
The Zephyr RTOS shall provide an interface to schedule a thread based on an event.
- Status:
Draft
- Type:
Functional
- Component:
Thread Scheduling
- User Story:
As a Zephyr RTOS user, I want to be able to execute work which reacts on events and interrupts the current executed work.
- Parents:
ZEP-SRS-2-5: Deadline Scheduling Priorities
The Zephyr RTOS shall organize running threads by earliest deadline first priority.
- Status:
Draft
- Type:
Functional
- Component:
Thread Scheduling
- User Story:
As a Zephyr RTOS user, I want to be able to schedule threads by earliest deadline first.
ZEP-SRS-2-6: Work Queue utility capable of running preemptible work items
The Zephyr RTOS shall provide a thread-pooled work queue utility capable of running preemptible work items with specific scheduler priorities.
- Status:
Draft
- Type:
Functional
- Component:
Thread Scheduling
- User Story:
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.
ZEP-SRS-2-7: Run user supplied functions in-order in a separate thread(s)
The Zephyr RTOS shall provide an interface for running user-supplied functions.
- Status:
Draft
- Type:
Functional
- Component:
Thread Scheduling
- User Story:
As a Zephyr RTOS user, I want to be able to run functions in-order in a separated thread/threads.
ZEP-SRS-2-8: Organize running threads into a fixed list
The Zephyr RTOS shall organize running threads into a fixed list of numeric priorities.
- Status:
Draft
- Type:
Functional
- Component:
Thread Scheduling
- User Story:
As a Zephyr RTOS user, I want that the OS organize running threads in a fixed list of numeric priorities.
ZEP-SRS-2-9: Preemption support
The Zephyr RTOS shall support preemption of a running thread by a higher priority thread.
- Status:
Draft
- Type:
Functional
- Component:
Thread Scheduling
- User Story:
As a Zephyr RTOS user, I want that the OS preempt running threads by a thread with higher priority.
ZEP-SRS-2-10: Un-preemptible thread priorities
The Zephyr RTOS shall support thread priorities which cannot be preempted by other user threads.
- Status:
Draft
- Type:
Functional
- Component:
Thread Scheduling
- User Story:
As a Zephyr RTOS user, I want to be able to configure thread prioritizes which cannot be preempted by other user threads.
ZEP-SRS-2-11: Time sharing of CPU resources
The Zephyr RTOS shall support time sharing of CPU resources among threads of the same priority.
- Status:
Draft
- Type:
Functional
- Component:
Thread Scheduling
- User Story:
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.
ZEP-SRS-1-1: Creating threads
The Zephyr RTOS shall provide an interface to create (start) a thread.
- Status:
Draft
- Type:
Functional
- Component:
Threads
- Parents:
ZEP-SRS-1-2: Setting thread priority
The Zephyr RTOS shall provide an interface to set a thread’s priority.
- Status:
Draft
- Type:
Functional
- Component:
Threads
- Parents:
ZEP-SRS-1-3: Suspending a thread
The Zephyr RTOS shall provide an interface to suspend a thread.
- Status:
Draft
- Type:
Functional
- Component:
Threads
- Parents:
ZEP-SRS-1-4: Resuming a suspended thread
The Zephyr RTOS shall provide an interface to resume a suspended thread.
- Status:
Draft
- Type:
Functional
- Component:
Threads
- Parents:
ZEP-SRS-1-5: Resuming a suspended thread after a timeout
The Zephyr RTOS shall provide an interface to resume a suspended thread after a timeout.
- Status:
Draft
- Type:
Functional
- Component:
Threads
- Parents:
ZEP-SRS-1-6: Deleting a thread
The Zephyr RTOS shall provide an interface to delete (end) a thread.
- Status:
Draft
- Type:
Functional
- Component:
Threads
- Parents:
ZEP-SRS-1-7: Thread states
Threads shall have different states to fulfill the Life-cycle of a thread
- Status:
Draft
- Type:
Functional
- Component:
Threads
- User Story:
As a Zephyr RTOS user, I want to know in what state a specific thread is.
- Parents:
ZEP-SRS-1-8: Thread stack objects
Every Thread shall have it’s own stack.
- Status:
Draft
- Type:
Functional
- Component:
Threads
- User Story:
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.
- Parents:
ZEP-SRS-1-9: Thread privileges
The Zephyr RTOS shall provide an interface to create threads with defined privilege.
- Status:
Draft
- Type:
Functional
- Component:
Threads
- Parents:
ZEP-SRS-1-10: Scheduling multiple threads
The Zephyr RTOS shall provide an interface to schedule multiple threads.
- Status:
Draft
- Type:
Functional
- Component:
Threads
- Parents:
ZEP-SRS-1-11: Thread Options
The Zephyr RTOS shall support a set of thread options.
- Status:
Draft
- Type:
Functional
- Component:
Threads
- User Story:
As a Zephyr RTOS user, I want to be able to pass specific option to a thread.
- Parents:
ZEP-SRS-1-12: Thread Custom Data
Every thread shall have a custom data area.
- Status:
Draft
- Type:
Functional
- Component:
Threads
- User Story:
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
- Parents:
ZEP-SRS-4-1: Timer definition at compile time
The Zephyr RTOS shall provide a mechanism to define and statically (i.e. compile time) initialize timers.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-2: Timer expiry function
When initializing a timer, the Zephyr RTOS shall support setting a function that gets called when the timer expires.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-3: Timer stop function
When initializing a timer, the Zephyr RTOS shall support setting a function that gets called when a running timer is stopped.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-4: Timer definition at run time
The Zephyr RTOS shall provide a mechanism to define and initialize timers at run time.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-5: Timer start
The Zephyr RTOS shall provide a mechanism to start a timer for a specific duration and periodicity.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-6: Timer stop
The Zephyr RTOS shall provide a mechanism to stop a running timer.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-7: Timer status
The Zephyr RTOS shall provide a mechanism to read the number of times a timer has expired and then reset this count to zero.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-8: Timer status reinitialization
When a timer is initialized, started, or read via the timer status or synchronization mechanism, the Zephyr RTOS shall reset the timer’s expiration count to zero.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-9: Timer thread synchronization
The Zephyr RTOS shall provide a mechanism to synchronize a thread to a timer and then block the thread’s execution until any of the following conditions is satisfied: - The timer is stopped - The timer’s expiration count is greater than zero
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-10: Timer next expiration time in system ticks
The Zephyr RTOS shall provide a mechanism to get a timer’s next expiration time in system ticks.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-11: Timer remaining time until expiration in system ticks
The Zephyr RTOS shall provide a mechanism to get a timer’s remaining time until its next expiry in system ticks.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-12: Timer remaining time until expiration in milliseconds
The Zephyr RTOS shall provide a mechanism to get the timer’s remaining time until its next expiry in milliseconds.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-13: Timer set user data
The Zephyr RTOS shall support adding user defined data to a timer.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-14: Timer get user data
The Zephyr RTOS shall support retrieving user defined data from a timer.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-4-15: Timer expire functions in interrupt context
When a timer expiry function is called, the Zephyr RTOS shall do so in the interrupt context.
- Status:
Draft
- Type:
Functional
- Component:
Timers
- Parents:
ZEP-SRS-10-1: Initializing a trace
Zephyr shall provide an interface to initialize a trace.
- Status:
Draft
- Type:
Functional
- Component:
Tracing
- Parents:
ZEP-SRS-10-2: Triggering a trace
Zephyr shall provide an interface to trigger a trace.
- Status:
Draft
- Type:
Functional
- Component:
Tracing
- Parents:
ZEP-SRS-10-3: Dumping trace results
Zephyr shall provide an interface to dump results from a trace.
- Status:
Draft
- Type:
Functional
- Component:
Tracing
- Parents:
ZEP-SRS-10-4: Removing trace data
Zephyr shall provide an interface to remove trace data.
- Status:
Draft
- Type:
Functional
- Component:
Tracing
- Parents:
ZEP-SRS-10-5: Tracing Object Identification
Zephyr shall provide an interface to identify the objects being traced.
- Status:
Draft
- Type:
Functional
- Component:
Tracing
- User Story:
As a Zephyr 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.
- Parents:
ZEP-SRS-10-6: Tracing Non-Interference
Zephyr shall prevent the tracing functionality from interfering with normal operations.
- Status:
Draft
- Type:
Functional
- Component:
Tracing
- User Story:
As a Zephyr OS user, I want that the trace functionality do not interfere or slow down the operation system functionality.
- Parents:
ZEP-SRS-21-1: Dynamic initialization of condition variables
The Zephyr RTOS shall provide a mechanism to define and initialize a condition variable dynamically (at runtime).
- Status:
Draft
- Type:
Functional
- Component:
Condition Variables
- Parents:
ZEP-SRS-21-2: Static initialization of condition variables
The Zephyr RTOS shall provide a mechanism to define and initialize a condition variable statically (at compile time).
- Status:
Draft
- Type:
Functional
- Component:
Condition Variables
- Parents:
ZEP-SRS-21-3: Signal one waiting thread
The Zephyr RTOS shall provide a mechanism to signal the highest priority waiting thread when a condition is met.
- Status:
Draft
- Type:
Functional
- Component:
Condition Variables
- Parents:
ZEP-SRS-21-4: Signal multiple waiting threads
The Zephyr RTOS shall provide a mechanism to signal all waiting threads when a condition is met.
- Status:
Draft
- Type:
Functional
- Component:
Condition Variables
- Parents:
ZEP-SRS-21-5: Wait on a condition variable
The Zephyr RTOS shall provide a mechanism for a thread to wait on a condition variable.
- Status:
Draft
- Type:
Functional
- Component:
Condition Variables
- Parents:
ZEP-SRS-21-6: Wait timeout on a condition variable
When waiting on a condition variable, the thread shall specify a timeout value.
- Status:
Draft
- Type:
Functional
- Component:
Condition Variables
- Parents:
ZEP-SRS-21-7: Wait timeout occurence
When a timeout occurs while waiting on a condition variable, the thread shall be unblocked and a timeout error shall be returned.
- Status:
Draft
- Type:
Functional
- Component:
Condition Variables
- Parents:
ZEP-SRS-21-8: Release mutex on wait
When a thread waits on a condition variable, the Zephyr RTOS shall atomically release the associated mutex while the thread is blocked and re-acquire it before the thread resumes.
- Status:
Draft
- Type:
Functional
- Component:
Condition Variables
- Parents:
ZEP-SRS-21-9: Unblock a waiting thread
Whenever a thread signals a condition variable, the Zephyr RTOS shall unblock the highest priority thread currently waiting on that condition variable.
- Status:
Draft
- Type:
Functional
- Component:
Condition Variables
- Parents:
ZEP-SRS-20-1: Queue definition at compile time
The Zephyr RTOS shall provide a mechanism to define and initialize a queue at compile time.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-2: Queue definition at run time.
The Zephyr RTOS shall provide a mechanism to define and initialize a queue at run time.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-3: Queue enqueue item to the back
The Zephyr RTOS shall provide a mechanism to enqueue a data item to the back of a queue (i.e. append).
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-4: Queue enqueue item to the front
The Zephyr RTOS shall provide a mechanism to enqueue a data item to the front of a queue (i.e. prepend).
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-5: Queue remove item
The Zephyr RTOS shall provide a mechanism to remove a specific data item from a queue.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-6: Queue get and dequeue item from front
The Zephyr RTOS shall provide a mechanism to get and dequeue a data item from the front of a queue, within a timeout.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-7: Queue empty check
The Zephyr RTOS shall provide a mechanism to check if a queue is empty.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-8: Queue peek item at back
The Zephyr RTOS shall provide a mechanism to peek at the data data item at the back of a queue.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-9: Queue peek item at front
The Zephyr RTOS shall provide a mechanism to peek at the data data item at the front of a queue.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-10: Queue insert
The Zephyr RTOS shall provide a mechanism to insert a data item behind another specific data item in a queue.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-11: Queue append item list to the back
The Zephyr RTOS shall provide a mechanism to append a list of data items to the back of a queue.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-12: Queue append and empty item list to the back
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.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-13: Queue append unique data item
The Zephyr RTOS shall provide a mechanism to append a data item uniquely to the queue.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-20-14: Queue implicit memory allocation
The Zephyr RTOS shall provide a dedicated mechanism to implicite allocate memory from a thread when appending data items to a queue.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-23-1: LIFO definition at compile time
The Zephyr RTOS shall provide a mechanism to define and initialize a LIFO at compile time.
- Status:
Draft
- Type:
Functional
- Component:
LIFOs
- Parents:
ZEP-SRS-23-2: LIFO enqueue item to the back
The Zephyr RTOS shall provide a mechanism to enqueue a data item to the back of a LIFO (i.e. prepend).
- Status:
Draft
- Type:
Functional
- Component:
LIFOs
- Parents:
ZEP-SRS-23-3: LIFO implicit memory allocation
The Zephyr RTOS shall provide a mechanism to allocate memory from a thread when enqueuing data items to a LIFO.
- Status:
Draft
- Type:
Functional
- Component:
LIFOs
- Parents:
ZEP-SRS-23-4: LIFO get and dequeue item from front
The Zephyr RTOS shall provide a mechanism to get and dequeue a data item from the back of a LIFO, within a timeout.
- Status:
Draft
- Type:
Functional
- Component:
LIFOs
- Parents:
ZEP-SRS-23-5: Queue definition at compile time
The Zephyr RTOS shall provide a mechanism to define and initialize a LIFO at compile time.
- Status:
Draft
- Type:
Functional
- Component:
Queues
- Parents:
ZEP-SRS-24-1: FIFO definition at compile time
The Zephyr RTOS shall provide a mechanism to define and initialize a FIFO at compile time.
- Status:
Draft
- Type:
Functional
- Component:
FIFOs
- Parents:
ZEP-SRS-24-2: FIFO cancel waiting thread
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.
- Status:
Draft
- Type:
Functional
- Component:
FIFOs
- Parents:
ZEP-SRS-24-3: FIFO enqueue item to the back
The Zephyr RTOS shall provide a mechanism to enqueue a data item to the back of a FIFO (i.e. append).
- Status:
Draft
- Type:
Functional
- Component:
FIFOs
- Parents:
ZEP-SRS-24-4: FIFO implicit memory allocation
The Zephyr RTOS shall provide a mechanism to allocate memory from a thread when enqueuing data items to a FIFO.
- Status:
Draft
- Type:
Functional
- Component:
FIFOs
- Parents:
ZEP-SRS-24-5: FIFO append item list to the back
The Zephyr RTOS shall provide a mechanism to append a list of data items to the back of a FIFO.
- Status:
Draft
- Type:
Functional
- Component:
FIFOs
- Parents:
ZEP-SRS-24-6: FIFO append and empty item list to the back
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.
- Status:
Draft
- Type:
Functional
- Component:
FIFOs
- Parents:
ZEP-SRS-24-7: FIFO get and dequeue item from front
The Zephyr RTOS shall provide a mechanism to get and dequeue a data item from the front of a FIFO, within a timeout.
- Status:
Draft
- Type:
Functional
- Component:
FIFOs
- Parents:
ZEP-SRS-24-8: FIFO empty check
The Zephyr RTOS shall provide a mechanism to check if a FIFO is empty.
- Status:
Draft
- Type:
Functional
- Component:
FIFOs
- Parents:
ZEP-SRS-24-9: FIFO peek item at front
The Zephyr RTOS shall provide a mechanism to peek at the data data item at the front of a FIFO.
- Status:
Draft
- Type:
Functional
- Component:
FIFOs
- Parents:
ZEP-SRS-24-10: FIFO peek item at back
The Zephyr RTOS shall provide a mechanism to peek at the data item at the back of a FIFO.
- Status:
Draft
- Type:
Functional
- Component:
FIFOs
- Parents:
ZEP-SRS-25-1: Mailbox Initialization At Run Time
The Zephyr RTOS shall provide a mechanism to define and initialize a mailbox at run time.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be able to initialize a mailbox instance so that it is ready to be used for message exchange between threads.
- Parents:
ZEP-SRS-25-2: Mailbox Initialization At Compile Time
The Zephyr RTOS shall provide a mechanism to statically define and initialize a mailbox object at compile time.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be able to statically define and initialize a mailbox at compile time so that it is available immediately without runtime initialization.
- Parents:
ZEP-SRS-25-3: Message Size Support
The Zephyr RTOS shall support messages containing zero or more bytes of data.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be able to send messages of different sizes using the same mailbox so that I can efficiently communicate different types of information between threads.
- Parents:
ZEP-SRS-25-4: Mailbox Data Transfer
The Zephyr RTOS shall handle the data transfer between mailbox objects of the sending and receiving threads.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- Parents:
ZEP-SRS-25-5: Synchronous Message Sending
The Zephyr RTOS shall provide a mechanism for a thread to send a message through a mailbox and block until the message is processed or a timeout occurs.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be able to send a message and wait for it to be processed so that I can be sure the message was received before continuing execution.
- Parents:
ZEP-SRS-25-6: Synchronous Send Timeout Handling
If the synchronous message send operation times out before a receiver processes the message, the Zephyr RTOS shall return an timeout error code to the sending thread.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be able to limit how long my thread waits for a message to be received so that I can implement fallback behavior if communication takes too long.
- Parents:
ZEP-SRS-25-7: Asynchronous Message Sending
The Zephyr RTOS shall provide a mechanism for a thread to send a message through a mailbox without waiting for it to be processed.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be able to send a message without waiting for it to be processed so that my thread can continue execution immediately.
- Parents:
ZEP-SRS-25-8: Asynchronous Completion Signaling
When a sending thread asynchronously sends a message to a mailbox object, the Zephyr RTOS shall provide a mechanism to signal to the sending thread that the message has been both received and completely processed by the receiver.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be notified when my asynchronously sent message has been fully processed so that I can perform follow-up actions without polling.
- Parents:
ZEP-SRS-25-9: Message Reception
The Zephyr RTOS shall provide a mechanism for a thread to receive a message via a mailbox object with a timeout parameter.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be able to receive messages from other threads with control over how long to wait for a message to arrive.
- Parents:
ZEP-SRS-25-10: Message Data Retrieval
The Zephyr RTOS shall provide a mechanism for a thread to retrieve message data via a mailbox object.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be able to extract message data into my buffer after message reception so that I can process the information contained in the message.
- Parents:
ZEP-SRS-25-11: Message Reception Blocking
When a receiving thread requests a message via a mailbox object and no message is available, the Zephyr RTOS shall block the receiving thread until a message is available or the timeout expires.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- Parents:
ZEP-SRS-25-12: Message Reception Timeout Handling
If the message receive operation times out before a message becomes available, the Zephyr RTOS shall return an appropriate timeout error code to the receiving thread.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be able to limit how long my thread waits for a message to arrive so that I can implement fallback behavior if communication takes too long.
- Parents:
ZEP-SRS-25-13: Non-Anonymous Messaging
The Zephyr RTOS shall handle message exchange via a mailbox object non-anonymously, allowing both the sending and receiving threads to know the identity of the other thread.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be able to identify the source or destination of messages so that I can implement thread-specific handling of message content.
- Parents:
ZEP-SRS-25-14: Priority-Based Message Delivery
When multiple threads are waiting on an empty mailbox object, the Zephyr RTOS shall deliver the next message to the highest priority thread.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want message delivery to respect thread priorities so that higher priority tasks receive messages before lower priority ones.
- Parents:
ZEP-SRS-25-15: Priority-Based Message Delivery
When multiple threads of equal priority are waiting on an empty mailbox object, the Zephyr RTOS shall deliver the next message to the thread that has waited the longest.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- Parents:
ZEP-SRS-25-16: Mailbox Quantity Support
The Zephyr RTOS shall support an arbitrary number of mailbox objects, limited only by available RAM in the system.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want to be able to create as many mailboxes as my application needs without arbitrary limitations so that I can design my communication architecture freely.
- Parents:
ZEP-SRS-25-17: Invalid Parameter Handling
The Zephyr RTOS shall handle invalid parameters by returning error codes rather than causing system failures.
- Status:
Draft
- Type:
Functional
- Component:
Mailboxes
- User Story:
As a Zephyr RTOS developer, I want the system to validate my inputs and return errors rather than crash when I provide invalid parameters so that I can develop more robust applications.
- Parents:
ZEP-SRS-30-1: Stack definition at compile time
The Zephyr RTOS shall provide a mechanism to define and initialize a stack at compile time.
- Status:
Draft
- Type:
Functional
- Component:
Stacks
- Parents:
ZEP-SRS-30-2: Stack initialization at run time with an user-defined memory area
The Zephyr RTOS shall provide a mechanism to initialize a stack at run time, using a data buffer provided by the user.
- Status:
Draft
- Type:
Functional
- Component:
Stacks
- Parents:
ZEP-SRS-30-3: Stack initialization at run time with automatically allocated memory area
The Zephyr RTOS shall provide a mechanism to initialize a stack at run time, with automatic allocation of the stack memory.
- Status:
Draft
- Type:
Functional
- Component:
Stacks
- Parents:
ZEP-SRS-30-4: Releasing a dynamically allocated stack buffer
The Zephyr RTOS shall provide a mechanism to deallocate all resources previously allocated by a run-time stack definition.
- Status:
Draft
- Type:
Functional
- Component:
Stacks
- Parents:
ZEP-SRS-30-5: Push an item to the stack
The Zephyr RTOS shall provide a mechanism to add a new item on top of the stack.
- Status:
Draft
- Type:
Functional
- Component:
Stacks
- Parents:
ZEP-SRS-30-6: Pop an item from the stack
The Zephyr RTOS shall provide a mechanism to retrieve the current item from the top of the stack and to remove such item from the stack.
- Status:
Draft
- Type:
Functional
- Component:
Stacks
- Parents:
ZEP-SRS-30-7: Pushing onto a full stack
If the stack is full when an item is pushed, the Zephyr RTOS shall return an error and not add the item.
- Status:
Draft
- Type:
Functional
- Component:
Stacks
- Parents:
ZEP-SRS-30-8: Concurrent access protection
The Zephyr RTOS shall provide a mechanism to push items to or pop items from the same stack object from multiple execution contexts which can run concurrently.
- Status:
Draft
- Type:
Functional
- Component:
Stacks
- User Story:
As a Zephyr RTOS user I want to access a stack from different execution contexts (like threads), including interrupt handlers.
- Parents:
ZEP-SRS-30-9: Stack data retrieval with timeout
The Zephyr RTOS shall provide a mechanism to allow waiting for a stack item availability within a specified timeout.
- Status:
Draft
- Type:
Functional
- Component:
Stacks
- User Story:
As a Zephyr RTOS user I want to share a stack object between a producer and a consumer threads. The producer thread pushes items into the stack, while the consumer thread is waiting for an item to appear in the stack.
- Parents:
ZEP-SRS-26-1: Atomic variable
The Zephyr RTOS shall define an atomic variable type whose size matches the native word size of the target architecture: 32 bits on 32-bit architectures and 64 bits on 64-bit architectures.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-2: Atomic value
The Zephyr RTOS shall define a signed integer type, whose size is determined by the target processor architecture, used as the parameter and return type of operations on atomic variables.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-3: Tearing freedom
The Zephyr RTOS shall guarantee that each operation on an atomic variable is free from torn reads or writes.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-4: Cross-CPU visibility
The Zephyr RTOS shall guarantee that the result of each operation on an atomic variable is visible to all processors in the system.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-5: Indivisibility
The Zephyr RTOS shall provide a mechanism for performing all operations on an atomic variable in an indivisible manner.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-6: Memory ordering
When performing an operation on an atomic variable, the Zephyr RTOS shall provide full memory barrier semantics, such that memory operations issued before the atomic operation are observed before it and memory operations issued after it are observed after it.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-7: Software implementation fallback
The Zephyr RTOS shall support executing atomic operations on hardware that does not provide native atomic instruction support.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-8: Native atomic instructions
Where the target hardware provides native atomic instructions, the Zephyr RTOS shall support implementing atomic operations using those instructions.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-9: Compute size of atomic variables
The Zephyr RTOS shall provide a compile-time mechanism for computing the minimum number of atomic variables necessary to represent a bit array of a given number of bits.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-10: Define an array of atomic variables
The Zephyr RTOS shall provide a compile-time mechanism for defining an array of atomic variables with the minimum size necessary to represent a bit array of a given number of bits.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-11: Initialize atomic variable
The Zephyr RTOS shall provide a compile-time mechanism for initializing an atomic variable.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-12: Set atomic variable
The Zephyr RTOS shall provide a mechanism for setting an atomic variable and returning its previous value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-13: Get atomic variable
The Zephyr RTOS shall provide a mechanism for getting the value from an atomic variable.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-14: Atomic bitwise operations
When performing a bitwise operation on an atomic variable, the Zephyr RTOS shall store the result in the atomic variable and return its previous value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-15: Atomic bitwise AND operation
The Zephyr RTOS shall provide a mechanism for performing a bitwise AND operation on an atomic variable with a given value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-16: Atomic bitwise OR operation
The Zephyr RTOS shall provide a mechanism for performing a bitwise OR operation on an atomic variable with a given value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-17: Atomic bitwise NAND operation
The Zephyr RTOS shall provide a mechanism for performing a bitwise NAND operation on an atomic variable with a given value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-18: Atomic bitwise XOR operation
The Zephyr RTOS shall provide a mechanism for performing a bitwise XOR operation on an atomic variable with a given value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-19: Atomic addition
The Zephyr RTOS shall provide a mechanism for adding a value to an atomic variable and returning its previous value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-20: Atomic increment
The Zephyr RTOS shall provide a mechanism for incrementing an atomic variable by 1 and returning its previous value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-21: Atomic subtraction
The Zephyr RTOS shall provide a mechanism for subtracting a value from an atomic variable and returning its previous value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-22: Atomic decrement
The Zephyr RTOS shall provide a mechanism for decrementing an atomic variable by 1 and returning its previous value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-23: Atomic compare and set
The Zephyr RTOS shall provide a mechanism for setting an atomic variable to a new value if and only if its current value equals an expected value, leaving the atomic variable unchanged otherwise, and returning whether the atomic variable was updated.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-24: Atomic clear
The Zephyr RTOS shall provide a mechanism for setting an atomic variable to zero and returning its previous value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-25: Atomic bit operations
The Zephyr RTOS shall support performing bit-level operations on individual bits within either a single atomic variable or an array of atomic variables.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-26: Atomic set bit
The Zephyr RTOS shall provide a mechanism for setting a specific bit within an atomic variable or an array of atomic variables to 1.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-27: Atomic clear bit
The Zephyr RTOS shall provide a mechanism for clearing a specific bit within an atomic variable or an array of atomic variables to 0.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-28: Atomic set bit to a given state
The Zephyr RTOS shall provide a mechanism for setting a specific bit within an atomic variable or an array of atomic variables to a given boolean value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-29: Atomic test bit
The Zephyr RTOS shall provide a mechanism for getting the state of a specific bit within an atomic variable or an array of atomic variables, returning its current state as a boolean value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-30: Atomic test and set bit
The Zephyr RTOS shall provide a mechanism for setting a specific bit within an atomic variable or an array of atomic variables to 1 and returning its previous state.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-31: Atomic test and clear bit
The Zephyr RTOS shall provide a mechanism for clearing a specific bit within an atomic variable or an array of atomic variables to 0 and returning its previous state.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-32: Atomic pointer
The Zephyr RTOS shall define an atomic variable type for storing a pointer value atomically.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-33: Atomic pointer value
The Zephyr RTOS shall define a pointer type used as the parameter and return type of all atomic pointer operations.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-34: Initialize atomic pointer
The Zephyr RTOS shall provide a compile-time mechanism for initializing an atomic pointer to a specific pointer value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-35: Atomic pointer operations
The Zephyr RTOS shall provide operations that read and write atomic pointers using the atomic pointer value type.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-36: Get atomic pointer
The Zephyr RTOS shall provide a mechanism for getting the pointer value from an atomic pointer.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-37: Set atomic pointer
The Zephyr RTOS shall provide a mechanism for setting an atomic pointer and returning its previous pointer value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-38: Atomic pointer compare and set
The Zephyr RTOS shall provide a mechanism for setting an atomic pointer to a new value if and only if its current value equals an expected value, leaving the atomic pointer unchanged otherwise, and returning whether the atomic pointer was updated.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-39: Atomic pointer clear
The Zephyr RTOS shall provide a mechanism for setting an atomic pointer to NULL and returning its previous pointer value.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents:
ZEP-SRS-26-40: Usable from threads and interrupt service routines
The Zephyr RTOS shall support performing atomic operations from threads and from interrupt service routines, guaranteeing correct results when multiple contexts operate concurrently on the same atomic variable.
- Status:
Draft
- Type:
Functional
- Component:
Atomic Service
- Parents: