Connect Your MCU

Introduction

With the emerging Internet of Things (IoT) in both consumer and commercial applications, there is a lot of focus on connectivity. IoT is all about connecting devices together to allow for higher order experiences and usability.

A first order example can be an office meeting-room, where lights and equipment can be automatically turned on or off depending on when someone is in the room to conserve energy. A second order function can be tracking all information about use of the room, to allow managers to see which meeting rooms are being heavily used, and which are not, to optimize the work-space, and to decide when a room needs to be cleaned because of frequent usage.

Furthermore, data can be used to prepare meeting rooms ahead of time, by turning on projectors and other equipment, not only based on scheduled meetings, but also based on expected activity, which is based on measured data. This white paper will explore the key building blocks that are required to make scenarios like this a possibility, and how these can be integrated into increasingly small and energy efficient microcontrollers (MCUs).
 

The Function View

A device or an application typically has a well-defined set of functions and behaviors. In the example above multiple types of devices can be required to make up the complete functional experience, such as:

• Motion detectors
• Light-bulbs
• Power control for projectors etc
• Manual switches

Some of these functions can be combined into a single device. A light-bulb, for instance, could include both motion detection and light generation. Each of these devices needs to communicate with each other. A simplified view of a light bulb is shown in Figure 1. Note that the power management of the light-bulb has been excluded, to focus on the communication aspects in the bulb.

Figure 1: Functional View of Connected RGB Lightbulb with Motion Sensing Capabilities

The main functions of the bulb are based on the device’s interaction with the world, through its sensors and light source, and how easily the bulb can connect to your phone, light switches and the Internet, is defined by its radio. This is a functional view of the application, but it is also very important, because these are major features of the device, which you in the end want a customer to buy.

External Connectivity - Wireless

The ‘Connect’ area in Figure 1 focuses on how the application communicates with the outside world. For some applications, this can be a connection to a single external device, or it can be a connection to multiple devices. Through this connection, the application could potentially communicate with the other device(s), and potentially also get access to an Internet/cloud connection, either directly or indirectly. Being able to connect to the cloud will become increasingly important for connected devices, to get firmware updates to fix security holes, bugs and provide feature-improvements during the device's lifetime. There are many ways to provide external connectivity to a device, including both wired and wireless options. The table below shows some of the wireless options available in the market today:

1 Can be increased to thousands of nodes using subnets. 2 Can go higher with use of MIMO etc. 3 Unlimited with broadcast. 
4 Network is managed by operator, and network size should not be an issue

There are many wireless connectivity options to choose from, and many of them are specialized in different ways to give an optimal fit for a specific set of use-cases.

Wi-Fi

Wi-Fi is a widespread and extensively deployed technology and is largely ubiquitous across market segments and geography, meaning it is available pretty much everywhere. The benefits of Wi-Fi are high data-rates, allowing use cases such as file transfers and video streaming, and its availability, which makes it a good target for device connectivity.

When basing connectivity on Wi-Fi, you can be pretty sure that your customer will be able to connect it to their network at home without having to purchase additional equipment. The major downsides of Wi-Fi are higher energy consumption, and somewhat higher cost than other solutions on the list. There are also practical limits to how many devices can be connected to a single Wi-Fi access point, making it an unsuitable technology for connecting a large number of devices.

Great for:

• Devices with high bandwidth requirements
• Devices that need IP connectivity
• Devices that need to “just work” straight out of the box

Not great for:

• Small, battery-powered devices
• Large amounts of devices, e.g. lightbulbs

Bluetooth Classic

Bluetooth is another technology that has seen significant consumer adoption. Bluetooth Classic refers to Bluetooth Basic Rate / Enhanced Data rate (BR/EDR), and is today mostly replaced by either dual mode radios that can both do Bluetooth Classic and Bluetooth LE (BLE), or BLE-only. The BR/EDR functionality is today mostly used for wireless audio, where it will still play a role for many years to come. Most low power peripherals are using BLE.

Great for:

• Audio Streaming, Voice

Not great for:

• Most other applications
   

Bluetooth with Low Energy (LE)

Bluetooth LE provides a significantly lower current consumption than Bluetooth Classic, allowing battery-powered devices, such as smart watches and Bluetooth trackers to stay connected to your phone while still providing decent battery life. With the introduction of Bluetooth LE 5.0, the range of a BLE connection can be more than a kilometer, and can reach speeds of 2 Mbps - but not at the same time. This opens new use-cases for BLE. There are also smart-hubs deployed with BLE functionality to allow BLE home automation devices to stay connected even when no phone is around.

Great for:

• Short burst data (wearables, PC peripherals, remotes, sport and fitness, healthcare, etc.)
• Beaconing (Point-of-Interest Info, indoor positioning, asset tracking)

Not great for:

• Audio streaming

Bluetooth Mesh

Another recent addition to Bluetooth LE is Bluetooth Mesh. This functionality allows devices such as light-bulbs, builton BLE to form a mesh network, to communicate with each other, and relay messages for each other. A benefit of Bluetooth Mesh is that a single BLE radio can be used to communicate both with the mesh and with a user’s phone. A downside is the technology has just come out, and it is unclear how it will scale. Bluetooth Mesh is based on “controlled flooding,” meaning that it does not rely on advanced algorithms to define who talks with who in the network, but rather floods messages through the network. The functionality is assisted by relay nodes that repeat any message they hear to make sure messages spread throughout the network.

