Meeting the challenge of communications in a connected world

Not too long ago, embedded technology was epitomized by point-solutions that were designed to perform a single or small number of functions as standalone devices. Even when the PC became prevalent, networks were closed systems intended to connect just a few devices or locations. Today, ever fewer devices operate in isolation; connectivity has become so prevalent that even the smallest device is able to include a level of connectivity. It is, in fact, this concept that is fuelling the Internet of Things (IoT), M2M, and Industry 4.0, as well as the smart grid and building automation.

Connectivity is now ubiquitous throughout every aspect of society, enabling greater mobility for both people and data, which is in turn empowering greater efficiencies in commerce and consumerism. But the rapid acceptance of connectivity isn't without its challenges, not least of all in tackling the issue of support for legacy protocols while taking full advantage of the latest developments.

Data drives connectivity

This seemingly insatiable appetite to connect "things" is a result of the value of data in all its forms. Along with the trends mentioned previously, which all have a significant impact on the embedded electronics industry, there is a larger overarching trend that, while perhaps not directly driving developments, is exerting its influence: Big Data.

The concept of Big Data involves finding value in disparate datasets. This requires two things: lots of procession power and lots of data. The former is being provided by server farms and cloud-based processing services, while the latter is being generated by almost every activity that can be measured.

Getting this volume of data out of devices and in to the cloud requires connectivity; however, while there is a clearly adopted infrastructure for the networked world – that being Ethernet – the embedded sector is less unified. The need for Ethernet connectivity isn't always obvious to embedded developers as, while costs continue to reduce, the expense of adding Ethernet isn't zero, and therefore must be justifiable. Also the complexity of adding Ethernet to a resource-constrained embedded device can be significant, not least because of the added software burden.

In addition to the need to transfer data, secure access to modern devices is becoming increasingly important for control, to support the IoT, M2M, and Industry 4.0; in this respect Ethernet in all its forms is rapidly becoming the standard. Being the backbone of the Internet, it brings wide area network (WAN) access to locally networked devices, allowing them to be accessed and controlled from anywhere.

Embedded designer challenges

More often, some form of local connectivity will be specified in the form of an industry-standard serial bus, such as RS232/485 CAN bus, etc. Most low-cost microcontrollers (MCUs) offer this or some other form of UART or general purpose I/O (GPIO) that can be used for this purpose. However, GPIO is rarely used for data transfer to a wider network, particularly within a non-industrial application.

Increasingly, USB is being specified as a board-level interconnect within embedded devices; just as with GPIO or a simple serial bus, it offers greater flexibility, as well as a universally accepted standard. Furthermore, USB connectivity is increasingly simple to implement in low-cost MCUs; many manufacturers now offer a USB variant, further illustrating the trend towards connectivity in a wider range of equipment that would have previously operated as stand-alone devices. But perhaps most significantly, the USB protocol allows for a single device to operate as a hub, thereby significantly extending the I/O capability of a USB-enabled device. In this respect, USB offers a significantly more flexible solution to other, simpler serial interfaces, particularly when providing a "future proof" interface.

One of the major benefits USB offers is the ability to implement a tiered hierarchy, yet another is enabling a single controller to enumerate a number of devices. These, in turn, can be physical devices that offer a range of extended functionality, while the protocol affords those devices a level of autonomy and control over the host system.

For example, using the USB protocol, an embedded system can be extended to include a level of functionality that far exceeds its original hardware specification, particularly when the software of that device is hosted on an MCU that has provision for field upgrades. Conceptually, this would allow a wide range of embedded devices equipped with a USB interface to become active members of a wider network, to the point of becoming accessible from any networked device. Providing this level of connectivity can be cost-prohibitive if it were to be designed-in, but by using USB as a gateway, it becomes both practical and affordable.

Bridging barriers

Adding connectivity to an embedded device can be achieved by selecting a more powerful MCU that offers a plethora of interfaces. In some applications this will be the best option, but that number is likely to be limited, primarily due to cost, size, or power budgets. Furthermore, larger devices may introduce redundant GPIO that isn't needed for a particular application, unnecessarily increasing system cost and system power.

While, conceptually, USB offers the flexibility to accommodate a range of interface standards, in practice implementing those standards could still present challenges for such resource-limited platforms. For example, while there are a number of expansion ICs available that can effectively increase the number of GPIO a low-cost MCU offers, suitable for a wide range of control or monitoring applications, adding a high-speed interface such as USB, or a network connection such as Ethernet could rapidly increase the number of discrete ICs significantly, far beyond the space and/or cost budget.

In high-volume applications a bespoke ASIC can be developed that integrates a range of interface standards. Such an ASIC could be designed to be low power and physically small, however, the NRE costs of ASIC design would prohibit this approach in all but the highest volumes. The practical alternative to ASIC development is the use of an application-specific standard part (ASSP) – effectively a device dedicated to a particular function. Typical port expanders may be considered to be ASSPs, however, historically no semiconductor manufacturer has developed a single ASSP that targets a wide range of communication standards, forcing OEMs to choose either a high-end MCU, an FPGA, or several ASSPs.

By exploiting the strengths of USB, an ASSP has been developed that integrates I2C, UART, and Ethernet interfaces, as well as flexible GPIO. All functions are enumerated as USB endpoints and can be controlled using standard USB drivers embedded in the host MCU's firmware. Using either standard USB commands, class-specific commands, or specific Exar commands allows full control over the communication peripherals, which can in turn be configured using dedicated registers. On-chip OTP memory also allows OEMs to modify features such as vendor ID and vendor string, and each device has a uniquely assigned Ethernet MAC address. The functional block diagram is shown in Figure 1.

The ability to add a wide range of communication interfaces to an embedded design using one low-cost device could provide OEMs with an answer to the design problem of adding flexibility to resource-constrained applications.

The need for more flexible communication options is growing within the embedded sector, as more vendors realise the value of connectivity. The problem they face is choosing the right communication interface, but that needn't be the case. Through higher integration and innovative design, OEMs can effectively future-proof today's designs to offer – through software upgrades if necessary – greater levels of connectivity "on demand." Ethernet is increasingly driving the connectivity revolution and it is now easier than ever before to integrate it and many other communication standards in to small, resource-constrained embedded devices.