Seminar Report On EMBEDDED LINUX

Linus Torvalds has been insisting for some time that a prominent part of Linux's future lies in embedded systems, a rather unglamorous child of the computer world.

That future appears to be now, as multiple vendors announce products that extend Linux squarely into the suddenly-hot world of embedded systems. Already we're seeing a race to market, pitting companies with existing products against firms with experience in the embedded field which have upcoming Linux products.

As microprocessors have become smaller and cheaper, more and more products have microprocessors embedded in them to make them "smart". Such products as VCRs, digital watches, elevators, automobile engines, thermostats, industrial control equipment, and scientific and medical equipments are driven by these microprocessors and their software. People use the term 'embedded system' to mean any computer system embedded in any of these products. In an embedded system, the actual programming work is done on a system other than the system on which the software will eventually run. The system that you may ship may or may not have a keyboard, a screen, a diskdrive and other peripherals necessary for programming. Therefore most programming work for embedded system is done on a host, a computer system on which all programming tools run. Only after the program has been written, compiled, assembled and linked, it is moved to the target, the system that is shipped to customers.

2. Why embed Linux?

            The power, reliability, flexibility, and scalability of Linux, combined with its support for a multitude of microprocessor architectures, hardware devices, graphics support, and communications protocols have established Linux as an increasingly popular software platform for a vast array of projects and products. Use of Linux spans the full spectrum of computing applications, from IBM's tiny Linux wrist watch to hand-held devices.(including PDAs and cell phones) and consumer entertainment systems, to Internet appliances, thin clients, firewalls,  equipment, . . . and even to cluster-based supercomputers.

2.1 To pay, or not to pay . . .

            Then there's the question of commercial vs. non-commercial (open source) software. This might be an important philosophical issue for you or your company. You (or your company) may want to restrict your Linux-related activities to using exclusively open source software, so there are no licensing restrictions or royalty requirements, or so that you have the flexibility to supply source code to your customers. Or, you might prefer to take a more pragmatic approach, using (and sometimes licensing) whatever software components best match your application's needs -- whether proprietary or open source.

            Either way, whether you decide to use pure open source, or to mix open and proprietary software components, using Linux in embedded applications is unlikely to be totally "free" of costs. You'll need to either invest time and resources to create your own implementation, or spend money on tools and/or licensed components, or pay for outside services and support.
hat said, there are certainly a wide variety of excellent open source tools and utilities which you can download free of charge; and, there are also excellent proprietary tools and utilities which, if you choose to use them, you must license or purchase from their suppliers. Then too, bear in mind that the companies who offer "commercial" Embedded Linux distributions generally possess a high level of expertise and have well trained staff ready and waiting to assist you with your project -- for a price.

            Paying money to one of the "commercial" Embedded Linux suppliers can have many advantages, including development tools, useful utilities -- and, of course, support. Most commercial suppliers of Embedded Linux distributions are busy investing in the development of tools and services that will differentiate their Linux offerings from the pack, in order to advance their standing as a prospective partner for companies building Linux-based embedded applications. In many cases, these commercial Embedded Linux distribution suppliers are also making significant contributions to the overall pool of open source software.

2.2 Searching for Solutions

            Taken as a whole, there are a great many options -- both open source and proprietary -- which fall into the following categories . . .

·        Linux kernel implementations -- a wide range of shapes and sizes of Linux, including reduced footprint implementations, versions that do not require the presence of a memory management unit (MMU), and enhancements and add-ons to support the "hard", "firm", or "soft" real-time responsiveness of performance-sensitive applications such as streaming media, IP telephony, and robotics.

·        Windowing and graphics environments -- modules, add-ons, drivers, and utilities to support the graphical display needs of embedded applications, including graphical user interface (GUI) toolkits, window managers, and browsers which vary in size, appearance, features, and capabilities.

·        Drivers and utilities -- software support for the unique hardware, software, and functional requirements of Linux-based embedded applications including telephony equipment, multimedia devices, mobile computing, wireless capabilities, data acquisition and control, and more.

·        Tools -- software that simplifies and automates the process of generating a Linux configuration that is tuned to a specific embedded system's requirements, assists the developer in debugging and tuning the system configuration, provides remote system maintenance and support, and more.

