Market demands are pushing companies to produce products with network support. This requires the incorporation of communication protocols like Ethernet, which enables easy configuration, monitoring, and control of embedded systems through the use of a common web browser. A browser can also provide a more dynamic product interface giving a more polished look and feel to the end product.
Complexities of Ethernet Though simple to use, adding Ethernet connectivity to a product is no trivial task. The complexities of TCP/IP stack operation require a great deal of knowledge and effort to implement. Stack operation can also quickly consume processor resources if not efficiently integrated into a real-time operating system. Bringing web services into the picture, it becomes clear the engineering effort can be substantial. These complexities make in-house development and maintenance of the stack alone impractical. The effort can be greatly reduced by using a third-party tool vendor. Though third-party tools provide a solid platform to begin development, there are NRE costs to consider. Traditional tool vendors also have a revenue model that charges per project. This presents an ongoing expense with the release of every new product. Tool Migration Migrating to a lower-cost tool vendor presents its own challenges. A full re-architecture of the software is required due to the proprietary nature of stack and web service APIs. Losing previous NRE and the software engineering time makes changing vendors difficult and expensive. So many companies pursue alternatives to in-house design using third-party tools. The most common is the use of an Ethernet module. Modules typically offer a way to simplify the design and avoid the purchase of an RTOS, web serving package, and IDE. They also cut time to market by eliminating the time associated with the development of hardware, board support packages, and deployment tools. Performance Choosing the processor platform that best suites your needs is as important as the tool set that supports it. The tightest integrated toolset has little value if the end module's performance falls short of system requirements.Because internal architectures vary greatly between module manufacturers, it's important to understand the module's capabilities and the end product's requirements. Correctly matching a module's capability with an application's need's will yield the most cost-effective product.
Unfortunately, determining a module's performance is not as simple as seeing an on-board 10/100 MAC. Simply having a MAC does not mean the module can transfer data at that speed. Servicing a 100-Mbit TCP/IP stack requires data to be looked at and transferred between layers many times before being delivered to its final address. To meet speed requirements, these operations need wide internal data paths, hardware acceleration in the form of a DMA, and an integrated MAC.
Satisfying stack requirements just maintains a coherent network connection. To transfer data, it must be brought into the module. Limited I/O performance can slash throughput. As I/O latency is analyzed, process interaction must also be considered. A collision in priorities can occur when the serial port has data and the stack needs servicing at the same time. This task collision can yield unpredictable throughput rates. Optimizing the stack by integrating it into the RTOS and using peripheral DMA hardware support minimizes priority collisions, giving higher and more predictable data throughput.
Web Services Once these low-level performance requirements have been satisfied, the module can begin to interact with a web client. This interaction might include serving up a web page, collecting and displaying data, or interacting with other systems through the I/O.In many cases, the end customers' only view of an embedded product is through the web server. Every module manufacturer has a different approach to web server support. Some assemble the web page at compile time; others have a static page that variables and a logo can be added to. Interaction with the embedded environment is also unique. Some vendors allow only variables to be presented while others allow full interaction with the embedded environment. This can have a great impact on how the product looks and feels. Careful analysis of the dynamic nature and flexibility of the server is critical in selecting the solution that best represents a company's end product.
Cost Reduction Another challenge is encountered as increasing production volumes make the design more cost sensitive. Driven by cost, companies need to migrate from a module to a fully custom solution. Cost optimizing this solution requires changing peripheral features, including memory size and external control logic. These changes require modifying the BSP supplied by the module manufacturer. Not having the knowledge gained during the development of the BSP, can be a major obstacle to completing the custom design. Understanding the Vendor's Revenue Stream Module manufacturers' revenue models are based on hardware sales, not software sales. Many module manufacturers view the software as simply an enabler for hardware sales. So designers must explore a manufacturer's desire to support migration to a fully custom design. Some vendors make up for lost revenue by charging a royalty to use their stack in a fully custom design. Others manufacture the silicon and maintain revenue by increasing the processor's cost. This is simply a way of moving the royalties into silicon resale dollars, converting the revenue stream from one model to another. Conclusion As these details come to light, it becomes clear a new approach to cost analysis is necessary when implementing Ethernet. Custom API structures limit a company's ability to change vendors due to cost or support issues. Designers must understand not only the immediate costs but also the manufacturers' revenue model.If carefully analyzed, a module can provide an easy and smart way to quickly build Ethernet functionality into a product. If not, it can create an ongoing challenge to engineering support and increase a product's cost. It can also limit the ability to cost-optimize a design, making a product non-competitive in a marketplace where everyone is incorporating Ethernet into their products.
Tim Shannon can be reached at [email protected].