Table of Contents
| Foreword | |
| Preface | |
| Ch. 1 | An Introduction to the eCos World | 1 |
| Ch. 2 | The Hardware Abstraction Layer | 17 |
| Ch. 3 | Exceptions and Interrupts | 31 |
| Ch. 4 | Virtual Vectors | 59 |
| Ch. 5 | The Kernel | 73 |
| Ch. 6 | Threads and Synchronization Mechanisms | 85 |
| Ch. 7 | Other eCos Architecture Components | 121 |
| Ch. 8 | Additional Functionality and Third-Party Contributions | 149 |
| Ch. 9 | The RedBoot ROM Monitor | 185 |
| Ch. 10 | The Host Development Platform | 207 |
| Ch. 11 | The eCos Toolset | 239 |
| Ch. 12 | An Example Application Using eCos | 281 |
| Ch. 13 | Porting eCos | 315 |
| App. A | Supported Processors and Evaluation Platforms | 337 |
| App. B | eCos License | 345 |
| App. C | Cygwin Tools Upgrade Procedure | 355 |
| App. D | Building the GNU Cross-Development Tools | 361 |
| About the Author | 369 |
| Index | 371 |
| About the CD-ROM | 392 |
Forewords & Introductions
Preface
Whether you're working on an existing project or moving on to a new development, eventually you're going to have to decide on what Real-Time Operating System (RTOS) to use. Numerous questions arise, including how much does it cost to get started, are there royalties associated with using the RTOS, what is the quality of the tools, is source code available, what features are available for the RTOS, and so on. In most situations, the lowest-cost solution in both upfront costs and royalties is the best solution, as long as it works. Eliminating royalties is very important for high-volume products, where every nickel counts.
There are also concerns of previous investments made, both in developer knowledge and financially, for the current solution. Anxiety can occur when considering moving existing code to a new software platform, which can be intimidating depending on the size of the project. Porting a new RTOS to your hardware platform can create more trepidation.
Decisions about whether to develop your own RTOS or use an off-the-shelf solution surface in some cases as well; especially when specific functionality is needed for a specialized hardware platform. In some cases, rolling your own RTOS might be the only solution. However, you can put your development way ahead by leveraging software that is already implemented, tested on numerous platforms and in various situations, and, most importantly, proven because it is successfully running on other shipping products. This eliminates the need for implementing functionality that is readily available.
This book focuses on one solution to these concerns: the Embedded Configurable Operating System (eCos). Theopen-source and royalty-free nature of eCos allows it to be downloaded, set up, and used, and here's the key: at no cost. When finished with this book, you will have a complete embedded software development environment—all the tools necessary to tackle any project.
Since eCos is open source, you, the developer, are in complete control over your embedded software destiny. Even the tools described in the eCos development system are open source, thereby allowing you to become completely self sufficient—although the eCos development community is out there available to lend help when needed.
Book Layout and Overview
Let's take a look at the layout of the book and get an overview of what is covered and where it is located. This enables you to focus on the specific aspects of eCos that you need to understand.
The layout of the book is intended to build on information covered in earlier chapters. We start with understanding the key components within eCos, then move to additional functionality offered in the system, and finally, get down to using eCos and the development environment.
For developers new to the eCos world, or embedded software altogether, it is helpful to understand the components that make up the eCos system by starting at the beginning. This gives the baseline understanding of the different features provided by eCos. You can then implement these software components in an actual system.
More experienced developers looking for an evaluation of eCos can skip to the later chapters and begin experimenting right away. The format of the development platform installation and examples allow a quick setup of the tools and immediate results. This lets you answer the question, "will eCos work for me?"
Current eCos users can fill in any holes that might be present in their eCos knowledge, by looking at some of the eCos concepts from a different point of view.
Chapter 1, An Introduction to the eCos World, begins with a brief introduction to eCos, which includes a background about the eCos open-source project and the company behind its start. A description of the eCos terminology is detailed as well. This terminology is used throughout the book and in the eCos development community. The beginning of the book is intended to provide developers who are unfamiliar with eCos a means to become acquainted with the eCos open-source project.
Next, we discuss the key components within the eCos system, presenting a closer look under the hood of these major software modules. The key component chapters offer an understanding about how the different software modules work independently and together to provide functionality required by the system.
Chapter 2, The Hardware Abstraction Layer, focuses on the software closest to the hardware that enables higher-level software modules to be unaware of the low-level functioning of the hardware.
In Chapter 3, Exceptions and Interrupts, we detail exceptions and interrupts and show how they are set up and handled in the eCos system. We discuss virtual vectors in Chapter 4, Virtual Vectors, which provide a means to share services between ROM and RAM applications.
The heart of the eCos RTOS, the kernel, is the focus in Chapter 5, The Kernel. The kernel supplies the scheduling functionality and the synchronization mechanisms for the software. Moving on to Chapter 6, Threads and Synchronization Mechanisms, we discuss the basic unit of execution in eCos, the thread, and provide a detailed look at the various synchronization mechanisms supported by eCos.
Chapter 7, Other eCos Architecture Components, continues with our look at the different eCos components by focusing on timing components, asserts and tracing functionality, and the I/O control system.
Chapter 8, Additional Functionality and Third-Party Contributions, includes a broader look at some of the additional features available for eCos developed by the eCos project maintainers and third-party contributors. These include networking support, ROM monitors, file systems, PCI support, USB support, and the GoAhead WebServer.
In Chapter 9, The RedBoot ROM Monitor, we focus on the RedBoot ROM monitor. This standalone program is designed for embedded systems to provide a debugging and bootstrap environment. RedBoot is an eCos-based application and uses the eCos Hardware Abstraction Layer (HAL) for its foundation.
We begin our hands-on experience in Chapter 10, The Host Development Platform, with the installation of the host development tools. We discuss the Cygwin native tools, the GNU cross-development tools, and the eCos development kit. We also cover the installation of a Concurrent Versions System (CVS) client, WinCVS, to enable access to the online eCos source code repository. This gives you the ability to take advantage of any bug fixes or extended functionality contributed to the eCos source code.
In Chapter 11, The eCos Toolset, we delve into the eCos toolset with a detailed look at how the tools operate on the eCos source code, and the layout of the tools. Also included are some other open-source tools to round out and complete our open-source embedded development system. This prepares us for the next step, putting the tools to work to build our application.
Chapter 12, An Example Application Using eCos, lets you put your knowledge to work. The chapter starts with an overview of the eCos build process, followed by a build of the RedBoot ROM monitor. We then do a build of the eCos real-time operating system, and, finally, put it all together by building an application. This chapter provides a baseline on which you can then add additional components to assemble a system to meet your embedded software requirements.
Finally, Chapter 13, Porting eCos, closes with a look at porting eCos onto another hardware platform. This is key to getting your application running on your new target hardware platform, which is typically the main goal in embedded software development.
Development System and Examples
As mentioned previously, in Chapter 10 we go through the process of setting up an eCos development system. This development system includes the native Cygwin tools for Windows, the GNU cross-development tools (binutils, compiler, and debugger), the eCos configuration and management tools, a CVS client, and a lint program.
This system enables you to configure and build the eCos library, which is then linked with an application to run the eCos RTOS. The RedBoot ROM monitor is also built using this system. After following the steps in Chapter 10, a complete open-source embedded software development environment is configured.
We go through examples of building RedBoot, the eCos library, and an application in Chapter 12. Rather than requiring a specific development board to run the examples, a second PC is needed for the target platform. This is a better approach to becoming familiar with the development tools since it's typically pretty easy to find a spare PC lying around.
Although GNU cross-development tools binary files are included on the CD-ROM for the Intel x86 and PowerPC processor architectures, the instructions for configuring and building the GNU cross-development tools for other processor architectures are provided in Appendix D, Building the GNU Cross-Development Tools.
The embedded software development tools are installed, and examples are built, on a Windows development system. However, the necessary files to get an embedded software development system up and running on a Linux system are included on the CD-ROM. Since the eCos configuration tools are able to run on both Linux and Windows, the procedure for building and running the examples applies to both host operating systems.
The CD-ROM accompanying this book contains the files needed to set up the complete embedded software development system for eCos as detailed in Chapter 10. The examples in Chapters 12 and 13 are also contained on the CD-ROM under the examples directory.
A web site is available to download the source code and updates.
If you find any errors that need correction, feel free to contact me and I will update the source code accordingly.
Some Notes about the Book
All example code in this book is in C or assembly language. eCos also uses the Component Definition Language (CDL), an extension of the existing Tool Command Language (Tcl) scripting language. We cover this in Chapter 11.
In the text where a 32-bit hexadecimal value is shown, the most significant 16 bits and least significant 16 bits are separated by an underscore ("_") (e.g., 0xABCD_EF12) for readability.
Sidebars are also included, which are used to point out important or additional information.
This book includes several Uniform Resource Locator (URL) links showing where additional information can be obtained on the Internet. The most up-to-date links are included in the text; however, we all know that links can have a finite existence.
Item lists throughout the book detail the eCos kernel API functions. These lists contain a field named "Context." This field shows the context from where the specified function can be called. The different contexts are Initialization, Thread, ISR, and DSR. "Any" is used to designate that the function can be called from any of the contexts.
A Brief Take on Open Source Development
There have always been "agnostics" in the debate of open source versus closed source—it sometimes comes down to whether the funding is available to purchase software tools and support. Each has its benefits and shortcomings, so let's take a brief look at some of the pros and cons developers have found when working on both sides of the open-source and closed-source fence. What it ultimately comes down to is, does the product work, and can the schedule and cost budget be met using this solution?
Open source can be a confusing term. In an article written by Daniel Benenstein, he states that open source is free software in the sense of freedom of knowledge exchange. Much more reliance is placed on the individual developer to find problems, correct the problems, and make the solution available to others in the open-source community. This iterative process is the method that creates a more robust and bug-free code base.
Presumably, because the draw of talent is worldwide, the best and brightest developers are working to make the product better. With closed source, a development support team is assembled to work on fixing problems for code they probably did not create. The team assembled might be very talented; however, the pool of talent from which to draw is very small compared to a worldwide talent pool.
Often times, closed-source, or proprietary, software and open-source software work hand in hand to complement each other. Many proprietary products are derived from open-source projects. Proprietary software must be innovative and differentiate itself from the open-source alternative; otherwise, why would people pay for something that they can get for free? Looking at things from this point of view, open source pushes proprietary software to the extreme of innovation.
There are some general advantages and disadvantages to using open-source software. One advantage is that since the source is available if you are not able to get support from the open-source community, you can dive right in and find out exactly what is going on with the code. There is no need to wait for support from an external source, which can reduce debug time drastically.
Another advantage of open-source software is that it is not tied to any one specific company. In the case of proprietary software, if the owning company changes direction, or disappears, then the application developers using that solution are left out in the cold. Open-source software prevents this because developers have full access to the code and can choose the path for their own system software.
Sometimes vendors selling proprietary software are not always the most responsive to all customers using their product. In cases where a project is not destined to produce large volumes, the vendor's response to questions might not be as rapid as needed. The reality is that a company with higher revenue products will get the preferential treatment.
Having the source also gives you the ability to implement your own changes and customize the code exactly the way you need to for your specific application. In addition, only with open-source can the source-level configuration method, as we find in eCos, be used.
Although some proprietary software vendors offer their source code to developers, there is often a fee associated with getting said code.
Security is often looked at as a negative aspect of open-source developments. Because all of the source code is available to everyone, malicious developers can exploit security holes. On the other hand, the community of developers supporting the open-source project work quickly on a fix because it is in their best interest as well. You are not at the mercy of a single source providing a fix to the security problem.
A great source for getting viewpoints from some of the leading figures behind the open-source movement is Open Sources: Voices from the Open Source Revolution.
Finally, I hope you all enjoy this book.
Anthony J. Massa
Loading...