3. The evolution of embedded computers

            You don't have to go too many years back to recall a time when designing and building embedded systems was a relatively uncomplicated matter. Not that the process was easy -- there simply weren't many choices to make. Combine a few inputs and outputs with some time critical components and, voila, you had an embedded system.

            As you can imagine, limitations in component choice resulted in functional limitations. Those components available to the design engineer dictated the types of designs the engineer could create, setting off a domino effect that limited overall system performance. Because they were the only kind available for embedded applications, most embedded systems were run with relatively simple 8-bit microcontrollers, the limitations of which forced designers to make significant functional tradeoffs. These limitations, in turn, restricted overall system function and performance. After all, with a slow microcontroller there's no point in adding fast memory. And with only 64KB of available memory, there's only so much the system can do.

            Adding a second microcontroller to divide some of the processing load was one solution to the problem, but it was the real-time requirements that drove overall system design and functionality. Limited CPU resources, speed and memory kept multi-tasking to a minimum in order to prevent compromising real-time system response.

            On many of these early systems, human interaction was limited to keypads or sensors, which were either polled or interrupt-driven in the system. Outputs were limited to LED indicators or simple serial character displays. These systems were not extremely interesting -- or powerful for that matter. These were the days of the 'deeply' embedded devices: relatively simple devices that did not require much human interaction or control. Turn them on and they went to work, sometimes for years at a time.

            As more and more powerful CPUs became available to the embedded designer at lower and lower prices, more powerful systems with more features were able to be built, but there was always a sharp divide between what could be used on the traditional desktop computer and what could be run on a small, resource-limited, embedded device.

            Now, by combining powerful CPUs with much higher memory densities, this divide is blurring. But consumer demand for more powerful handheld computers, MP3 players with more memory, and two-way pagers with cooler interfaces demands a more complex, multi-tasking operating system that can juggle the load seamlessly, and allow interfacing from a human user just as if the user were a high priority interrupt.

            This evolution defines a realm where Linux is the embedded operating system of choice.

3.1 Hard Real-Time vs. Soft Real-Time

            There is some debate over what constitutes "real-time" operational requirements in any particular system or environment. There is a difference between the real-time requirements of the Mars Polar Lander control system and the real-time requirements of a vending machine.

            Strictly speaking, most devices that interact directly with humans are classified as "soft" real-time. There are, of course, exceptions to every rule. For example, a pilot's interaction with the controls of a jumbo jet are certainly "hard" real-time. But if a web page sometimes takes a few more seconds to load, the world will not come crashing to a halt and people will not be hurt. This is the realm of human-interactive embedded devices, and an example of an environment where Linux can be very effective.

            Linux is not a real-time operating system, but in many applications, lack of real-time performance is not a deal breaker. Linux tends to be a better fit for devices that are considered 'not-so-deeply' embedded, or devices with relatively high levels of human interaction. Linux is also a robust and reliable player in networking applications.

3.2 Let the fun begin

            Once a project team has decided on Linux, the fun begins. Because many ports are available for Linux, it is easier to start with than operating systems that require building upon or modification for the specific application at-hand.

            Also, because Linux is open source, the developer has far-reaching debug capabilities -- a feature that is often far more valuable then many tech support plans. Many times, issues that arise can be debugged because the developers have all of the source code. Support questions that come up often involve simply pointing developers in the right direction to find the right code to see which control is where in the source tree.

            Having source code also gives the development team protection from software problems over which they have no control. Linux provides explicit control over all of the software elements in the project. Any developers who have waited for a vendor to fix an annoying bug in a library understand the real value in having the source code.

3.3 The power of networking

            Linux was made to run on a network, so for a networked embedded device, it is simply a matter of configuration to turn these modules on, and get the right drivers running to talk to the hardware. There are kernel configuration tools available to the developer, making this task relatively straight-forward.

            Many of the required drivers have already been written and are available in the open source realm. Some vendors even supply entire development kits which not only contain all of the drivers, but already have the complete development environment integrated so that developers may start immediately with their software implementations.

            The network stack is another big portion of the Linux equation. Linux is known for its strong networking performance and robustness. The Linux stack contains essentially the same interface found in Unix. The same socket calls can be made, and useful return and error codes are present. Running a Linux stack pretty much guarantees a compliant stack, and if bugs are found that cannot be resolved in the source by the developer, the community is usually quick to address them. Source availability can be added by the development team if a special networking function needs to be because they have the source code. This means a device can respond in an application-specific manner when prompted by the special initialization packet of the design.