Great for:

• Connected Lighting, Home and Building Automation
• Audio streaming

Not great for:

• High data-rate applications

Zigbee

Zigbee is a mature mesh protocol based on IEEE 802.15.4, focused on low power and reliability. Zigbee has been around for a long time, and has a large install-base, across home automation and security, smart lighting, smart energy, and building. Zigbee uses algorithms to determine optimal message paths through the network, and therefore does not use the same “flooding mesh” approach as BLE Mesh. Zigbee includes a complete application layer called Dotdot (formerly Zigbee Cluster Library) that defines a common language for devices to communicate with each other, enabling interoperability across device manufacturers. Zigbee is great for networks that need a high level of reliability, and also when scaling to large numbers of nodes.

Great for:

• Connected Lighting, Home and Building Automation
• Industrial Control, Metering

Not great for:

• High data-rate applications
• Audio

Thread

Thread is a mesh networking protocol based on IEEE 802.15.4, similar to Zigbee, but with native support for IPv6 and 6LoWPAN. The initial release of Thread is targeted at home automation applications, although the Thread Group is actively developing extensions to support commercial deployments. One benefit of Thread is it provides IPv6 connectivity directly to the end-node. This allows each node to be addressable from the Internet/cloud, making it easy to write applications on the nodes that reach out to cloud-services and vice versa. It also allows for a simple “border router” to be the connection between the nodes and the Internet, since no mapping is required between end-nodes on the network and what is visible on the Internet. Thread is flexible in that it does not define/mandate a specific application layer. Any application layer which supports IPv6 can theoretically run on top of the Thread stack. One example is Zigbee Dotdot, which is being adapted to run on top of Thread.

Great for:

• Connected Lighting, Home and Building Automation
• Low data-rate networks

Not great for:

• High data-rate applications
• Audio

Z-Wave

Z-Wave is another mesh networking protocol. Unlike the other networking technologies discussed so far, Z-wave is not based on 2.4 GHz, but rather frequencies in the 868 MHz to 926 MHz frequency band, which is also called “Sub-GHz.” Z-Wave has had success in the home automation space, and has fairly good consumer brand recognition. It is only backed by a single vendor, so interoperability between devices from different vendors is easier to achieve with ZWave than with some of the other mesh standards.

Great for:

• Home Automation

Not great for:

• Commercial lighting, Building Automation
• Industrial Control
• High data-rate applications

NFC

NFC (Near-Field Communication) is a technology allowing devices to communicate when they are within 10 cm or closer. NFC can communicate both with other NFC devices, or passive (unpowered) RFID devices. One of the focus areas of NFC is payments, as it provides a secure connection, both because of its protocol and because of the requirement for proximity. NFC is also used in some cases for commissioning of devices, i.e., associating a wireless device with, for example, a name and a password to access its main network.

Great for:

• Very short range communication
• Payments

Not great for:

• Most other applications

2G / 3G / LTE

The cellular technologies 2G, 3G, and LTE all provide both voice and data services. For embedded applications, the data services are the most interesting. Key properties of these cellular services are very long range, and high current consumption while receiving and transmitting. The later technologies also provide high data-rates, of up to hundreds of Mbps. Cellular is good for applications that are mobile, or are in inaccessible areas, where a router or gateway is not available. Cellular modems communicate directly with the same cellular base stations that regular cell-phones communicate with, and have excellent global coverage. One additional downside of cellular is the cost of connectivity. Modems are usually fairly expensive, and a data plan is required, where the user pays per the amount transmitted. The benefit is convenience, because the network is there, and it “just works.”

Great for:

• Long range, mobile and rural applications
• Applications not providing their own connectivity infrastructure

Not great for:

• Battery-powered devices

LTE-M

With the emergence of more connected industrial devices, there is a need for lower cost, lower-power cellular solutions. 5G will be a successor to the current cellular standards, but it is many years out, and until then, there are several intermediate solutions. LTE-M is one of these, and while being slower than, for example, LTE Cat 1, it is also lower power, and the radio is less expensive. One benefit of LTE-M over NB-IoT, is the solution still has high enough data-rate to support voice communication.

Great for:

• Long range, mobile and rural applications
• Applications not providing their own connectivity infrastructure
• Battery-powered devices communicating a couple times a day

Not great for:

• Battery-powered devices communicating often

NB-IoT

NB-IoT is similar to LTE-M, but is cheaper and lower power, and also has a significantly lower data-rate and higher latency. NB-IoT is not fast enough to support voice communication. Even though LTE-M and NB-IoT are driven forward by the same interest groups, they are competing technologies, and are being adopted differently across geographic regions and by cellular operators. The benefit of LTE-M is it only requires a software update to existing base-stations to be deployed, so it is attractive to providers who have already built out their LTE base stations. However, NB-IoT requires a hardware upgrade, but has low power and cost advantages over LTE-M, making it attractive for cellular providers who have not completely built out their LTE base stations. Currently, it looks like LTE-M will be mostly deployed in North America, while NB-IoT is seeing more tractionin EMEA and APAC. There are exceptions, with T-Mobile in the USA adopting NB-IoT as well.

