IES: Express Logic is claiming more than half a billion ThreadX kernels deployed – congratulations on that. With so many choices for RTOSs out there, why do you think you are seeing this kind of success?

1. It’s royalty-free. This means that manufacturers do not pay any per-unit charge for its use, which appeals to high-volume products where royalty charges would affect very critical material costs. Thus, we enable manufacturers to avoid royalty charges and keep manufacturing costs to a minimum.

2. Success begets success. Manufacturers who see that an RTOS has been used in many devices are more interested in using it themselves. ThreadX is field-proven in many devices, making it a low-risk choice for an RTOS. That is critical to a product’s success.

3. It’s easy to learn and use. This aids developers in meeting schedules and getting products to market quickly. In today’s highly competitive marketplace, product development times shrink to 3-6 months, leaving little time to learn how to use a complex RTOS. ThreadX is less complex than most RTOSs and Linux[], making it desirable for the short time-to-market requirements often associated with high-volume products.

4. It works. I’m not meaning to sound trivial, but not all RTOSs actually work in demanding real-time situations. Some fail due to their inability to service more than a certain number of threads, some thrash in situations involving multiple nested interrupts, and others just have bugs. With millions of deployments, ThreadX has run in countless situations, stressed to a greater extent than any less commonly used RTOS, and users know it will work for them based on its reputation and endorsements from previous users.

(click graphic to zoom by 1.2x)

ThreadX is used to perform one or more of the functions the SoC includes, such as wireless radio management. Its small memory footprint (as small as 2 KB) enables it to meet such demands with minimal memory consumption. That in turn enables the SoC to keep memory size to a minimum, helping reduce power consumption and extend battery life for portable devices.

ThreadX generally is delivered in source code form, enabling SoC manufacturers to configure it to suit their needs and bundle it in flash or ROM. We support all the major 32-bit architecture cores (ARM, Freescale, MIPS, Renesas, ARC, Altera, Analog[] Devices, AMCC, Tensilica, Atmel, Luminary, ST, NXP, Cirrus) and the Microchip 16-bit PIC24/dsPIC, as well as many DSPs and digital signal controllers. These ports are driven either by customer demand or semiconductor manufacturers who fund us to provide support to assist them in winning design opportunities.

IES: That’s quite a list. I’m curious – in your view, do engineers pick their favorite SoC architecture first, then come looking for an RTOS? Or do they choose ThreadX and then look for an SoC to accomplish the job at hand? Explain how the choice starts.

CARBONE: That’s a great question. Developers usually have to select three components for a design: a processor (architecture), development tools, and an RTOS. Not all designs use all three, but most 32-bit-based designs do.

Generally, the architecture is selected first for a new design, but often the tools or RTOS can dictate a short list of contenders that support those software elements.

For follow-on development, the software typically rules the roost as it represents the most costly element to construct. And, once software is constructed for a product, there is great motivation to reuse it on a new product.

Developers often abstract the software interface to enable any RTOS to be used underneath and likewise abstract the hardware to enable replacement with a less expensive or more powerful alternative that can run the same software. So we see many such software "abstraction layers" that enable these three elements to be modularized and independent.

IES: Which RTOS are people coming from when they choose ThreadX: raw C, another RTOS, or Linux? What’s usually driving their move?

CARBONE: In most cases, it’s from another RTOS, and developers migrate to ThreadX for its smaller size, faster performance, lower royalty-free cost, or better ease of use.

After that, it’s from raw C with an in-house RTOS or no RTOS at all. Those developers migrate to us when their application gets too complex to manage without an RTOS, but they don’t require a "complex" RTOS with hundreds of services and a large memory footprint.

Also, some try Linux and decide it isn’t going to work for them because of its large footprint, slow real-time performance, complex structure, demand on the processor, or legal entanglement, and then they settle on ThreadX.

Each group has its reasons for using us, and we see business from all of them.

IES: What are engineers asking you for most in terms of feature support on SoCs, and how are you responding to that demand?

CARBONE: I’d say networking and USB. For networking, IPv6 is becoming a requirement, but basic TCP/IP is the staple. In the USB area, host and device support with classes for HID [Human Interface Device], storage, and audio seem to be commonplace.

John A. Carbone, VP of marketing for San Diego-based Express Logic, has 35 years of experience in real-time computer systems and software, ranging from embedded system developer and FAE to VP of sales and marketing. Prior to joining Express Logic, he was VP of marketing for Green Hills Software. John has a BS in Mathematics from Boston College.