3.4 Tailoring Linux to the embedded application

There are three tools in common use for configuring the kernel: make config, make xconfig, and make menuconfig. Each of these tools essentially do the same thing: configure the Linux kernel. Although many applications may be able to forego the process of configuring the kernel, every Linux development effort should, at a minimum, scan the contents of the kernel and classify each element as necessary or not.

            Embedded systems must be concerned about overall memory footprint, and trimming the kernel is a great place to start. Only system-essential elements should be present in the kernel. If the embedded device does not have a SCSI interface, then SCSI support should be removed from the kernel.

            The first step in configuring the Linux kernel for your specific target is in understanding the directory system used on the Linux development platform. The following subdirectories will be present on most Linux development environments under the top-level directory . . .

/arch -- This directory contains the code that is specific to the architecture. Each supported platform will have its own subdirectory like arch/i386, or arch/armnommu.

/drivers -- this area is further broken out into specific types of drivers, like block, char, cdrom, or scsi. There is a sub-directory for each major type. This is where you would add your own code needed for your specific target.

/fs -- this directory contains all of the support code for file systems like ext2, minix, or even msdos.

/include -- this directory contains all of the needed header files. It is further broken down into architecture specific sub directories, much like the arch directory.

/init -- this optional directory can contain the bootstrap code, which runs when the target is first powered on.

/kernel -- this contains the main kernel code including the scheduler.

/lib -- this contains the architecture specific library code.

/mm -- this directory contains the memory management code.

/mmnommu -- this is the version of the mm directory used for processors that do not contain an mmu, like 68K, or some arm processors.

            The kernel build process is not a straightforward process and can get complicated quickly. Since there are so many make files and subdirectories and code trees, it is probably easiest to keep the build process automated. Using a script to make sure the build process is done exactly the same way every time is recommended. A script can also make and check the dependencies so the developer can focus on other more interesting parts of the code. In the NetSilicon NET+Works 32-bit RISC product, ported to uCLinux, the kernel build process is automated in this way. The entire build for the kernel is contained in a single build.sh script file. This ensures that every time the build is done, it is done correctly and exactly the same way as before.

3.4.1 Drivers

            Usually, it is easiest to find drivers that have already been written and then port them to your target. If the development team has purchased an integrated Linux development environment, such as the NET+Works uCLinux development kit from NetSilicon Inc., the development kit should contain full BSP and drivers for most all components in the hardware. This is the best place to start when doing the development. At a minimum, a provided package should include an Ethernet driver, a couple of different serial drivers, and drivers for whatever other hardware exists on the system.

            The sources for these drivers is contained in the arch/drivers directory and are placed according to major grouping, whether they be char drivers, block drivers, or SCSI drivers. Driver code added to a project would most likely go into this directory structure and be added to the driver makefile that would then be built into the kernel using the build.sh script file which builds the entire kernel directory structure.

3.4.2 Memory Requirements

            All embedded microprocessor systems must go through the process of defining what the memory requirements of the system will be. Most importantly, how much ROM and RAM are needed in the system. For smaller systems with less functionality, less memory is usually required. It is perhaps one of the more difficult aspects of designing with Linux to determine minimum required memory, but has the single biggest impact on recurring product costs (being that Linux is royalty-free), so it is critical to the final design.

            Some designs may be able to run with as little as 256KB of ROM and 512KB of RAM. Much tweaking and snipping will need to be done to develop such a system, and there would likely be little room left for the application or any graphics for web pages. This system would truly be somewhat limited and might not be a good fit for a Linux device.  A more typical memory space is on the order of 2-4 MB of ROM, and 4-8MB of RAM. This system allows for a fully functional kernel with various drivers built in, and a shell program to allow remote users to log into the system. Such a system also becomes a more versatile development platform that can reduce the costs for follow on projects using the same platform.

