| Streamlining development for customized embedded devices |
by Mike Hall (Mar. 7, 2006)
Application developers don't need to reinvent the wheel every time they write an application. Tools and application development frameworks have progressed to the point where application developers can focus on their added value, not on the underlying application plumbing/infrastructure. Can we consider Embedded systems development to be heading in the same direction?
Developers have the task of creating hardware/software solutions with limited time and/or resources, this being the case; developers should focus their time and efforts on the added value for their product, not on the underlying plumbing.
Looking back several years, embedded systems typically ran on custom hardware and were hand-coded in assembler, these systems didn't require communications technologies or security infrastructure (how times have changed!). These systems ran as stand-alone devices perhaps in many cases running without an underlying operating system, in effect the system would run a dedicated single task or process (this can of course also be true with today's devices), the developer would be responsible for all aspects of the system, interaction with underlying hardware, and user input/output (if needed). Every aspect of the device would need to be coded by the developer. Typically, the application developer would need to be extremely familiar with the underlying hardware, and perhaps may have been involved in the hardware design.
Over time, developers have moved from coding portions of their operating systems in pure assembler, perhaps moving to higher level languages such as C/C++ and even making use of software libraries to assist with common software development tasks (string manipulation, file I/O, graphics, audio and video etc.). Many well known software development tools ship with libraries that assist with application development, Borland OWL and Microsoft Foundation Classes (MFC) are both good examples of application development libraries that abstract a developer from the underlying operating system APIs and provide functions or classes that provide support for common programming tasks. These libraries can be considered to be a shim layer that sits above the operating system and below the application, in many cases application developers are still responsible for controlling object lifetimes, thread and memory management.
Many application development libraries are simply shim layers between an application and the underlying operating system, and many libraries ship with source code, so it's possible to see how the library works, and through examination of source, determine how quickly the library will call into native operating system APIs. The additional benefit of having application development libraries that ship as source is the ability to extend the functionality of the library. Taking application development and operating system abstraction model one step further we can also see application development models that are (for the most part) operating system and processor independent, Java and .NET are both good examples. In this model the application developer is further abstracted from the underlying operating system, object lifetime is handled by the application runtime environment (JVM or .NET runtime), classes, objects, events, and methods bear little to no relation to the underlying operating system APIs. In much the same way that application developers have accelerated product development by moving from assembler to C/C++ additional gains can be found by moving from C/C++ to managed application development.
A side effect of moving application development from Assembler through C/C++ to a managed application development environment is the abstraction from the underlying hardware. Application developers (for the most part) don't need to know about the specifics of the underlying hardware. A hardware abstraction layer, coupled with a device driver layer shields an application from the exact implementation of hardware. For example, a serial port might be implemented as a UART or FPGA, the driver takes care of the hardware specific issues, the application simply requests access to the serial port without needing to know the hardware specifics. The same is also true of graphics, audio, and many other peripherals.
But how does this relate to embedded operating system development?
As embedded device developers we have the ability to choose the operating system and tools used to develop a device. There is a trade off that needs to happen when choosing the hardware, operating system (if needed), and application development tools. The equation can be complex, the decision process can of course be driven by both business and technology issues but mostly boils down to time, resources, and cost. Anything that can be done to reduce any of these three items can benefit your development project.
Where is the value of your specific embedded system? Perhaps the user interface, the applications, processes or services running within the device, and perhaps the servers that drive content to/from the device. This might seem to be obvious, your developers should focus development time on the applications and technologies that add value to the device. But what about thread management, memory management, networking stacks, media players, Web Browsers and various servers technologies? These are technologies that are typically provided by operating systems. Does it make sense for your development team to spend valuable man months developing a TCP/IP stack thats 5kb smaller and 10 percent faster than a commercially available TCP/IP stack? Or perhaps working on updating your operating systems Web Services to comply with the latest specifications?
The question is whether it is a good use of your development teams time writing, developing, testing, and maintaining components at this level of the operating system? Probably not.
One question to ask is "Where do I want to spend my time/effort when building my embedded system?" There are of course a number of answers to this apparently simple question. One could spend time close to the hardware, perhaps writing the Hardware Abstraction Layer code (if needed) for your embedded system, building operating system infrastructure code and other low level support code, or your team could spend their time at a higher level, customizing the end user experience and adding your product-specific Intellectual Property to an existing operating system.
Hopefully you can see a parallel between the progression in application development technologies and the direction of Embedded Systems design and development.
There are a number of operating system choices, perhaps you have an in-house developed operating system that you've been developing and growing over a number of years, perhaps you are using a commercial ‘desktop' operating system, a commercial embedded operating system, or using an open source operating system. In each case there are a number of decisions that need to be made to determine the best choice of operating system for your specific embedded device. Choices can include footprint, processor support, native hard real-time support, breadth of supported hardware devices (or reference hardware), access to source code, and whether there's a community of developers and partners to assist you with the development of your embedded system.
Time to market is increasingly important; one way to reduce time to market is to focus your time only on the added value portions of your device. But what about the operating system? Embedded operating systems come in a number of shapes and sizes, from "here's the source, go build a tool chain, and then go build a device" through to "here's a full operating system image, just write your applications and you're done." I would suggest that at one end of the spectrum you will be wasting valuable man hours building and configuring the operating system and tool chain, and the other extreme is rapid device development and time to market.
Let's examine two options, the first is to use a shipping commercial operating system and an off-the-shelf reference board (after all, people have been building embedded devices based around CPM/80, MS-DOS, OS/2, and Windows 3.x through to Windows XP for some time now). The advantage in this case is that you get all of the operating system features and can simply layer your application, services, and drivers onto the operating system and you're done. The disadvantage with this approach is that you get all of the operating system features. This can mean that your operating system image is larger than you might need, contains features that your embedded system doesn't use (media player, web browser, networking features etc…) and may not be tailored for embedded systems use (boot from read only media for example).
The second option is to use an operating system that can be customized to suit the needs of your embedded design, a componentized operating system if you like. Perhaps the ability to boot from flash, fast boot times, support multiple processor architectures, native hard-real time support, footprint size are all important for your design. There are of course a number of other reasons why a full desktop operating system or operating system build for the server market may not be suitable for your embedded device. Perhaps a range of operating systems that expose device specific features would be ideal to match the needs of a wide and varied embedded systems marketplace. Windows CE and Windows XP Embedded are examples of componentized embedded operating systems from Microsoft that complement each other through the support of processors, hardware, real-time, networking and media technologies.
Note that customized doesn't have to mean that it's difficult or time consuming to configure the operating system you need for your device. A typical Windows XP Embedded design from concept to shipping is in the order of 12-14 weeks!
An install of Windows XP Professional SP2 takes approximately 1.5GB of hard drive space. This is because Windows XP is a general purpose desktop operating system that supports a wide range of hardware devices (isn't plug and play cool!) and end user applications. There is a version of Windows XP Professional SP2 available for Embedded systems, called Windows XP Embedded. The operating system has been componentized, divided into approximately 12,000 components, 9,000 device drivers, and 3,000 operating system features. Embedded systems developers can choose the individual components or technologies needed for their embedded device. In this case you get all the benefits of the latest in networking, multimedia, and security without the need for a full operating system install.
Windows XP Embedded uses the same underlying hardware as Windows XP Professional, meaning that the hardware will be based on the x86 processor and PC Architecture. Of course the boot media requirements are completely different. Windows XP Embedded can boot from the network (PXE boot), from CD-ROM (El-Torito), from flash, or from a hard drive. Since the operating system has been componentized, its footprint can be tailored to suit the needs of your device
One of the advantages of using an operating system such as Windows XP Embedded is the range of supported hardware and software. Any driver or application that runs on Windows XP could also run with Windows XP Embedded (assuming that the appropriate operating system dependencies are included into the operating system image). This leads nicely onto dependencies.
When building an embedded operating system image you may know that your user interface, applications, or services rely on specific operating system features. Taking the time to add these features and knowing all of the operating dependencies would be a time consuming process. Tools that ship with Windows CE and Windows XP Embedded contain a catalog of operating system features (known as components), each of which ships with dependency information. Here's an example, let's say that you're using Windows CE and want to include the HTTP Web Server, which is approximately 80kb in size. You would add this component from the catalog to your workspace, when you add this component its dependencies will automatically be added.
Below we can see the Catalog Dependencies for the Windows CE HTTP Web Server.
Using components, dependencies and operating system configuration templates, embedded operating systems can be rapidly configured and tested. Taking a new x86 based reference board, configuring, building, and booting a Windows XP Embedded operating system can be achieved in less than thirty minutes. Configuring, building, and booting the Windows CE 5.0 operating system within the Windows CE Emulator or on a board that ships with an appropriate BSP can also be achieved in less than 30 minutes.
We've seen that application developers have the luxury of using application development tools and frameworks that accelerate their time to market. Using componentized embedded operating systems also reduces time to market. Imagine what happens when you combine the latest in application development tools and programming frameworks with the latest in componentized embedded operating systems!
Copyright © 2006 Microsoft Corp. All rights reserved. Reproduced by WindowsForDevices.com with permission.
 About the author: Mike Hall is Technical Product Manager in Microsoft's Mobile and Embedded Devices Group, on the Windows Embedded team. Among other things, he writes an extensive (and often entertaining) blog that's published on Microsoft's MSDN developer website.
Related stories:
(Click here for further information)
|
|
|
news feed