Great for:

• Long range, mobile and rural applications
• Applications not providing their own connectivity infrastructure
• Battery-powered devices communicating a couple times a day

Not great for:

Battery-powered devices communicating often

LoRa and LoRaWAN

LoRa is a communication protocol also targeted at long range communication, similar to LTE-M and NB-IoT. LoRa has a significantly lower current consumption than both, at the cost of significantly lower data-rates. LoRa is designed for devices that transmit data rarely. The uplink data-rate is about 50 kbps, but due to restrictions, the bandwidth is only about 400 bytes per hour. The downlink to the device is slower than the uplink. LoRa is not suited forapplications that need to receive firmware updates in the field. Lora is driven by Semtech, and Semtech is currently the only IC vendor for LoRa solutions. LoRaWAN is built on LoRa, and provides a network service similar to the cellular networks, allowing a LoRa device to connect to infrastructure operated by network providers. This provides better ease of use.

Great for:

• Long range, mobile and rural applications
• Applications not providing their own connectivity infrastructure
• Devices with very low data transfer needs

Not great for:

• Devices that need to download data from the cloud
• Devices that need to download firmware updates

Sigfox

Sigfox is similar to LoRa, but has even lower data-rates. A Sigfox device is limited to 140 messages per day, each with a payload of up to 12 octets, at a data-rate of 100 bps. The same limitations around data rate and uplink vs downlink speed that apply to LoRa also apply to Sigfox. One benefit with Sigfox over LoRa is there are multiple vendors supporting Sigfox in the market. Sigfox coverage is still limited, although Sigfox is aggressively deploying new networks to increase its coverage. Sigfox employs a subscription-based model similar to cellular providers, and will effectively be competing withsolutions such as LTE-M, NB-IoT and 5G, but with a connection offering different properties.

Great for:

• Long range, mobile and rural applications
• Applications not providing their own connectivity infrastructure
• Devices with extremely low data transfer needs

Not great for:

• Devices that need to download data from the cloud
• Devices that need to download firmware updates

Proprietary Wireless

In addition to the standard-based protocols, which include many of the ones previously discussed, there are an even larger number of proprietary protocols. These were developed by companies because appropriate standard-based protocols were not available at the time. A benefit with proprietary wireless is ultimate flexibility. Protocols can bedeveloped to optimize power consumption, data rate, range, modulation and security for a specific application, and many applications still benefit from this flexibility today. Proprietary wireless is commonly used in a variety of applications, including security, metering, lighting, consumer electronics, automotive key fobs, etc. Silicon Labs provides a software interface layer called RAIL to assist in developing proprietary wireless solutions on top of the Wireless Gecko products.

Great for:

• Meeting special connectivity requirements of an application
• Ultra-low power, and long-range applications

Not great for:

• Application developers with limited wireless experience

Multiprotocol

The different communication protocols all have benefits and downsides, and in some applications, it would be beneficial to combine the properties of multiple protocols in the same application. Looking at the light-bulb example discussed earlier in this white paper, it would be beneficial to use a managed mesh network to provide connectivity between the bulbs, the light switches, and the cloud. However, it would also be ideal if the bulbs could automatically transmit BLE beacons to nearby cellphones to provide location information, and accept cellphone connections for configuration. Multiprotocol technologies exist to support these types of scenarios. A multiprotocol-capable radio can operatemultiple radio protocols at the same time, for instance solving the scenario above by providing simultaneous Thread connectivity, BLE connectivity and BLE beacons. The Silicon Labs EFR32 Mighty Gecko wireless SoC supports multiprotocol connectivity to help with these situations.

Great for:

• Combining the properties of two or more wireless protocols in a single device
• Applications that need to optimize cost and form-factor

Not great for:

• Application developers with limited wireless experience

External Connectivity – Wired

The IoT is seeing explosive growth in connected devices because wireless connectivity allows connecting devices that would have been previously difficult, costly or cumbersome to connect. With this enablement, many new use cases are emerging. It is important to realize that, while wireless connectivity is providing many benefits, it also has some challenges:

• Energy Consumption: Wireless is an enabler for un-tethered devices, and is often found in battery-powered, cordless devices. Most wireless radios consume significant amounts of energy when transmittingor receiving, which means that devices need to be tuned to transmit and receive infrequently to conserve battery life. If a device detects a high volume of activity it needs to report, it can burn through the battery quickly if not managed properly.
• Complexity: To enable low power operation and reliable transmission of data, wireless protocols can be complex, and use significant code-space in an MCU. This is also true for some wired protocols, such as USB and Ethernet.
• Interference: Wireless connectivity can lose performance or drop out completely in the presence of other wireless communication or noise. Some protocols are robust, and deploy counter measures such as frequency hopping to avoid interference. However, there is always the possibility that a strong enough signal could jam the communication.
• Security: Wireless connectivity is inherently less insecure than wired connectivity, because physical access is not required to listen to or tamper with the wireless signal. Modern wireless technology employs strong cryptography to combat this problem, yet some of the burden is put on the implementer to ensure the overall application does not have vulnerabilities.