4. What's so good about open source

and Linux -- in embedded?

            Throughout 2000, LinuxDevices.com conducted a survey of developers to try to understand their motivations for using Linux in embedded systems and intelligent devices. Some of the most interesting results are in the areas of reasons for wanting to use open source software, and the perceived strengths and advantages of Linux.

You might think the simple answer would be "Because it doesn't cost anything!"
Not so!

4.1 What do you value most about open source?

            Developers were asked to select their "most important", "second most important", and "third most important" reasons for using open source software in embedded applications from among these choices . . .

·        So I can add functionality directly within the OS

·        It represents "insurance", even if it's never needed

·        It facilitates debugging and troubleshooting the application

·        It allows fully understanding what's going on inside the OS

·        It lets me immediately fix OS bugs, in case they arise

·        To eliminate dependence on a single OS vendor

·        The collaborative open source development process produces superior software

·        I don't need or want open source

·        Other

Each of the selected reasons was weighted according to whether it was designated "most important" (5 points), "second most important" (3 points), or "third most important" (1 point). Then, the results were combined and normalized such that the top reason ended up with a score of 1.0.The following graph shows the results.

These results are intriguing in several respects. First, the popular notion of programmers hacking away at source code to create custom versions of Linux was not borne out by the survey. Instead, developers place a high value on having source code as a way to avoid being held hostage to proprietary OS providers. Also, having source code makes it much easier to find out what's going on inside the system. Choices like "so I can modify the software" and "so I can fix bugs" did receive a fair number of votes, but in the overall scheme of things these ended up at the bottom of the list.

            Interestingly, the reason that topped the list was "the collaborative open source development process produces superior software." What's especially significant about this finding is that it's not something that proprietary software vendors can emulate without fundamentally altering their business models -- something they are highly unlikely to do.

4.2 Free beer vs. free speech

            One particularly intriguing outcome is that despite the obvious cost-sensitivity of embedded devices, the "free speech" aspect of Linux (i.e. source code is available) edged out "free beer" (i.e. no royalties) as the primary reason why developers are looking at embedding Linux for their designs.

4.3 Other reasons for liking Linux

            The survey also asked developers to identify their main reasons for wanting to use Linux in embedded applications. Here, the respondents were asked to select all of the reasons they felt were important from among the following choices . . .

·        Source code is available (and free) %

·        It's not from Microsoft

·        Linux No runtime royalties

·        has excellent networking support

·        There are more drivers and tools available

·        Lots of programmers are familiar with Linux

·        Linux is more robust/reliable

·        Other

To delve a bit deeper into the cost issue, we asked a pair of questions related to costs . . .

·        "Would you consider paying for Linux development/support services?"

·        "Would you consider paying per-unit royalties?"

The results appear in the following two graphs.(Note: the second question was added more recently, so the results shown here are based on a relatively small sample of data.)

What we learn from this is that while embedded developers are indeed prepared to invest money in outside services and support for embedded Linux (68% said yes, and only 13% said no), the numbers are nearly flip-flopped when the question is about willingness to pay per-unit royalties (51% said no, and only 21% said yes).

5. Update on the Embedded Linux Market

(Oct. 2001)

            In short, two years ago (1999)the "Embedded Linux Market" simply didn't exist.  Much has changed since then. Numerous companies have jumped on -- and off -- the fast-moving Embedded Linux bandwagon, which seemed more like a rocketship much of the time. The technology and Linux stock "market bubbles" offered plentiful investment capital and fueled unnaturally rapid growth of Linux companies (including a handful of Embedded Linux companies) beyond their ability to sustain themselves from actual revenues. For some, the bursting of the bubble left them either out of business or in search of different businesses. For others, it meant tightening the belt and settling down to a more traditional business model.  Throughout all of this, though, the benefits of using Linux in smart devices and embedded systems have not only persisted, but grown exponentially. The newly established Embedded Linux vendors have provided new tools, OS extensions, middleware, and support to enhance the value of using Linux in embedded applications. In parallel, "ordinary" Linux itself has evolved at a rapid pace.  And the result has not been missed by those who make the design decisions. The following recent market studies and overviews testify to the growing prominence of Embedded Linux as the embedded OS of choice . . .

