If “the network is the computer,” then connectivity is what empowers—or limits—your MCU application. This is an area that continues to evolve rapidly.
Microcontrollers (MCUs) have utilized serial transmissions practically from the onset, but the purpose and elegance of those channels have evolved greatly over the last 30 years. The word “connectivity” has taken on new prominence in most applications in the new century, driving on-chip support for networking and even wireless communications from the microcontroller. The advantages of more advanced connectivity and the ease with which it can be obtained make it well worthwhile to take a renewed look at how your end-application can make use of broader communications capabilities.
Begin with the basics
In the 1970s, as MCUs were first emerging, UARTs (universal asynchronous receiver-transmitters) first brought a pre-configured serial port to microprocessors and microcontrollers. UARTs and synchronous-capable USARTs were largely used to perform simple data communications. UARTs and USARTs were added to the MCU as the transistor budget allowed, and serial communication became more attractive.
Soon, the need was determined to more tightly connect the central brain of the MCU with nearby peripherals that remained separate from the MCU due to their complexity, uniqueness, or electrical characteristics that made them less practical to integrate on-chip. A serial connection may have been slower than transmitting over the parallel bus, but it conserved valuable pins (even in the 8 bit era) and made it easier to use peripherals from a different, perhaps more specialized, vendor than the controller manufacturer. This gave rise to the various standard serial modules found in great numbers on today’s MCUs:
Philips’ I2C (Inter-Integrated Circuit)
Motorola’s faster SPI (Serial Peripheral Interface)
Philips’ fairly specific I2S (Inter-IC Sound)
Motorola’s SCI (Serial Communications Interface)
Tradeoffs between speed and complexity may take a back seat to how many devices are on the channel and exactly which interface the desired peripheral supports. Generally, such serial interfaces are intended to connect only with other chips on the circuit board, often in a master-slave relationship. The SCI, often bundled with these serial ports, is really just a UART and more likely to provide a little longer reach. Buses like the I2C, SPI, and I2S are used to connect with nearby peripherals such as E2PROMs, real-time clocks, memory cards interfaces, analog-to-digital converters, digital-to-analog converters, sensors, camera interfaces, and audio codecs. For most of today’s MCUs, the existence of SCI, SPI, I2C, and similar serial ports are more of a requirement than a differentiating feature.
Automotive drivers
More sophisticated, frame-based serial communications were first driven onto MCUs with the advent of CAN (Controller-Area Network). In the 1980s, Robert Bosch GmbH initiated CAN as a means for microcontrollers to communicate among themselves in an automobile, a platform where numerous MCUs were used. This harsh environment required robustness and a strict protocol. Since the number of potential network end-points was growing quickly, the need for a specific host or master could be limiting. Yet, reliable communications between disparate and optional controllers in the vehicle have greatly improved the operating conditions of the vehicle and have become a necessity for engine control, safety systems, and diagnostics. With the automotive industry’s support, the CAN network and CAN peripheral chips took hold.
In the 1990s, CAN peripherals started appearing on-chip in MCUs destined for automotive applications, about the time the protocol started evolving. While other networks have also found some places in the automobile for specific applications, CAN still forms the backbone of most automotive systems. CAN has also found a home in industrial applications, with their similarly harsh environments and noisy conditions and in medical instruments where special integrity requirements are highly valued.
CAN and MCUs were mad for each other. CAN was developed to let the systems that MCUs comprised communicate with each others. Since automotive applications are the inspiration for much of the design of MCUs, CAN modules are a natural circuit to include in MCUs.
Computer connectivity
The tremendous growth of the personal computer (PC), accompanied by Ethernet (see Figure 1) and the Internet, took place somewhat outside of the microcontroller industry but is having a heavy influence on it. The PC made de facto standards of TCP/IP, Ethernet, and Wi-Fi for long distance data communications with servers, email, the Internet, databases, and other systems. The need for system inter-activity drove TCP/IP and Ethernet to be the backbone of data communications, even supplanting the circuit-switched telephone network to a large degree, and attracting creative minds to make the protocol work for nearly every application. The utility of TCP/IP made it quite popular and the protocol stack became a well-honed standard, economies of scale dramatically drive down the prices of chips and software down.
The ubiquity of the protocol and some confluence of Metcalfe’s Law and Moore’s Law, has opened untold opportunities for electronic system connectivity. Whether it is refrigerators reporting food shortages to the grocery store or air conditioning systems taking a break during peak electricity rate periods, networks, Ethernet, and TCP/IP are being employed in every conceivable application for machines to communicate with hosts, servers, directly to other machines, hubs, remote monitors, and to control centers manned or unmanned.
Microcontroller vendors have responded by providing Ethernet controllers on their MCUs (although it took some time for the transistor budget to free up) and for OEMs to give serious consideration to Ethernet as a connectivity option on traditional MCU-based systems. Today the benefits are difficult to ignore. From software updates to remote monitoring to long-term customer services, when TCP/IP brings the Internet to the edge of the board for a small price adder, the option can be very attractive. If nothing else, access to the Internet gives essentially unlimited range to the control or management of the system.
Figure 1: Ethernet Cable.
The ubiquitous USB
The PC is also responsible for the great popularity of the USB (Universal Serial Bus). There used to be discussions of whether USB (Figure 2) would supplant other local connectivity ports on the PC, especially the space-constrained laptop, but it did not take very long for the discussion to turn to “how many USB ports can we put on this?” once USB ports and drivers became integral to the PC and a few devices converted over to the convenient standard, USB caught on like wildfire.
Figure 2: USB connector.
Soon, MCU-controlled devices such as the mouse, keyboard, and similar input devices, switched over to USB connections. Printers, modems, and other output devices made the change, abandoning interfaces with origins in the mainframe era. USB evolved to be faster (Table 1), making it more practical for hard drive interfaces. New form factors put flash memory on a thumb-sized portable storage device that easily plugs into many hosts. USB also became an intermediary and a “dongle” port where other connectivity devices can plug in, such as Ethernet, Bluetooth, Wi-Fi, and memory card adapters. At some point, the convenience of the USB port drew MCU vendors to put their own MCU evaluation boards and debugging ports on USB-enabled cards.
| Version | Mbps | Grade | Comment |
| USB 1.1 | 1.5 | low-speed | mice, keyboards |
| 12 | full-speed | printers |
| USB 2.0 | 480 | high-speed | hard drives |
| USB 3.0 | 5000 | super-speed | new connector, emerging |
Table 1: USB versions.
USB gained additional popularity as its facility for supplying current to attached devices started to be exploited. It is possible to draw 100 mA at 5 V (up to 500 mA also accommodated), which is more than enough to power numerous applications without an additional power source. With the slightest effort, this current can recharge the battery of a truly portable handheld device. This allows USB to perform the dual functions of transmitting data as well as supplying power – all with a single cord and connector.
MCUs are convenient for operating the USB port for transmitting data and even for managing a recharging circuit. While the latter is usually left to the system engineer to design, integrating a USB controller onto the MCU eliminates an additional chip in the system. The cost is minimal and most of the software is readily available and prepackaged.
The distinction between host (master), device (slave), and the swings-both-ways, On-The-Go (OTG) varieties of USB controllers must be considered when picking an MCU with USB capability, but more USB modules and stacks can support any role the controller must play. It’s another dimension of USB that should be narrowed down (along with speed grade and, eventually, physical connector style) when evaluating how the technology can expand an application’s utility.
Less wire
The ultimate in connectivity and communication would require no physical contact. Wireless communications, be it using Bluetooth, ZigBee, Wi-Fi, near-field communications (NFC), or similar technologies, are robust enough to link up between devices or with a network or the Internet without much trouble. Breaking the tether avoids certain hassles but also removes the benefit of getting electricity to the device, so there are some tradeoffs in going wireless. Also, the nature of radio circuits limits just how much these can be integrated onto the mostly-digital MCUs, but the vendors are still working to get closer to more compact and well-blended with wireless systems. Range, EMI, and security are other issues to consider in selecting the radio air interface.
In industrial applications, for instance, having wireless controllers, especially in a mesh network, means that to move some equipment or add a sensor on a factory floor may mean just placing the equipment where it is needed. With a wireless network, no new cables need to be laid out or routers reconfigured. The network self-discovers the new equipment (and probably doesn’t care if it was only moved). If a unit fails, it simply falls off the grid and the rest of the network continues without it, though hopefully a flag is raised.
Consumer explosion
As mentioned, many forms of communications have become stand-outs and true standards in recent years. The high volume of digital consumer electronics has become a significant factor in establishing such standards. While CAN is more under-the-hood, USB and Ethernet are far more visible. The phenomenal boom – and churn – in digital still cameras, MP3 players and cellular phones—in tandem with the desire to transfer large amounts of data between PCs, TVs, printers, and the Internet—has caused an explosion in the need for universal connectivity.
This explosion of consumer electronics needing connectivity opened huge opportunities for chip vendors to supply vast quantities of chips and programmers to write the protocol stacks to support the standards. Lower costs and off-the-shelf software made it even easier to connect consumer devices in more ways.
Microcontrollers will hook you up
Microcontroller vendors have been taking care of your connectivity and communications needs. More and more serial channels, communications methods, and networking peripherals have been brought into the MCU as the market has called for it. Along with the hardware implementation, the chip vendors have been assembling the software that makes it work. Third-party software vendors step up to the plate to offer improved, more universal, customizable, and specialized communications software and protocol stacks. The result is a relatively easy and cost-effective means of adding greater connectivity to MCU-based equipment.
The more advanced communications protocols require more horsepower from the processor than a little bit-banging does or a UART. Some can take advantage of additional RAM for buffering and forming packets. Some can use Direct Memory Access (DMA) techniques to block-transfer strings of data to other parts of the system. The more advanced MCUs typically have more advanced communications capabilities. However, some advanced connectivity is available on 16-bit and 8-bit MCUs, as well. Most vendors have evolved with their markets, so your favorite architecture probably has a selection of MCUs with a peripheral on board to implement the technology of your choice.
In my opinion, the best bet for exotic network and communications will be with 32-bit MCUs. They have the performance, the flexibility, and the memory space to handle the code, and they are more likely to be in markets where overall performance is important, and where connectivity is a must rather than a luxury. This also means the 32-bit MCUs will keep up with heavy communications traffic. However, 32-bit MCUs are not as expensive as one might believe. The price difference from a comparably-equipped 8-bit MCU is hardly noticeable.
The established architectures have a good range of MCUs with CAN peripherals. Namely Renesas, Freescale, Texas Instruments, STMicroelectronics, and Microchip all have suitable solutions for this market.
When it comes to USB, almost any vendor has a good range of MCUs with USB connectivity. USB does not weigh down 8-bit MCUs, and 16-bit controllers should handle USB well.
Ethernet has been appearing on MCUs more frequently the last few years, and has increasing promise as the Internet becomes a backbone for all things electronic. We are consistently seeing suppliers provide solutions with both MAC and PHY integrated on chip.
There are a few MCUs containing an array of communications facilities. To highlight one solution, ARM-based Stellaris line from Texas Instruments has MCUs with several serial peripherals all on-chip including: two CAN 2.0 A/B controllers, a USB 2.0 Full-Speed Host/Device/OTG module, a 10/100 Ethernet MAC/PHY with hardware-assist to synchronize industrial networks via the IEEE 1588 Precision Time Protocol, two SSI/SPI controllers, two I2C interfaces, an I2S interface, and three UARTs.
Is your application sufficiently connected for tomorrow?