A benefit of wired connectivity is once you pull a wire to a device, you might as well include power in the wire. The wire makes the device less flexible, as it must stay in the same location at all times, but it provides some benefits:

• No Batteries: Most devices using wired connectivity also get power from the same cable, allowing the device to run “forever” without the user needing to recharge it or swap batteries. This can also simplify the product significantly, since power management and battery housing can now be simplified or removed.
• High Data-Rate, Long Range: Wired connectivity is generally able to provide higher data-rates over long erranges, at lower energy consumption than wired connectivity.
• Reliable Operation: With a point-to-point connection between devices, which is often shielded from outside interference, wired communication is typically more reliable than wireless communication. To eavesdrop or jam a signal, someone would have to get physical access to the wires, which is easier to protect against than a wireless signal that expands in all directions.

Both wired and wireless technologies have their benefits and downsides, and which you should use depends fully on the target application. For large installations, there is also a cost factor related to wired connectivity because the cables must be purchased and installed. The choice must be looked at from all angles.The table below shows some of the wireless options available on the market today. This list is by no means exhaustive, and on top of the communication protocols below, there are higher-level standards that define how to communicate.

1 Limited by bus capacitance 2 Can be increased with switches and hubs  3 Variants are available with higher speeds,
but these are seldom used in embedded systems  4 Depends on technology

RS-232

The RS-232 port was once a standard feature on personal computers, connecting them to modems, printers, mice, data storage, and other peripherals. The technology is still in use in legacy applications across the world, but few new devices use RS-232 due to significant downsides such as low transmission speed, short maximum cable length, large voltage swing, ability to only support point-to-point connections, etc. Functions from RS-232, such as the RTS and CTS signals for flow control, are still used in many applications as a part of UART communication that will be discussed later in this whitepaper. More common in modern applications are USB-to-UART bridges, and virtual COM ports, which provide a robust andmodern transport for UART communication in embedded systems.

Great for:

• Communicating with old, legacy equipment

Not great for:

• Applications not interfacing with old, legacy equipment. (Use USB, Ethernet, etc. instead)

Ethernet

Ethernet provides the connectivity backbone in many industrial and commercial buildings, and individual homes, although connectivity in the home is now primarily distributed using Wi-Fi. Use-cases range from command/control applications in industrial settings, connecting devices together, and focusing on high reliability, but require low bandwidth and have media/content rich applications connected to the Internet, pushing Ethernet speeds to the limit. The most common forms of Ethernet are currently running at 10 Mbps, 100 Mbps and 1 Gbps. In consumer applications, TCP/IP is running directly on top of Ethernet, but in industrial applications there are several protocols inuse, including EtherCAT, PROFINET, EtherNet/IP, and many more.

Great for:

• Wired IP connectivity over long cable lengths
• Both low and high data-rate wired applications
• Automotive, industrial and residential applications

Not great for:

• Connecting a device to a computer. (USB is preferred in this case.)

USB

USB is a standard for connecting devices together. USB started as a way of connecting peripherals such as mice, keyboards, printers, and digital cameras to computers, replacing many old connectivity standards, and has since alsohad a big impact on cellphones, and other devices, for battery charging and connectivity. Multiple iterations of USB have come out in recent years, including the new Type-C specification, which provides increased power delivery and are versible connector. Electrically, all versions of USB can fall back to Full-Speed USB, running at 12 Mbps, which provides sufficient speeds for many applications. Many IoT products include USB connectivity for firmware updates, downloading data, and updating data to the cloud. In many cases, the USB connection is replaced by wireless connectivity, such as BLE.

Great for:

• Peripherals intended to connect to a computer or cell-phone.
• Consumer devices that need to be charged

Not great for:

• Cable lengths over 5 meters

CAN bus

Controller Area Network (CAN) is a robust bus allowing multiple controllers to communicate with each other without any central coordinator. The technology was originally designed for automotive applications, and has widespread use across automotive networks, but it is also used in a range of non-automotive applications requiring robustness. Messages on a CAN bus are designed so higher-priority messages always have the right-of-way, allowing a system to make sure that important messages always get to their destination first at the expense of lower priority messages. Messages are also limited in length. These features make CAN bus a good real-time protocol. In industrial settings, higher level stacks including CANOpen and Device Net are used on top of the CAN physicallayer. While CAN is widely used in industrial applications, the trends is to move towards Ethernet-based field-buses.

Great for:

• Robust, priority-based communication
• Automotive and Industrial applications

Not Great for:

• High data-rate applications
• IP connectivity

4-20 mA Current Loop

A current loop is an older way of signaling that has been used extensively in industrial process controls. In a 4-20 mAcurrent loop, the master device has two wires connected to the slave and puts a voltage across them. The slave then modulates its resistance to change the current going through the connection between 4 and 20 mA. For a flow sensor4 mA, for example, represents 0% flow, while 20 mA represents 100% flow. A current outside 4-20 mA typically represents an error condition. A device on the current-loop can be powered by the loop itself if the device consumption is less than 4 mA. In this setup, only 2 wires are required for both power and communication to an external sensor. A 4-wire setup with separate power ground and current loop can also be used. The 4-20 mA sensors are often mechanically and electrically robust. A basic current loop only represents one measurement. For industrial sensors, the trend is to move to higher level protocols such as HART and wireless HART, which have more capabilities. HART uses 4-20 mA as its physical layer.