6. VDC forecasts strong growth for Linux

 in embedded

            Driven by the growth of the Internet and the increasing ubiquity of embedded computing systems, the embedded market is exploding in terms of a proliferation of products requiring embedded technology with new, increasingly complex applications for embedded devices. A new market study by Venture Development Corporation (VDC) forecasts a significant increase in shipments for embedded GNU/Linux operating systems, software development tools, and related services.   VDC research reveals that use of embedded GNU/Linux operating systems is increasing as developers seek access to source code, reduced licensing costs, and the reliability, networking support, and modularity of the operating system. The open source community represents a powerful movement and development model in the computer industry, driving innovation by providing a robust body of software offering solutions to many different problems. Open source licensing offers embedded developers reduced development costs, reduced product costs, and the opportunity to get their product to market quickly. 

"Embedded Linux vendors, such as Lineo, MontaVista, Red Hat, and LynuxWorks, are branding distributions and adding value to the platform, while supporting a breadth of microprocessors" says Stephen Balacco, Embedded Systems Analyst at VDC. "Linux vendors have invested in an infrastructure to deliver technical support, maintenance, and a comprehensive suite of professional services for life-cycle support, allowing their customers to focus on differentiating their product."

            While embedded Linux distributions include the standard GNU software development tools (i.e., compilers, linkers, debuggers, etc.), VDC research reveals that a lack of development tools is the most important factor cited by embedded developers inhibiting their adoption of Linux for use in future projects. Embedded developers recognize the benefits offered through these products that drive product development productivity and produce higher quality code, while reducing development costs and critical time-to-market. Leading software development tool companies such as I-Logix, Metrowerks, Green Hills, IBM, and others have recognized the increase in interest from embedded developers in using Linux and are strategically adapting their product offerings for use with Linux in embedded projects. VDC expects that the trend toward software development tool companies supporting Linux will continue, or else they will miss the market opportunity that embedded Linux presents.

7. Study finds 300% growth in embedded Linux development Jul. 30, 2001

            Santa Cruz, CA -- (press release excerpt) -- From household appliances and consumer electronics gadgets, to controllers used in aviation, factories, and automobiles, application-specific devices have become a new frontier for Linux, according to a new report published today by software industry analyst Evans Data Corporation.

            The Evans Data "Embedded Systems Developer Survey," released today, shows a dramatic change in the software content of the microprocessor-controlled devices in the workplace and in our homes. Based on a survey of more than 500 embedded systems developers, the comprehensive report projects a three-fold increase in Linux-based projects in the next year, as part of a shift toward commercially available operating systems rather than those developed in house.

            "Embedded Linux has captured the attention of the development community like few other phenomena," said Tom Williams, Evans Data's Embedded Systems analyst. "Developers are open to new technical approaches and are willing to move to them once they are convinced that they will satisfy key demands for performance, cost effectiveness and time-to-market."

            The study also found keen interest in tools and products that can help developers get their projects completed correctly and on time, suggesting that inefficiencies endemic to this industry are gradually being overcome. Two-thirds of the developers reported a high incidence of embedded projects that are started and never completed, as well as a high proportion of projects delivered late.

Of developers polled in the June 2001 survey . . .

·        More than 45% expect to release a Linux application in the coming year; 14% have already released a Linux application

·        More than 80% said Linux is important to the embedded system development community

·        Open source code, royalty-free licensing and a large community of knowledgeable developers were cited as Linux's key benefits

·        Factors slowing Linux adoption include lack of specific board support packages, availability of device drivers and fragmentation of the code base

·        Some 15% of developers report that between 26% and 50% of their projects are never finished. Forty-one percent report that up to 25% of projects are abandoned

            The "Embedded Systems Developer Survey" looks at multiple facets of embedded systems development, including hardware and software platforms, Linux, Java, and open source software, types of applications, embedded databases and development tools.

