Product category:
Networking Hardware
News Release from: NetBurner | Subject: Ethernet modules
Edited by the Electronicstalk Editorial
Team on 16 March 2006
What does it really take to network a
product?
Tim Shannon from NetBurner argues that using Ethernet is more than choosing a component manufacturer - it's about choosing a long term partner.
The evolution of high speed connectivity and the advent of the worldwide web are changing market demands for embedded systems These new demands require the incorporation of emerging communication architectures like Ethernet
This article was originally published on Electronicstalk on 9 Aug 2005 at 8.00am (UK)
Related stories
Embedded Ethernet module comes with tool support
The MOD5270 is the first module based on Freescale Semiconductor's ColdFire MCF5270 processor.
ColdFire-based module has rich peripheral set
NetBurner has introduced the first module targeted at the low cost low power embedded space.
The incorporation of Ethernet 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.
Although simple in use, the development of products with Ethernet connectivity is no trivial task.
Further reading
File system speeds network development
NetBurner has enhanced its network development kit by adding an embedded Flash file system.
Bridge links Ethernet with CAN
NetBurner has introduced its first product specifically targeted at providing developers with a platform for Ethernet enabling Control Area Networks (CAN).
Ethernet module masters its own I/O
Ethernet module includes a programmable I/O controller with its own core and memory system, enabling it to perform complex timing and I/O management independently of the CPU.
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 of developing an Ethernet solution can be substantial.
These complexities make in house development and maintenance of the stack alone impractical.
The engineering effort can be greatly reduced through using a third-party tool vendor.
Though third-party tool vendors provide a solid platform to begin development, there is an NRE associated with the purchase of tools.
Traditional tool vendors also have a revenue model that charges per project.
This presents an ongoing expense with the release of every new product.
Deciding to migrate to a lower cost tool vendor has its own set of challenges.
A full re-architecture of the software is required due to the proprietary nature of Stack and web service APIs.
Loosing invested tool NRE and the software engineering time, makes changing vendors difficult and expensive.
These expenses have driven many companies to pursue alternative solutions to in-house design using third-party tools.
The most common alternative is the use of an Ethernet module.
Modules typically offer a way to simplify the design; avoiding the purchase of an RTOS, web serving package, and IDE.
They also offer a shorter time to market; avoiding the time associated with the development of hardware, board support packages, and deployment tools.
Choosing a module that best fits system requirements is a challenge typically unfamiliar to embedded designers.
The question of how much processor performance is required has moved from being just an estimate of the end applications needs, to accounting for TCP/IP stack performance, RTOS latency, and data throughput requirements.
Although many 8 and 16bit processors boast Ethernet, the remaining processor performance falls far short of most system design requirements.
Demand for a larger more complex processor to satisfy stack requirements and communication speed has pushed many engineers into the 32bit processor arena.
Because internal architectures vary greatly between manufacturers, it's important to understand the modules capabilities and the end systems design requirements.
Correctly matching a module's capabilities with system requirements will yield the most cost effective solution for a specific application.
Unfortunately, determining a modules performance is not as simple as seeing an onboard 10/100 MAC.
Simply having a MAC does not mean the module can transfer data at that speed.
Servicing a 100Mbit/s TCP/IP stack requires data to be looked at and transferred between layers many times before being delivered to the final address.
For these operations to be carried out quick enough to meet speed requirements, they need to have wide internal data paths and hardware acceleration in the form of a DMA and an onboard MAC.
Satisfying stack requirements just maintains a coherent network connection.
To transfer data; data must be brought into the module through I/O.
Limited I/O performance can quickly kill data throughput.
I/O throughput is more than just I/O latency; the processor must interact with the I/O to bring data in and place it in memory.
In many architectures this requires processor interaction.
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 data throughput rates and an intermittent network connection.
Optimising stack operation through integrating it into the RTOS and using peripheral DMA hardware support, minimises priority collisions giving higher and more predictable data throughput.
Once these low level performance requirements have been satisfied, the module can begin to interact with the network client and the embedded environment.
This interaction might include, serving up a web page, connecting with client through a TCP/UDP connection, or interacting with the embedded environment through module I/O.
In many cases the end customers only view of the embedded product is through the web browser or TCP connection.
Intermittent network connections and slow data throughput can make a product feel less capable; opening the door for the customer to look at different solutions.
Giving a product a clean look and feel requires understanding how the module interacts with the web client.
Every manufacturer has a different approach to web server support.
Some assemble the page at compile time; others have a static page where variables and a logo can be added.
Interaction with the embedded environment is also unique.
Some manufacturers only allow variables to be presented, while others allow full interaction with the embedded environment.
This can have a great impact how the product looks and feels to the end customer.
Careful analysis of the dynamic nature and flexibility of the server is critical when selecting a module that best represents a company's end product.
With many 32bit processors to choose from, designers are basing the decision of which module to use on the tool suite provided with the module.
Tightly integrated tools ease the design process by simplifying code development and deployment.
An additional challenge is encountered as increasing production volumes make the design more cost sensitive.
Driven by cost, companies require a migration path from a module to a fully custom solution.
Cost optimising this solution requires changing peripheral features including memory sise and external control logic.
These changes require modifying the BSP supplied by the module manufacture.
Without the knowledge gained during the development of the BSP, this can become a major obstacle to completing the custom design.
The module manufacturer's revenue model is based on hardware sales not software sales.
Many module manufacturers view the software as simply an enabler for hardware sales.
For this reason, it is necessary to explore a manufacturer's desire to support migration to a fully custom design.
Some manufacturers make up for lost revenue through charging a royalty for the use of their stack in a fully custom design.
Others manufacture the silicon and maintain revenue income through increasing the cost of the processor.
Comparing processor prices, it becomes apparent additional cost is built into the processor from these manufacturers.
This is simply a way of moving the royalties into silicon resale dollars, converting the revenue stream from one model to another.
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 manufacturers due to cost or support issues.
It is important to understand not only a manufacturer's immediate costs, but also its revenue model.
NetBurner offers a wide variety of solutions for low, medium, and high volume applications.
Low and medium volume designs are satisfied through a low cost tool set and aggressive module pricing.
As volumes ramp up, NetBurner has a path to full design ownership with no additional royalties.
This one time fee includes full source for hardware and software, as well as a full design review to ensure that a design works right the first time.
The design can be used over and over again at no additional cost (no royalties).
• NetBurner: contact details and other news
• Email this article to a colleague
• Register for the free Electronicstalk email newsletter
• Electronicstalk Home Page
Search the Pro-Talk network of sites
