The “P” stands for POSIX pthreads, “X” stands for thread switching, and the “5” represents the 5th RTOS Bill Lamie has created, including commercial RTOSes Nucleus and Azure RTOS ThreadX.
We are located in San Diego, CA. Our office address is 11440 West Bernardo Court, Suite 300, San Diego, CA 92127.
Our standard hours of operation are 9 AM to 5 PM, Pacific time. That said, many of our team members have different schedules, which allows us to be responsive throughout the day.
We welcome partners to the PX5 ecosystem. Please contact us to discuss further.
For general questions and comments, please reach out to us via contact form or e-mail at info@px5rtos.com.
Yes. Using the PX5 RTOS or any of our other products requires a license. We have inexpensive perpetual and subscription licensing, both of which include full PX5 RTOS source code. Please see our licensing information here: licensing
Full PX5 RTOS source code is included with most licenses and is delivered in a custom private portal. We also include integration and examples for your choice of processor and development environment.
There are no run-time royalties (per device fees) with our standard licenses.
Yes our non-subscription licenses are typically perpetual. Please contact us for more information.
Yes, subscription licenses are available, please contact us for more information.
Yes, custom licenses are available, please contact us for more information.
Yes, subscription licenses include support. Perpetual licenses also include a period of support, after which additional support periods may be purchased.
Please visit our licensing page and submit a licensing information request: licensing
The PX5 RTOS is designed for the most resource-constrained embedded devices, requiring less than 1KB of instruction area memory for minimal operation on many architectures. Processing requirements are similarly minimal. This contrasts with typical embedded Linux distributions that require many megabytes of memory. Additionally, unlike most Linux implementations, the PX5 RTOS does not require an MMU.
Generally, an RTOS removes the burden of managing processing time from the application. Without an RTOS, the application must ensure all processing is completed within its real-time requirements. The more complex the application is, the greater the RTOS benefit is. In general, applications over 64KB or that have any networking protocol, USB, GUI, or file system requirements benefit from an RTOS which provides the following advantages:
1. Improved time-to-market
2. Enhanced device quality
3. Safer and more secure devices
4. More portable/reusable application firmware
5. Cross-platform support
6. Reduced engineering training via industry-standard pthread API
7. Professional support
For applications smaller than 32KB that have one or just a few things to do, an RTOS can be overkill. However, even in these situations, an RTOS can “future-proof” application firmware.
POSIX pthreads are an industry-standard set of APIs for multithreading. This includes threads, semaphores, mutexes, condition variables, signals, timers, etc. The PX5 RTOS delivers the native pthread API support found in embedded Linux but missing in most RTOSes.
Pthread+ is a largely optional pthreads extensions. All pthread+ APIs have a leading “px5_” prepended for easy identification.
Virtually all (99% or more) of the PX5 RTOS is written in ANSI C.. For each processor/development tool, there is one assembly language “binding” file that glues the PX5 RTOS generic C with the specific processor and development tool.
The fullest support is for the Arm processors, including the Cortex-M series MCUs and Cortex-A/R series MPUs plus RISC-V. Please contact us for the latest processor support.
We support IAR, GCC, and Arm development tools. We use IAR tools internally and recommend them to our customers.
“Real-time” requirements vary by application. Some applications must respond to some events in less than one microsecond while others might have more lenient requirements.
Yes. The PX5 RTOS is designed to execute in a predictable, deterministic manner regardless of system load. For example, an application with 100 threads will have the same context switch time as one with 10 threads.
“Embedded security” requirements vary by application. Embedded applications that connect externally generally have more stringent security requirements than those of a an unconnected, isolated device. PX5 RTOS features, Pointer/Data Verification (PDV), a unique technology that can help prevent remote execution by verifying all function pointers and return addresses on the stack.
Embedded devices are often used in critical situations that could cause serious injury or damage if they malfunction. Examples include medical, industrial, and automotive applications. Such embedded devices require a fully tested and verified RTOS as well as safety certifications such as IEC 61508. The PX5 RTOS boasts 100% statement and branch-decision test coverage, static analysis via IAR’s C-STAT, a high-degree of MISRA compliance, and planned IEC 61508 certification later this year. Of course, the unique Pointer/Data verification, stack checking/verification, and central error handling make the PX5 RTOS one of the safest RTOSes available.
Yes, in most use cases the PX5 RTOS is directly linked with the application firmware.
POSIX is a broad specification that exceeds the scope of resource-constrained embedded devices. The PX5 RTOS offers the most popular POSIX pthread APIs. Please review the PX5 RTOS User Guide for the specific API support.
Mostly. The PX5 RTOS is compliant with the vast majority of MISRA rules, with only a handful of exceptions. Please contact us for the complete list.
You can install the PX5 RTOS by adding the PX5 RTOS source code to your project and calling px5_pthread_start from your “main” program. Once px5_pthread_start returns, the “main” program has been automatically upgraded to your first thread. All other pthread APIs are now available. For complete installation information please refer to PX5_RTOS_Binding_User_Guide.pdf for specific processor/development tool installation information.
Always be suspicious of any recent changes prior to the crash. Also, placing a breakpoint on the PX5 RTOS central error handling function px5_internal_central_error_process can show if the PX5 RTOS detects any errors. For especially strange crashes, verifyi that all thread stacks (and system/ISR stacks) are large enough. If the crash is happening during the installation process, visit the examples provided in the PX5 RTOS distribution to see if they run properly. Please see the “Troubleshooting” section in the PX5_RTOS_User_Guide.pdf for more thorough information.
Each thread’s stack must be large enough to store the local variable usages through the worst-case function call path from the thread’s entry function. On top of that, there must be enough stack space to store the processor register contents for PX5 RTOS context switching. The application can enable stack checking and stack verification by building the px5.c source file with PX5_STACK_CHECK_ENABLE and PX5_STACK_VERIFY_ENABLE. The application code may also call the px5_pthread_stack_check API to determine how much of a thread’s stack has been used.
Too small of a thread stack can result in a system crash. However, too large of a stack for a thread wastes memory. Achieving an ideal balance generally favors wasting some memory for peace of mind.
To minimize context switching overhead, use as few thread priorities as possible. Or said another way, give a thread a higher priority if and only if you need it to preempt another thread. Threads that can execute cooperatively at the same priority level will require less context switching overhead.
In general, you should always check the API return code.
PDV stands for Pointer/Data Verification. With this unique technology, the PX5 RTOS can verify all function pointers before calling them as well as verify the return address on the stack. In addition, the PX5 RTOS data objects and memory pools can be verified against most sequential corruption. When corruption is detected, the PX5 RTOS central error processing is called.
Small subsets of APIs are available from Interrupt Service Routines (ISRs), including sem_post and mq_send.
The PX5 RTOS instruction area needs 1KB of flash for minimal usage. If everything in the PX5 RTOS is used, flash requirements could grow to20KB. Note that this automatically scales based on what APIs the application uses–no configuration is required.
The minimal RAM required is 1KB.
Yes. By default, the internal RAM needed to create internal objects (condition variables, semaphores, mutexes, message queues, etc.) is allocated from the memory supplied to px5_pthread_start. However, the application may override the internal memory allocation or even designate the internal RAM for each system object via object attribute (*_attr_setcontroladdr) APIs. Please refer to the PX5_RTOS_User_Guide.pdf for more details.
For professional, fully ticketed support please visit px5-rtos-tech-support.htm. We will be glad to help!
It means that the generic C code of PX5 RTOS is already certified (px5.c) as an off-the-shelf component and does not require any additional certification effort. The only portion of the PX5 RTOS that needs to be addressed with the application firmware is the set of PX5 RTOS binding code, which amounts to ~10 small assembly language functions.
The PX5 RTOS is certified to be used in safety critical applications that need to meet IEC 61508 SIL 4, IEC 62304 Class C, ISO 26262 ASIL D, and EN 50128 SW SIL 4 levels of functional safety certification.
The standard PX5 RTOS code base is certified. Even applications that don't need the formal certification benefit from all the effort to certify the PX5 RTOS.
The PX5 RTOS certification artifacts (safety manual, certification report, technical report, etc.) are provided as part of a licensed package. Please contact for additional information.