Device networking products play a critical role in the operation of electronic systems within a variety of different sectors: factory automation, point-of-sale, building management, and many others. In fact, we’re seeing an exponential increase in the number of devices populating these applications—each one offering valuable data that users need to harvest and use to enhance decision- making and improve efficiencies. However, many of these devices are essentially “dumb” and low cost. As a result, they have only simple interfaces, such as serial RS-232 or RS-485.
At the same time, system designers want to leverage the capability of Ethernet to shift the device data to a central server and onwards to a global network. Thanks to the IT fraternity, many sites will, of course, already be fitted with CAT5 cabling, which makes its use as a control and communications infrastructure even more desirable. More recently, the advent of deterministic Industrial Ethernet has removed the final barrier to Ethernet’s complete adoption, opening it up to applications where latency is critical.
The challenge faced by device networking product designers is how to make the burgeoning array of RS-232, RS-485, or increasingly USB devices accessible over the house network. And, at the same time, they must provide the rich networking features used by the PCs also connected to that network.
It’s important not to forget that manufacturers of device-networking products find themselves in a highly competitive marketplace, where design is semi-bespoke and the need for differentiation is great, yet cost is highly sensitive and time-to-market of paramount importance. There’s no doubt that the aspect of connectivity is a crucial one, but it adds little value— it just needs to be there and work! True product differentiation is best related to the features and capabilities of the software running on the product.
Traditionally, device networking relies on a PC and the use of PCI add-in cards. The disadvantages are obvious: it’s a large expensive box (particularly if it’s an industrially hardened breed) and it consumes a large amount of power. Conversely, it offers a feature-rich operating system, networking and connectivity aspects are taken care of, and it’s real easy to add your own applications.
A more recent trend has been to replace PC-oriented solutions with dedicated device networking products that save space and power, handle all of the connectivity, and provide product designers with the flexibility to add their own value to a given application. However, for many organisations, such a move can be onerous.
Consider the obvious step of basing a device-networking product design around an off-theshelf microprocessor and separate connectivity chips (Ethernet, USB, serial, and so forth). At face value, the solution presents a clear advantage—you choose exactly what you want, with the right cost/feature mix. However, each component needs to be separately identified, validated, and integrated with the rest of the system, which requires additional glue logic probably in the form of an FPGA.
Once the component selection process is complete, the real challenges begin to unfold. Considering the required networking capabilities, an operating system must be selected, purchased, and then integrated with the microprocessor, a tool chain, and ultimately your own design environment.
It might just be that the selected operating system has device drivers for the chosen connectivity chips. If not, you’ll need to write and integrate them yourself, a task that can be difficult and timeconsuming. And when it comes to more sophisticated networking, you’ve got to deal with more complexity. In reality, networks assume that all of its devices have the capabilities of a PC and can support SSL, SSH, DHCP, web servers, etc. Again, if your OS doesn’t support these, then you’ll have to write them yourself, or worse case, change the OS.
Future proofing of your design in this environment is problematic. Invariably, customers will request features that were never considered in the original design. Having the flexibility to extend the capabilities of the product, both from a hardware and software point of view, is then essential for capitalising on potential business opportunities. Thus, processor and operating-system selection become critical.
Naturally, this can be a real issue, particularly if an organisation is more rooted in hardware rather than software design. The whole aspect of network connectivity can lie way outside of the comfort zone of many designers, and involve making many difficult software (and in fact hardware) selection decisions that could later limit the product’s commercial potential.
To address this, Oxford Semiconductor has been working on the concept of a “network connectivity platform.” In summary, this system-on-a-chip-based solution aims to offer device-networking product designers the following ingredients:
- A powerful compute engine
- A feature-rich operating system
- A high-performance connectivity set
- Product customisation—flexibility through both hardware and software
- Fast development—a fully integrated hardware and software environment
The whole idea of the OXETHU954, the company’s first network-connectivity platform, is driven from the connectivity side. The SoC embeds a number of standard connectivity ports (Ethernet, USB, serial, and PCI) and integrates them with an on-board 220MIP, ARM 926 microprocessor, and requisite memory resources. The silicon comes preconfigured with an operating system and software, and is backed by Eclipse-based IDE tools.
The connectivity options provided by the chip, whose architecture is shown in Figure 1, is tailored as closely as possible to the needs of its target applications: factory automation, pointof- sale and building management. In such applications, particularly in industrial arenas, serial communication certainly remains important for device interfacing. The chip, therefore, offers four high-speed UARTs to respond to RS-232, RS-422 and RS-485 needs at transmission rates up to 1Mbaud.
In addition, two USB2.0 fullspeed host controllers and respective PHYs capable of operating at up to 12Mbps are included. As previously stated, in these applications, the devices are relatively “dumb” and produce small amounts of data. Consequently, more sophisticated interfaces aren’t required to bring them together.
On the networking side, the SoC then integrates a 10/100 Ethernet MAC for wired network connections. Wireless network connections are also addressed in the form of a PCI interface. As the standard expansion bus for the PC, PCI is supported by many peripheral chips that handle serial, USB, FireWire, Ethernet, and 802.11 communication. A PCI interface provides the flexibility to easily add more capabilities and functionality to a new product design.
There’s a particularly topical economic argument for the PCI option, too. Compared to consumer applications, many of the target device-networking applications can yield relatively low volume product runs, which can be unattractive to 802.11 chip manufacturers. Wireless miniPCI modules, however, are available in any volume, from a number of manufacturers. They provide a solution without real commercial constraints, one that’s readily interfaced to the connectivity platform via PCI.
And what about integrating all of this connectivity in software? This is where the concept of the dedicated connectivity platform steps into the picture. An illustration of the complete software development environment is shown in Figure 2.
Linux is becoming increasingly popular for embedded applications. Its advantage lies in the sophistication it offers, particularly in terms of networking and device driver support, whilst having the flexibility to easily add functionality, very good tool support, and no royalties.
Being open source, it also lets users leverage code developed by the community to save valuable engineering time. A commercial RTOS, on the other hand, is a closed environment, typically limited in its features and functionality. It requires a proprietary tool chain and, of course, it’s not free.
Preconfigured with the Linux OS, the SoC assures users of a rich set of capabilities and transparent access to embedded communication stacks and a board-support package (BSP). Beyond providing the code that glues OS and hardware, Oxford’s BSP contains the device drivers for all on-board peripherals as well as some external ones (for example, PCI to octal UART and 802.11). Coupling Linux with PCI and the 220 MIPS offered by the ARM 926 provides product designers with the flexibility to extend and modify their products.
In this instance, the Wind River Linux platform serves as an integral component due to its stability and reliability. The commercial- grade, develop-and-run platform is based on a stable, tested, and validated Linux Kernel. It includes integrated patches and packages for advanced networking, security, and carrier-grade functionality.
For application development, the SoC’s software-development kit comes complete with development board (Fig. 3) and a choice of development tools on 30-day free trial: Wind River Workbench and Code Sourcery G++. To save setup time, the Linux Root File System has already been integrated.
The tools will provide an Eclipse-based development environment. However, users can also choose to work from the command line.
The integration of OS and BSP with a dedicated connectivity platform can save huge amounts of time and effort in the selection and integration of the components that make up a device-networking product. In short, designers simply needn’t worry about any aspect of the connectivity. Of course, that does leave the application development itself. But at this point, it’s best to have designers keep their focus, because this is where they add the most value on any given project.