Why a Platform Approach?

Get To Market Faster with USB 3.0 Connectivity

Embedded systems developers have tight development schedules and tighter budgets. Using platforms allows them to reuse their development and test investment across a broader range of products, and over a longer period of time. USB 3.0 can serve as a connectivity platform for a wide variety of applications, allowing developers to get to market more quickly with products with new functions. A commercial USB software platform allows developers to reuse their applications across a broad range of software and hardware, and take advantage of the vendor’s ongoing development and validation path.

Automakers have used platforms for many years as a way of maximizing the return on design and tooling investments. Rather than design each model from scratch, automotive engineers typically create a core design, which is then varied and extended to create the final products. The same thing is often done in the embedded system world; companies design hardware platforms with a given CPU and peripherals, which are then reused across products. Companies often treat their Linux kernels as platforms for application development; they’ll standardize on a given version of Linux in conjunction with a given processor and chipset family, and then deploy it in multiple products. We can call these “bottom-up” platforms because they start from a very low level of abstraction and grow up. The components of a bottom-up platform are usually designed to the same set of design rules, and frequently depend intimately on the details of other components in the platform. For example, the USB stack for Linux depends intimately on the details of the kernel and the kernel APIs.

In the case of software, it’s productive to rethink the platform approach, especially as it regards open standards. A platform can be viewed as an abstract design pattern with several key goals. A platform can allow reuse of software built upon the platform across multiple products, in multiple operating environments (Linux, Windows, pre-boot environments, etc). A platform can also allow reuse of software built upon the platform as the implementation of the platform changes over time. Properly designed, a platform can greatly reduce the test and validation load by allowing most tests to be performed in more convenient environments than the target system (for example, it’s much more convenient to test USB implementations on Windows than on a typical embedded system).


Properly implemented, an abstract platform not only presents a stable set of APIs to client software – it also uses the abstract platform concept to isolate its core code from differences in CPU, compiler, operating system and hardware-implementation details. These abstract platform APIs allow the core code to be written with a minimum of conditional compiles – for instance, only for adding debug code. All other configuration decisions are made either at link time or at run time. By contrast, traditional free and open-source stacks are often a forest of conditional compiles.

Sometimes conditional compiles (and by extension, avoidance of a platform approach) are justified on the grounds of efficiency, either of code size or run-time execution. In our experience, however, these are not valid grounds. We have found that, generally speaking, conditional compiles are an example of “premature optimization.” First of all, except on the most critical paths, modern compilers are good enough that the performance benefit is minimal. Second of all, it hobbles verification. Each independent conditional compile option becomes a new dimension in the space of target configurations – the number of compilations for testing purposes scales exponentially with the number of compile options.

The benefits of avoiding conditional compiles are numerous. When using static code-verification tools, conditional compilation normally means that you must compile once for each target configuration. Conditional compiles are required for handling differences in compilers, but they should be confined to header files, where they can be used to select appropriate types for a given platform. For applications where extensive interoperability validation is required, code without conditional compiles can reliably be validated on a different platform. For example, a USB stack can be easily validated on Windows, and then deployed on embedded systems unchanged. The USB-specific portion of the validated behavior will not change.

MCCI’s TrueTask® USB is a portable platform for embedded systems that goes beyond a simple stack to provide APIs that are stable across releases and variations in hardware and operating systems. It enables reduced testing, reuse across multiple platforms, and overall lowered costs for manufacturers.

Abstract platforms are related to earlier software stacks. Software stacks were marketed as modules of code that provided specific functions, as a starting point for integration. They ranged from the simple RTOS kernel through TCP/IP stacks to complex cellular network and telecoms signaling stacks. Today, software stacks are typically provided by semiconductor vendors at no charge. Unfortunately, experience has shown that these free stacks do not necessarily meet the cost and time-to-market goals for embedded systems. According to Dr. Jerry Krasner, vice president and chief analyst, Embedded Market Forecasters (www.embeddedforecast.com):

  “ROI/cost of development data derived from detailed and extensive surveys of embedded developers has shown (year-over-year) that the use of commercial software, as compared with free or open-source software, results in a lower total cost of development, shorter time to market and better design outcomes. In a market where device manufacturers have a short window to launch new tablets, smartphones, and other portable devices, buying commercial software from a company that knows how to implement USB connectivity makes good business sense.”  

There’s a simple explanation for this: commercial software developers have a natural incentive to adopt the platform approach, because they have to support a range of customers and applications. Abstract platforms are hard to develop: they take a lot more effort, and they require a lot of architectural work that is not related to solving the problem at hand. Free and open-source software stacks are normally biased toward code that focuses on operating the hardware in question. Code from semiconductor makers is generally written as a sales tool, to show that their chips work, and to demonstrate coding sequences. In this case, the business goals naturally argue for less abstraction, not more. Non-commercial open-source software has similar constraints. Generally, the developers have no commercial incentive to worry about the maintenance or support of their code. Furthermore, generally speaking, in an open-source environment there is no design review team to enforce the rules and maintain a consistent architecture over time.

Using a platform approach can be compared to using automated design tools. There is an initial cost to adopt the approach, which usually falls on the first project to adopt the new methodology. But if the methodology is properly designed, subsequent projects (whether updates of the original project, or new projects in the same organization) will see substantial savings. With a platform approach, the cost may be substantially reduced if the vendor has already ported the platform to the target environment. Nevertheless, there is always a learning curve involved with the adoption of new and sophisticated software. This learning curve is why managers often prefer to stay with the known approaches.

With open connectivity standards such as USB, however, the test, verification, and support advantages of a platform approach are so large as to make the adoption costs seem relatively trivial. Billions of USB devices have been shipped. There are hundreds of thousands of different kinds of devices. A platform approach, combined with a commercial test strategy based on deploying the same stack in production on Windows systems, allows the platform customer not only to maintain their software investment, but also to have great confidence in the stability and compatibility of the core stack. An embedded stack that has also been commercially shipped as part of Windows systems will have been tested by the software vendor, the silicon vendors, the system vendors and by USB-IF. The testing will have covered commercially important products, which may deviate significantly from the ideal. For example, USB 3.0 hubs vary widely in the quality of implementation and conformance with the standard. Although all can be made to work, there is a lot of practical knowledge that can only be gained through testing. Using a platform approach gives the greatest confidence that the results gained in Windows testing will apply directly to deployments in an embedded system.

A platform approach therefore helps with time to market in two ways. It enables rapid adoption of a known-good USB software stack, saving test and validation time; and it thereby allows designers to access the full spectrum of USB 3.0 products (products using low speed, full speed, high speed, and SuperSpeed USB, and chips using HSIC USB and SSIC USB), thereby saving design time.



Terry Moore founded MCCI in 1995 and is the CEO. He has 35 years of experience designing and implementing computer system software and holds six hardware and software patents. He is recognized as one of the leading experts in Universal Serial Bus (USB) technology. His MCCI blog is "Making Connections." (https://forums.mcci.com/index.php/making-connections/blogger/listings/tmm/)

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis