I started my professional life as a software engineer working at a test and measurement company. My job involved writing the embedded firmware for test devices to initialize, calibrate, and coordinate the various functions on the hardware.
In those days, many hardware engineers did not fully understand the complexity and challenges of getting this firmware to work properly. We often heard “It’s just software” or “We can always fix this in software” regarding the difficulties of getting the software and digital hardware to properly exercise the analog portions of the system.
Don’t get me wrong—the hardware engineers understood that the software was important. But it clearly couldn’t be as difficult or critical as the hardware, right?
It All Comes Together
Throughout my engineering career, I’ve had the opportunity to work on various sides of the hardware/software boundary as a firmware engineer, a product team lead, a firmware manager, and a product marketing manager.
As a result, I’ve come to truly appreciate how most great products are the result of a comprehensive system design involving clever partitioning of analog performance, digital hardware, and software. This is particularly true in high-performance RF designs.
The analog aspects of high-performance RF design are truly difficult. Developing low-power circuits that exhibit low noise, high linearity, wide dynamic range, good selectivity, efficient transmit output power, and all the other required performance requirements in a low-cost radio is an art.
I continue to be amazed by the levels of RF performance that can be achieved today with low-cost RF systems. But while these RF specifications are critically important, they represent only a portion of the total system requirements that must be met in a successful end product.
Consider a wireless utility meter. The switch from mechanical meters to electronic meters is well underway throughout the world. Many of these smart meters use wireless radios for the communication link back to the utility. When electricity isn’t readily available, water and gas meters are usually battery powered.
The demands on the wireless portion of the system are high: communication in a harsh outdoor environment (exposed to the elements) with less than ideal RF conditions (buried in a pit in the case of a water meter). A new generation of RF solutions is optimized to deal with these difficult conditions while meeting the needs of running for up to 20 years from a battery source.
But designing a great RF solution isn’t sufficient to develop a great meter solution. While communicating usage data from the meter is extremely important, the system must perform a host of other functions: updating an LCD screen, reading a flow indicator to measure the water flow, running a real-time clock to coordinate measurements and communication intervals, and encrypting data to prevent tampering. All of these features must be implemented in a cost-effective, low-power metering solution.
The MCU’s Role
To achieve the best battery life, many of these system features need to be implemented in dedicated hardware blocks. For example, to reduce current consumption and extend battery life, the microcontroller unit (MCU) in the metering system should be kept in the lowest-power sleep mode for as long as possible. However, the LCD controller needs to be frequently refreshed to keep the display contents visible.
Waking up the entire MCU to simply update the LCD controller is inefficient. New MCUs with integrated LCD controllers allow the MCU to remain in a low-power state while a dedicated hardware block can refresh the LCD at minimum current. Built-in pulse counters can automatically read the pulses from an impeller to ensure accurate water flow measurements in a low-power state, again removing the need to wake up the MCU into a higher-power state.
The MCU and its associated software still have plenty of work to do in this system scenario, such as calculating total flow rates, preparing data transmissions, and coordinating the entire operation. But with intelligent hardware blocks to offload many of the frequent, more mundane tasks, the MCU can wake up only when needed, run in a higher-power active state, complete its work, and get back to sleep. This arrangement enables lower power consumption, reduced MCU horsepower, and easier software development.
Today’s semiconductor suppliers are taking this approach a step further by integrating the MCU and dedicated low-power peripherals along with the RF transceiver into a single device—a wireless MCU. By integrating the MCU and radio, more optimizations can be achieved such as dedicated packet handling to automatically format the communication data, hardware encryption accelerators, and transmission synchronization and control. By intelligently splitting the tasks between the radio, MCU, and dedicated peripherals, the overall system performance and power consumption can be optimized.
Nowadays, it’s all about the system, from elegantly partitioned system-on-a-chip devices to firmware and application software to board-level design to final product. Clearly, we’ve come a long way since the days of dismissing a complex design challenge with a shrug and “It’s only software.”