When embedded designers take advantage of the often-overlooked processing power within a wireless module they can typically eliminate the system microcontroller, thus creating a cellular-enabled system that is smaller, more efficient, and much cheaper to produce. Following are guidelines for choosing a module that can act as both microcontroller and modem.
When adding cellular connectivity to an embedded system, many designers choose a wireless module because they are pre-integrated components and perform cellular communications with minimum configuration. Pre-certified for use with mobile networks, they’re ready for worldwide deployment. The developer interacts with the module using serial interfaces and doesn’t have to be concerned with complex aspects of cellular modem transceiver design.
More often than not, designers use a wireless module in combination with a standard microcontroller, usually the two highest-cost items in the bill of materials. The microcontroller manages the application and interacts with peripherals while the module mainly takes care of cellular communications.
However, many wireless modules are capable of doing much more than managing cellular communications since they typically use an integrated chipset that includes a 32-bit ARM microcontroller. Accessing this processing power, designers can use the module to manage the entire application. The module can behave as the central processor and modem, eliminating the need for a standalone microcontroller. The resulting system is more compact and uses less power, with a noticeably lower material cost.
Figure 1 depicts an example wireless module integrating an ARM9 microcontroller, one the most widely used control architectures in embedded systems.
When the wireless module’s chipset was originally designed in the 1990s, the ARM9 was the core microcontroller for a complete mobile phone. Today, in the module’s role as an embedded cellular modem, the ARM9’s primary function is cellular control, which typically uses less than 20% of its total processing capacity, leaving excess capability available for doing other things.
However, designers can’t always assume their wireless module can take on a whole application since not all provide access to the ARM9’s excess capacity. Some modules, although using the same basic chipset as fully programmable modules, are shipped with only a subset of the ARM9’s pins connected to the external package, leaving its core inaccessible.
Today, designers have several options in choosing modules that provide full ARM core access. Some integrate an ARM946 variation of the ARM9 core with DSP functions often used in ASICs. At least one supplier is developing modules with other ARM cores, including ARM926 and ARM11, so designers will soon have more options.
Although hardware and software requirements vary by application, carefully consider these fundamentals.
To make sure the module’s resources can support the full application, check for available MIPS and memory resources as well as power consumption, especially if the application will use a battery.
The CPU MIPS are shared between the application and firmware for cellular communications. Table 1 gives average CPU consumption per service for a typical 2G M2M module.
To determine the number of MIPS available for the application, subtract MIPS necessary for cellular communications from the total available. For example, if a wireless module running at 104 MHz has 87 total MIPS available, peak GPRS transfer will consume roughly 16 MIPS (18%). The total 87 MIPS minus 16 MIPS used for GPRS leaves 71 MIPS available for the application.
Look for features that help maximize core performance. For example, direct access to low-level APIs for a UART, including interrupt handler, makes it easier for the CPU to drive external chipsets for things like GPS, Bluetooth, or ZigBee.
The module’s memory resources are also shared between cellular firmware and the main application. A memory management unit designed into the ARM9 core protects any partitioned memory and keeps them separate. Figure 2 shows the memory used by firmware in an example 3G module.
The example module has 128 Mbytes of total NAND flash memory and 64 Mbytes of total RAM memory. The cellular firmware needs 82 Mbytes of NAND flash for non-volatile data and 43 Mbytes of RAM for global variables, heap memory, and call stack. The remaining 46 Mbytes of NAND flash and 21 MBytes of RAM are available for the main application. Since NAND flash can’t execute code directly, code is copied into RAM for execution.
For very long lifespan applications some modules extend the life of flash memories by reducing the number of flash erasures. The system retains data for certain variables during a hardware or software reset. This increases the speed of restarts, especially after an unexpected event, because data can be retained in RAM.
Most modules include power-saving features, especiallywhen the system is idle. Standby power consumption typically rangesbetween 1.9 mA and 5.7 mA, good enough for a battery-powered system. Itmay not, however, be low enough for an application with extreme powerconsumption requirements, in which case using an externalmicrocontroller may yield better results.
Look for modules thatgo into sleep mode when the cellular function is inactive, and forfeatures like fast boot sequences or the ability to power individualblocks according to operating state, which can lower consumption. Somemodules suspend other battery-intensive operations when wirelesstransmissions are taking place.
Thebest option for an embedded system is a multi-tasking, pre-emptivereal-time operating system (RTOS) that is royalty-free and supports afamiliar programming language to keep total cost of ownership low.
Severalmodules are available with an RTOS customized for machine-to-machine(M2M) applications. They include cellular protocol and TCP/IP stacks,and are optimized for airtime and power consumption. Consider audiofeatures such as VDA class 2A for automotive, audio diagnostics andfilters, and audio player/recorder/sniffer functions. Data protectionfeatures such as fail-safe file system, SSL, and encryption engines helpincrease application security.
The ARM9 will probably manageexternal asynchronous events and need accurate timing functions. Lookfor an RTOS that reduces latency for asynchronous events and can driveseveral ICs connected either through SPI or I2C. This makes it possibleto extend the design with additional functions such as a CAN-controller,accelerometer, or vehicle sensors, Ethernet or Wi-Fi controllers, orsupplemental USB or UART devices. An integrated hardware timer combinedwith low interrupt latency makes it possible to time-stamp externalevents with good accuracy, eliminating the need for external timers.
Sincemany embedded M2M devices will be in service for a very long time, it’simportant to choose an RTOS with support for remote software upgrades.If the carrier changes its network or the application needs to beupdated, the software upgrade feature can be used to make changes.Over-the-air updates reduce service calls and help avoid recalls.
Agood selection of pre-configured software component libraries saves thedesigner from writing code for commonly used functions, so developmentmoves quickly and debug is simpler and faster. Table 2 gives a sample list of libraries and functions.
Somemodules are available with a PC-based integrated developmentenvironment (IDE) that lets the designer develop, compile, download,test, and debug an entire application. Look for an IDE based on Eclipse,a multi-language environment supporting Java, C, or C++. Othertime-saving features include project compilation with toolchain and GCCparameters, embedded debuggers, and the ability to monitor the targetwith AT, trace, and memory controls. Application libraries are oftenaccompanied by sample applications and example designs.
Toease the transition from development to deployment and to supportongoing maintenance, some modules are available with a cloud-basedmanagement service allowing remote monitoring and upgrade using a webportal. These services offer a way to test, install, and maintainwireless modules on any scale, in any location, while ensuring securityand keeping costs low. Management services are particularly helpful whenthe entire application is on the module because over-the-air monitoringand updates can evaluate and modify the application as well astelecom-related functions.
Using a wirelessmodule’s excess processing capacity to replace the microcontroller canyield a cellular-equipped system that is smaller, more efficient, andmuch less expensive to produce. Not all wireless modules can beconfigured as application microcontrollers, but designers have manyoptions. When making a selection, it’s important to consider hardwarespecs, including processing power, memory resources, and powerconsumption. Designers also need to weigh software-programming optionslike an RTOS and software libraries. A module should have available acomplete, easy-to- use development environment supported by devicemanagement services, for easier and less expensive long-term maintenancefor deployed systems.
Evan Jones is vice president ofM2M Engineering at Sierra Wireless and was instrumental in thedevelopment of the company’s 3G and 4G products. He holds an MSEEspecializing in DSP from the Illinois Institute of Technology, and aBSEE with an emphasis in Computer Engineering from Michigan StateUniversity. This paper was presented as part of a class (ESC-306) at theEmbedded Systems Conference at 2012 DESIGN West.