Great for:

• Very simple reading of external sensors, but generally not recommended for new designs
• Communicating with old, legacy industrial sensors

Not Great for:

• Complex, high data-rate sensors
• Smart, digital sensors

Power Line Communication (PLC)

Power Line Communication is similar to a Current Loop in that it can provide both data and power over the same wiring, but this is where the similarities end. The power-lines used by PLC are typically used to power several other devices and machines, and are also used as a shared communication medium. A wide range of technologies are used to communicate across power-lines at a wide range of data-rates. The main benefit of PLC is the ability to communicate over existing cables, simplifying installation of new equipment. Use-cases include communication between in-home intercoms, or distribution of an in-home broadband network, as well as outdoor applications such as automatic reading of electric meters by utility companies. A drawback of PLC used in a house to distribute connectivity is unpredictable performance, as it depends on the wiring in the house. Signals can also often not cross fuse-boxes, and EMI interference and susceptibility can be big issues.

Great for:

• Low-cost installations in areas where existing power wiring is available

Not Great for:

• Applications requiring high level of robustness and reliability
• Home automation and connectivity (becoming dominated by wireless)

Accessing Connectivity

As seen by the examples in previous sections, a wide range of connectivity options are available to connect an application to the outside world, all with their strengths and weaknesses. An application can in some cases implement multiple options to combine their benefits and also provide redundancy. This section will briefly explore how to add connectivity to an application.

When selecting a microcontroller for an application, the selection often depends on the availability of one or more communication interfaces. For a Zigbee application, for instance, it can be beneficial to select a microcontroller with a Zigbee radio integrated to optimize integration, footprint, and cost. Though many cases exist where full integration of a communication peripheral is not possible, or not desired. In many cases, it could be because no microcontrollers on the market have the exact combination of interfaces necessary, or it could be due to specific partitioning requirements for the application. In general, there are three ways communication can be made available to an application:

• Fully External
• Partial Integration
• Full Integration

Which of these options above make the most sense for a given application will be explored in the following sections.

Fully External

The traditional way of adding connectivity to an application is to “add another chip,” seen as the “Communicator” in the illustration below. This communicator has all of the functionality required to communicate over a certain protocol and provides a simplified interface to the microcontroller driving the application.

The communicator abstracts away significant parts of the communication protocol for the microcontroller, and typically loosens timing requirements on the microcontroller. For example, if the protocol requires an acknowledgement on a received package, this typically must be generated in a short time after a package has been received. If the microcontroller was responsible for that operation, it would have to be a high-priority operation. The challenge with this situation is there might be other high priority operations within the microcontroller and these could cause problems for each other. With an external chip handling the protocol, the microcontroller does not have to worry about tight turn around with respect to the radio.

Another benefit of this approach is physical separation of the application and communication devices. This is a benefit if there are multiple variants of the application, using different communication protocols. One device made for Japan could be using LoRa, while one made for Europe could be using another proprietary wireless technology. In both of these applications, the same microcontroller could be used, switching out the radio depending on the needs ofthe applications. Separation also makes it easier to re-qualify an application when changes occur. In certain industrial cases, if the application on the microcontroller has changed, and the communication occurs in a separate chip, only the microcontroller-part of the application must be re-certified. The communication piece can be left alone, reducing cost and certification time. This is especially true in many metering applications. An added benefit of external connectivity is it is often the easiest way to add more advanced connectivity to an application, since a lot of complexity is abstracted away.

The external option is available for most wireless standards, and for some, including Wi-Fi, LoRa and Cellular, is the primary way of adding them to an application. In wireless scenarios, this set-up is often called MCU + NCP, whereNCP is short for Network Co-Processor.

Benefits:

• Can add connectivity not natively supported by microcontroller
• Reduced load on MCU allows MCU to focus on application task
• Often easiest way to add connectivity
• Easier to move between different communication protocols for different applications
• Re-certification on application change can be easier
• Communicator can be placed in optimum location on PCB for good connectivity

Downsides:

• Two chips instead of one can increase cost and footprint of application
• Communication between microcontroller and communicator introduces latencies
  

Partial Integration

Partial MCU integration is also common and has been around for a long time. A good example is RS-232. On a logic level, simplified RS-232 is the same as the UART peripheral, which is integrated into virtually any microcontroller. But the UART can only output voltages within the microcontroller’s voltage range, typically 0 V – 3.8 V. Therefore, to communicate over RS-232, a device is required to translate the microcontroller’s signals to the higher-voltage signals required for RS-232, as seen below:

This approach increases the integration between the communication protocol and the microcontroller, which has both benefits and downsides. With the communication stack now running on the microcontroller, the communicator is now a much simpler device, often simply transferring data or commands from the microcontroller to the physical medium and feeding data from the medium back to the microcontroller. All communication decisions are made on the microcontroller. This reduces delays in the system, which can improve device responsiveness. The integrated design can also be beneficial for energy consumption, as the application can finish its communication quicker and go to sleep.

A downside to integration is the MCU software now must deal with the communication stack on top of the other tasks it is managing for the application, increasing the complexity and timing-requirements for the MCU. Many wired communication protocols are typically partially integrated, including RS-232, RS-485, Ethernet, CAN, etc. In many cases, this is because the voltage or ESD requirements for the protocol would require a different manufacturing process to be used for the microcontroller, resulting in worse performance in other areas, such as higher current consumption and lower clock speeds.

Benefits:

• Tighter coupling with software for increased responsiveness
• Faster turnaround time can give lower power consumption
• External chip is simpler, and easier to source
• Communicator can be placed in optimum location on PCB for good connectivity

Downsides:

• Increased software complexity
• Two chips instead of one can increase cost and footprint of application

Full Integration

Full integration means the connectivity mechanism is fully integrated into the MCU and only passive devices are assisting in connecting the MCU to the communication medium, as shown below.

Some of the wireless connectivity protocols, such as BLE, Zigbee and Thread, are increasingly fully integrated into MCUs to create Wireless MCUs, also known as Wireless SoCs. Some of the driving forces behind this are cost reduction, simplified supply chain, as less chips need to be procured, and simplified PCB design for the application.

The fully-integrated approach can also improve system energy consumption, because less chips must be powered and managed, and it provides a similar level of close integration as the partially integrated solution.

Software complexity for the fully-integrated solution is more complex than the external solution, but potentially less than the partially integrated solution, as application and communication software still must co-exist, but the communication hardware can now potentially be easier to manage. Another down-side with a fully integrated solution is it can be harder to move to a different communication technology. If an application is built on a BLE MCU, and you now want to move it to Zigbee, this can become problematic in many cases as you would have to switch to a completely different MCU. Fortunately, there are two solutions to this obstacle:

1. Multiprotocol MCUs like the EFR32 Mighty Gecko natively support multiple protocols. It can be configured todo BLE or Zigbee at manufacturing time, or in the field, or you can have it do both at the same time. In the same way, it also supports Thread and proprietary protocols, giving a lot of freedom for the application developer.
2. Additional connectivity can also be added as external communicators. This is commonly done when adding,for instance, Wi-Fi or Cellular connectivity to an application.

Benefits

• Tighter coupling with software for increased responsiveness
• Faster turnaround time can give lower power consumption
• Lowest BOM cost and component complexity

Downsides

• Not possible to move communicator to optimum PCB location without also moving MCU
• Increased software complexity
  

Modules

The three previous sections go through how connectivity can be added to a microcontroller, but whether modules are used or not used has not been covered yet. Wireless connectivity can be difficult to integrate into a system because both the antenna and the passives required to get good radio performance must be done just right. Certification costs are also associated with doing a custom radio design.

To help make it easier to integrate wireless connectivity into an application, a wireless module integrates both the communication device, the passive components, and optionally the antenna. This provides a pre-made solution for an application, which is much easier to get right, and the modules often reduce or remove the cost and time it takes togo through certification.

For wireless applications, modules are often used in one of two ways: The module is either used as a Network Co-Processor (NCP), implementing the wireless functionality as in the Fully External use-case, as shown below, or as a standalone Wireless MCU, where a single module contains all the components, including the microcontroller itself, as shown below.

The module approach can significantly simplify integration of wireless technologies into an application, versus integrating wireless through chip-down and external components. Read the following whitepaper to learn more: SixHidden Costs in a 99 cent Wireless SoC.

Internal Connectivity

So far, this discussion has primarily centered around external connectivity, enabling an application or device to connect to other devices and/or the cloud. The internal connectivity of a device includes all connections between internal chips in the device. The inside of a device can include microcontrollers, sensors and actuators, but also other components, such as flash memories, microphones and any other functionality required for the application not already integrated into the microcontroller. The figure below shows the internal and external connections in the application from Fig. 1.

There are many types of internal connections, and their properties depend on their use-cases. An overview of some internal connectivity technologies is shown in Table 3. Note that external connectivity technology is sometimes used inside an application as well. One example is USB, which is sometimes used to connect multiple sub-systems of an application together. In that scenario, a slightly different specification, sometimes referred to as USB-IC, is used, which reduces the overhead of standard USB. This section will not focuson those technologies, but rather the more common ways of connecting devices together in an embedded IoT application.

1 Range scales with data-rate, but is typically well below 1 meter. For fast transmissions, cable and trace lengths should be as short as possible. 
2 Traces or wires must be matched to provide equal transition time for signals 
3 Power consumption scales linearly with data-rate
4 Can go faster or slower depending on the devices communicating and the traces that carry the signals

UART

Available on virtually every microcontroller available on the market, UART provides an asynchronous, bi-directional communication channel to another device, capable of reaching speeds of multiple mega bits per second.