8. Developer interest in Embedded Linux skyrockets Rick Lehrbaum (Apr. 10, 2001)

            According to the results of a subscriber study recently conducted by Embedded Systems Programming magazine, developer interest in using Embedded Linux appears to be growing at an astronomical pace. Emerging from virtually nil in 1998 and 1999, the percent of developers considering using Embedded Linux for new projects has zoomed to the number two spot (38%) -- second only to market leader Wind River's VxWorks.

            This is especially significant in light of the fact that more than 80% of the microprocessors manufactured each year end up in embedded, rather than desktop computing applications. Typical embedded applications include industrial control, telecommunications, military systems, avionics, medical equipment, point-of-purchase systems, and consumer electronic devices.

8.1 Which embedded OSes are you considering?

            The chart below summarizes the responses to the question "Which 16 or 32-bit vendors would you consider when purchasing RTOSes or kernels for your embedded projects?" The top six choices are shown here, sorted by their 2000 ranking.

8.2 Which embedded OSes have you used in the past 12 months?

            The results of the survey also indicate that developers aren't just thinking about using Embedded Linux in their projects -- they're using it, too. In answer to the question "Which 16 or 32-bit RTOS or kernel vendors have you used in the last 12 months for your embedded designs?", Embedded Linux jumped from essentially unmentioned in 1998 and 1999, up to 4th place (12%) in 2000. The following chart shows the top six OS choices in response to this question, again sorted by their 2000 ranking.

9. Linux's future in Embedded Systems market

This paper is a brief summary of VDC's analysis of Linux's future in the embedded systems market. The base year for market data and analysis is 2000, with a five year forecast period through 2005. In this study, VDC presents data on the merchant market for embedded Linux operating systems and software development tools. The merchant market is defined as products produced and sold in the open market. It does not include products developed in-house by OEM developers for use in their own products.

9.1 Market Overview

            The overall embedded market is undergoing a major transformation both in design and functionality. Networking technologies are becoming increasingly more important for embedded developers. Driven by the proliferation of the Internet and the increasing ubiquity of embedded computer systems, devices that can communicate with other devices are becoming dominant in the embedded market.

            The Linux operating system has been available for years for servers and desktops, and has continued to gain market share in both of these computing segments. Helping to drive this growth and lend creditability to Linux are well established companies such as IBM, Dell, Hewlett-Packard, Compaq, Oracle, and others. Linux, originally developed for the desktop and adapted for servers, is now making in-roads into the highly fragmented embedded market.

            In 2000, worldwide shipments of embedded Linux OSs, software development tools, and related services reached an estimated $28.2 million (see figure, below). By 2005, VDC estimates that shipments will reach $306.6 million, a compound annual growth rate (CAGR) of 61.2%.

9.2 Product Categories

            In 2000, the annual developer fee was the largest category, followed by professional services, unbundled software development tools, and run-time royalties:

Annual Developer Fee

Professional Services

Unbundled Software Development Tools

Run-time royalties

Other

9.3 Geographic Regions

            North America accounted for the greatest share of shipments in 2000. However, VDC is forecasting both Europe and Asia/Pacific to grow at faster rates over the forecast period.

9.4 Vertical Market/Application Segments

            Telecom/datacom is expected to remain the largest consuming market for embedded Linux software development solutions, as indicated in the following ranked list which shows leading vertical markets and applications for embedded Linux OSs and software development tools in 2000 (in rank order by dollar volume consumption):

Telecom/Datacom

Consumer Electronics

Industrial Automation

Retail Automation

Office Automation

Military/Aerospace

Automotive

Information Automation

Medical

           

            In 2000, VDC estimates that telecom accounted for $13.2 million in shipments. However, VDC is forecasting consumer electronics to grow at the fastest rate over the forecast period.

9.6 Leading Vendors

            In 2000, the global market for Linux OSs was relatively small with no dominant market player. VDC estimates that Lineo, MontaVista, and Red Hat (in alphabetical order) are ranked in the top tier, with many companies trying to gain a foothold in this burgeoning market, focusing on specific vertical segment(s).

 9.7 On Linux's Future in the Embedded Systems Market

Findings include . . .

9.7.1 Strategic Business Issues