One benefit of UART is a device on either side of the connection can initiate transmission at any time. A down side related to this ability is both devices need to have a relatively accurate clock source. The maximum error toleranceper device is 2.5%, which often makes an external crystal necessary. On some Silicon Labs parts, however, the internal clocks are accurate enough to drive UART within this error tolerance, reducing application cost. Flow-controlis an optional UART feature, which prevents the devices communicating from sending information faster than the other can receive. This is accomplished either using XON/XOFF characters in the data-stream, or using separate CTS and RTS pins.

UARTs are often used to connect external connectivity devices such as cellular modems and wireless network coprocessors, as well as provide links between microcontrollers when multiple microcontrollers are used in one application.

Great for:

• Connecting devices that might have data for the microcontroller at arbitrary times

Not great for:

• Connecting multiple sensors to a microcontroller
• High-speed communication

SPI

Compared to UART, SPI is a master-driven, synchronous protocol allowing multiple devices to be connected to a single bus. SPI achieves this by adding a clock pin, driven by the master microcontroller, and a chip-select pin for each device to connect to. The data-lines are shared. SPI, therefore, requires more pins than UART if connecting to just one device, but potentially fewer if connecting to multiple devices. In SPI, the master always initiates a transfer, and side band signals are typically used to allow the devices to notify the master when they have data to transmit. Because SPI is a synchronous interface with an explicit clock, there is no requirement on the accuracy of the clocks of the devices. SPI can also be extremely fast, reaching 36 Mbps and higher on some devices.

Great for:

• Connecting sensors or devices with high bandwidth requirements

Not great for:

• Optimizing PCB area, due to a high number of connections

I²C

I²C is similar to SPI in that it can connect to multiple devices over the same bus, but I²C only uses two pins, regardless of how many devices are connected. I²C also supports true multi-master, meaning multiple microcontrollers can interrogate the slaves on a single bus. Like SPI, side band signals are also required for I²C devices to let the master(s) know they have data ready.

A downside of I²C is it has a much lower speed than SPI, and is therefore primarily suited for devices with lower data rates, such as sensors. I²C also has some reliability problems. If a device on the I²C bus fails, that device could block the bus for all other devices. A variation of I²C, which is supported on EFM32, EFR32 and EFM8 devices, called SMBus, solves this issue by introducing failure recovery mechanisms and making the bus more robust.

MIPI I3CSM is an upcoming communication protocol similar to I²C, but provides several improvements, including built in side band signals, which allow a device to signal a master without using extra I/O, as well as speed improvements. This protocol is driven by the MIPI organization.

Great for:

• Sensors with low data-rate, as many can be connected to a single bus
• Minimizing number of IO connections

Not great for:

• High data-rate peripherals

I²S

I²S is short for “Inter-IC Sound” and is a variant of SPI meant for audio. I²S is a point-to-point connection, and swaps the chip-select lines for word clock. Since the PCM data on an I²S bus can be streaming for long periods of time, the word clock provides word synchronization. For mono audio, it defines the start of each audio word, and for stereo audio, it also defines which speaker each audio word is targeted at. Word-sizes between 8 and 32 bits are typically supported. I²S can be used to interface to both microphones and speakers, but also other devices, such as codecs, which can translate audio signals and communication interfaces. MIPI SoundWire® is an upcoming communication protocol that will provide improvements to I²S. The improvements include built-in side band signals similar to what I3C is providing, as well as support for both PCM and PDM and double data-rate.

Great for:

• Audio devices

Not great for:

• Non-audio applications

PDM

PDM is short for Pulse Density Modulation and is generated from an analog signal, such as audio, through the process of delta-sigma modulation. The PDM signal is then sent to, for instance, a microcontroller, where a filter can be used to recreate digital values from the PDM input. When used in an application, the PDM signal is usually accompanied by a clock signal if it is sent to another chip for interpretation. It can be low-pass filtered to recreate the original analog signal.

PDM is often used in microphones, as microphones with PDM can be built cheaper than microphones based on I²S, since the PDM microphone only requires a delta-sigma modulator, while the I²S microphone requires a full ADC. PDM is also used in some other applications where a signal must be sampled at a high accuracy in a cost-efficient way.

Great for:

• Microphones with PDM output
• Sensors with sigma-delta modulated outputs

Not great for:

• Use with microcontrollers not supporting PDM due to high software overhead

PWM

PWM is technically a special-case of PDM, but much more common. PWM is used to drive power electronics, LEDs, etc., and is a cheap way to generate analog signals without using a DAC. When driving power electronics or LEDs, the PWM signal can be used directly; however, when creating an analog signal, an RC filter is often applied to the PWM signal to smoothen it out.

PWM is generally created using a TIMER peripheral. Each TIMER on the EFM32 and EFR32 devices can generate up to 3 or 4 individual PWM signals. PWM is seldom sent to another microcontroller to be interpreted, but is often used to emulate an analog output from a microcontroller.

Great for:

• Driving LEDs, motors, etc
• Cost-efficient generation of analog signals

Not great for:

• Highly accurate and high-bandwidth analog signals

Quad-SPI