·        Linux, originally developed for the desktop and adapted for servers, has done well in these markets, and is making in-roads into the highly fragmented embedded market.

·        Traditional embedded OS companies are searching for that middle ground and trying to become more open.

·        The open source community represents a powerful movement and open development model driving innovation.

·        There are several different business models for embedded Linux vendors who are focused on branding builds of their distribution and adding value.

9.7.2 End User Analysis

·        Embedded developers decision not to use Linux is based more on technical suitability and quality of long term support rather than the protection of intellectual property.

·        Availability of source code, royalty-free, and vendor reputation are key criteria for selecting Linux.

·        Embedded developers currently using Linux are satisfied with the products and support from their current Linux provider.

·        Real-time requirements vary from application to application and both second kernel and preemption improvements are viable alternatives to satisfying real-time for Linux.

9.7.3 Third Party Opportunities

·        VDC estimates shipments of unbundled software development tools and related services reached $4.0 million during 2000.

·        Increased interest from embedded developers in using Linux is driving software development tool companies to adapt their products for use with Linux.

·        Embedded developers recognize the benefits of software development tools and are not averse to paying for quality tools.

·        Going forward, VDC expects additional third party software development tool companies to announce support for embedded Linux.

·        Current demand for third party service opportunities is minimal and identified with application development.

Other findings include . . .

·        VDC forecasts consumer electronics, automotive, information automation, industrial automation, and telecom/datacom as vertical markets for high growth embedded Linux applications.

9.7.4 "Embedded Linux" has become a disruptive force in the market

            If you could travel back in time to the Embedded Systems Conference of September 1999, you would find that the "Embedded Linux Market" simply did not exist in 1999. Sure, a growing number of developers and a handful of companies were starting to embed Linux. But as a market that anyone tracked, or paid attention to, Embedded Linux simply hadn't made it onto the radar screens.Embedding Linux was a relatively rare phenomenon and was mostly the result of developer innovation -- not the fruits of marketing plans and promotional strategies.

            Transporting back to the present -- ESC, September 2000 -- where does embedded Linux stand today?

            "Embedding Linux," primarily an activity of innovative software developers became the central focus of a rapidly growing number of commercial endeavors by September 2000. Major investments in embedded Linux, totaling in the hundreds of millions of dollars, have been made by industry powerhouses like Motorola, IBM, and Intel.

            It's important to understand that the embedded market would be going through a major transition, right now, with or without Linux. Independent of Linux, developers would be scrambling to satisfy the growing demand for both intranet and Internet connectivity. They would be hastening to take advantage of the opportunities presented by new low-cost 32-bit RISC processors coupled with abundant program and storage (Flash) memory. High integration system-on-chip processors based on MIPS, PowerPC, and ARM cores make it both easy and inexpensive to embed full-system features in even the simplest and most cost-constrained systems. These emerging technologies have dramatically boosted the capabilities of embedded devices -- and have also greatly elevated expectation levels.

            In short, embedded Linux arrived on a scene that was already in the midst of great upheaval, with developers working hard and fast to apply newly available technologies to newly defined challenges. Because it provided low cost, open source, yet state-of-the-art functionality, Linux was well positioned to be swept along by the tide of change in the embedded sea. The open availability of source, coupled with today's unheralded ease and speed of collaboration and communication, turned out to be compelling factors that enabled developers to quickly and efficiently adapt to the challenges of a rapidly changing landscape. So Linux began to spread like wildfire in the embedded market.

10. CONCLUSION

           

10.1 Is Linux always best?

            Linux is certainly rapidly growing in popularity as a software platform for embedded systems and devices. But is it really a good fit for all applications?

            The not-so simple answer to this question is a highly-qualified "no." For the most constrained of devices (with less than a couple of Mbytes of RAM or ROM), it may be larger and more complex than the system can afford. Or, for true "hard real-time" applications, it might not provide the predictability or blazingly fast response times required (although a number of available real-time enhancements and extensions can help a lot).

            On the other hand, Linux is an excellent solution for embedded systems and devices that have more than the minimum of resources, are not strictly hard real-time, and have a need for networking or human interaction. Linux is also a great fit when there is a need to take advantage of its open source, royalty-free software model.