Where SPI offers two lines for data, one from master to slave (MOSI) and one from slave to master (MISO), Quad-SPI offers up to 4, or 8 (known as Octal-SIP) data-lines that are bi-directional. Quad-SPI also offers advanced features to speed up bit-rate over these lines. Together, these features mean that Quad-SPI can offer data-rates of hundreds of Mbps. Quad-SPI is a de facto standard established by NOR flash manufacturers, and it is therefore typically used as a “fasterSPI” to access external NOR flash. A strong benefit of Quad-SPI is it often allows the external memory to be directly mapped into the memory-space of the microcontroller. Quad-SPI also enables direct execution from the externalmemory, effectively increasing the “internal” memory of the MCU.

Great for:

• Adding more memory to a microcontroller for data and executable code

Not great for:

• Optimizing PCB area, due to a high number of connections

SDIO

Like Octal-SPI, SDIO employs up to 8 data-lanes to increase data-rate to an attached peripheral. An SDIO peripheralis typically used for connecting to external high-speed communication devices, such as SDIO-capable Wi-Fi modules, eMMC-devices (such as managed NAND flash), and SD memory, (including removable SD cards). Note that both Wi-Fi modules and flash memories come in variants supporting regular SPI interfaces in addition to SDIO. Using these devices in SPI mode will give the same level of control as SDIO, but at a lower performance.

Managed NAND eMMC memories and SD memory include support for files systems, and are good for bulk storage, but not for code or random-access data.

Great for:

• Connecting to Wi-Fi modules, eMMC chips and memory cards

Not great for:

• Optimizing PCB area, due to high number of connections

External Bus Interface

An External Bus Interface (EBI) is a wide parallel bus allowing for rapid access to external devices, at the cost of ahigh number of pins. Similar to Quad-SPI, the EBI maps the external device into the memory space of the microcontroller, providing quick access for the CPU. This interface can be used to connect memories, displays, and awide range of other devices to the microcontroller. In many cases though, unless very high data-rates are needed, an application can often be better served by a lower pin-count interface.

The EBI, being a flexible parallel bus interface, can also be used to emulate other serial interfaces. In this scenario, the CPU would pre-process the data to be transmitted to make it match the target protocol, and the DMA would apply the data to the EBI, allowing efficient emulation.The EBI on EFM32 has 8 or 16 data-pins and a configurable number of address pins, which canoptionally be multiplexed with the data-pins. This interface supports autonomous driving of TFT displays, and is the way to go to maximize frame-rate on larger displays.

Great for:

• High performance memories and displays

Not great for:

• Optimizing PCB area, due to a high number of connections

Plain Digital and Analog GPIO

Finally, GPIO pins on a microcontroller can be manipulated directly by software and specialized peripherals such as the on-chip TIMERs. Most GPIOs are also connected to analog functions inside the microcontroller, allowing them to drive analog signals using a DAC or sample signals using an ADC, or connect to a wide range of on-chip sensor interfaces and low-power peripherals.

Using GPIO directly is useful in a wide range of scenarios, including sampling sensors, driving sensor networks, configuring settings for external devices and managing energy consumption of an application by driving power gates. The possibilities are endless. GPIO can also be used to “bit-bang” / emulate other serial protocols, such as UARTs or protocols not supported by the microcontroller.

Great for:

• A wide range of design scenarios

Not great for:

• Bit-banged communication interfaces can have high software overhead.

Working with Connectivity

Coming back to the original example of the motion-sensing lightbulb, several connectivity technologies are required to make it work. The most visible one is the external connection, which connects the bulb to the world, but there are also multiple internal connections tying internal devices together to make up the functionality of the bulb. I2C could, for instance, be used to connect to the sensor, and PWM would likely be used to drive the LED.

The microcontroller is responsible for coordinating all communication interfaces and implementing the logical features of the bulb. For less complex applications using only simple communication protocols, such as UART, I2C, and one more advanced communication protocol, such as Zigbee or Ethernet, this type of scenario is manageable without leveraging an operating system for the microcontroller. Though, keep in mind the use of anOS can significantly simplify development, as it decouples the functional responsibilities of the application.

For more complex applications where a microcontroller might be using multiple advanced protocols at the same time, for instance Zigbee and BLE, an OS is pretty much required. Each of the advanced protocols are served by advanced stacks, with hard timing requirements, and unless they are scheduled properly, communication can fail. An OS assists, in this case, by allowing you to implement the application without putting too much thought into the scheduling of the communication stacks, as the OS does this for you. An OS such as Micrium OS also comes with communication stacks built-in, making the addition of communication elements to an application as painless as possible.

Closing thoughts

A wide range of connectivity solutions are available, both for connecting an application to the world, and to connect the internal pieces of the application. When selecting a microcontroller architecture, it is important to choose one that solves your connectivity needs. These needs can change from application to application and therefore, flexibility is important. With the Silicon Labs EFM32 Gecko MCUs and EFR32 Wireless Geckos, a wide range of connectivity technologies are available. With Gecko MCUs, USB, Ethernet, CAN, QSPI, SDIO, and so on, are all viable technology options. The Wireless Geckos technologies include Bluetooth, Zigbee, Thread, Proprietary, and Multiprotocol capabilities. The software compatibility between these devices means it is easy to build one application with one set of connectivity and then move to another device if the requirements demand it.