Buried Treasure: Unlock the Processing Power of Wireless Modules

Buried Treasure: Unlock the Processing Power of Wireless Modules

Abstract When embedded designers take advantage of the often-overlooked processing power of a wireless module, they can typically eliminate the system microcontroller and thus create an advanced, cellular-enabled system that is smaller, more efficient, and much cheaper to produce. This paper gives guidelines for choosing a module that will act as both microcontroller and modem. 2

The wireless module When considering ways to add cellular connectivity to an embedded system, many designers in the industrial and automotive sectors choose a wireless module. There are several reasons for this: wireless modules are preintegrated components, so they re already optimized for reliability, power, and design-in, and they perform cellular communications with a minimum of configuration work. Also, since they re pre-certified for use with existing 2G or 3G networks, they re ready for worldwide deployment. Figure 1 gives a high-level block diagram of a typical wireless module. The module contains all the analog and digital circuitry necessary for producing, transmitting, and decoding data over a cellular network. Figure 1. High-level block diagram of a typical wireless module The developer can interact with the module using familiar interfaces like UART and USB, and doesn t have to be concerned with the complex analog aspects of cellular communications. This can be a big savings for companies that don t already have wireless expertise in-house, since cellular radio frequency (RF) communication is a highly specialized discipline that often requires the full-time attention of an experienced analog designer. Engineers who are used to working in the digital domain face a steep learning curve if they re expected to design a cellular system on their own, so using a pre-integrated, pre-tested solution often presents an attractive alternative. Compared to a custom RF solution, a wireless module can shorten time-to-market, be less expensive to debug and prototype, and be more cost-effective in mass production. 3

More often than not, designers use a wireless module in combination with a standard microcontroller. The microcontroller is the central component in the system, managing the application and interacting with various peripherals, including the wireless module. In this set-up, the wireless module takes care of cellular communications, but not much else. This approach of using a wireless module as an auxiliary component in a microcontroller-based design is often the quickest way to add wireless connectivity to a system, especially when starting with an existing design. The bulk of the design remains unchanged, and adding the wireless module is a relatively straightforward task. The upgraded, cellular-equipped design can be ready to ship in very little time. However, since the wireless module and the microcontroller are usually the two highest-priced items in the bill of materials, using both in a system can be expensive. If volumes stay small, system cost may not be a problem, but as soon as quantities begin to increase, component cost can quickly become a serious issue. Fortunately, designers can often use an alternative approach. Taking a closer look at the product offerings reveals that many wireless modules are actually capable of doing quite a bit more than just managing cellular communications. This is because wireless modules typically integrate a highly optimized chipset, originally designed for use in lowend and mid-range cellular phones, that includes a 32-bit ARM microcontroller. By using this built-in processing power, designers can very often use the module on its own, without an external microcontroller, to manage the entire application. The wireless module can behave as both the central processor and the modem, creating a design that eliminates the need for an expensive standalone microcontroller. The resulting system is more compact, uses less power, and has a noticeably lower bill of materials. 4

Hidden talent Figure 2 gives a more detailed look at the sample wireless module given in Figure 1. The control circuitry is actually an ARM9 core, one of the most widely used control architectures in all of embedded. Figure 2. More detailed block diagram of wireless module, showing ARM9 core When the wireless module s chipset was originally designed, in the late 1990s, the ARM9 was used as the primary microcontroller for a full-fledged mobile phone. In addition to managing cellular communications, the ARM9 supported the keypad, a small LED screen, various audio functions, such as ringtones and other simple MP3 files, and USB-based connection to a personal computer. Today, in the wireless module s present incarnation as a cellular modem for embedded, the ARM9 s primary function is cellular control. But managing cellular communications typically uses less than 20% of the ARM9 s total processing capacity, so that leaves a large amount of excess available for doing a lot of other things. The fact that wireless modules usually include an ARM9 core isn t always obvious from the marketing literature. Wireless performance is often emphasized more than processing power, with product flyers highlighting specs for cellular performance, such as air interface, frequency range, data transmission, regulatory approvals, and compatible network carriers. The sub-components used in the module aren t always mentioned, and it can be difficult to find a block diagram. This is understandable, since wireless modules are, after all, designed to operate as drop-in solutions for cellular connectivity: knowing exactly what s inside the package isn t usually the engineer s first concern. So it s easy enough to miss the fact that there are unused ARM9 resources in the module. 5

On the other hand, designers can t always assume that their wireless module can take on a whole application, since not all modules provide access to the excess capacity of the ARM9. Some modules are configured to operate more purely as modems, with only limited support for customization. These commodity-like products use the same basic chipset as fully programmable modules, but are shipped with only a subset of the ARM9 s pins connected to the external package. The full potential of the ARM9 core remains inaccessible. It s important, then, if the designer wants to use the wireless module as both a microcontroller and a modem, to select a module that supports customization and provides full access to the ARM core. At present, designers have several options to choose from. The three modules listed in Table 1 are all currently available and have already been configured as microcontroller/modem combinations in large-scale deployments. Each module integrates an ARM946, a 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 have even more options in the near future.) Table 1. Sample integrated features and performance characteristics Embedded Wireless AirPrime Q2687 AirPrime SL6087 AirPrime SL8080 Module Air interface 2G GSM/GPRS/EDGE 2G GSM/GPRS/EDGE 3G HSDPA Processor ARM946/DSP ARM946/DSP ARM926/DSP Core frequency 26 or 104 MHz 26 or 104 MHz 184 MHz User MIPS available Up to 87 MIPS Up to 87 MIPS Up to 180 MIPS I/O voltage 1.8 to 2.8 V 1.8 to 2.8 V 1.8 V Standby power 2.4 ma 1.9 ma 2.7 V consumption UART 2 1 x 4- or 8-wire 1 x 4- or 8-wire USB 2.0 1 full speed (12 Mbps) 1 full speed (12 Mbps) 1 full speed (12 Mbps) SPI 2 1 1 GPIO Up to 44 Up to 26 Up to 7 RTC Yes Yes Yes SIM interface 1.8 or 3 V 1.8 or 3 V 1.8 or 3 V Temperature range -40 to 85 C -40 to 85 C -40 to 85 C Footprint 30 x 40 x 4 mm 25 x 30 x 2.65 mm 25 x 30 x 2.35 mm Specific hardware and software requirements will, of course, vary by application, but the specs given in Table 1 can act as a guide for initial selection. Beyond these basic statistics, there are several things, relating to hardware 6

performance, software programmability, design support, and device management services, to consider. Let s look at each in turn. Hardware performance It s important to be sure the wireless module has adequate resources to support the full application. Check for available MIPS and memory resources, as well as power consumption, especially if the application will use a battery. Processing Power The CPU and MIPS are shared between the application and the firmware for cellular communications. Table 2 gives average CPU consumption per service for a typical module. Table 2. CPU consumption per service Service CPU consumption GSM idle state 2% GSM call state 15% GPRS transfer rate 18% To calculate the number of MIPS available for the application, subtract the MIPS necessary for cellular communications from the total available. For example, if a wireless module running at 104 MHz has 87 total MIPS available, then GPRS transfer will consume 18% of that (0.18 x 87), or roughly 16 MIPS. The total of 87 MIPS minus the 16 MIPS used for GPRS leaves 71 MIPS available for the application. (It s interesting to note that even when executing GPRS transfer, this sample wireless module is more powerful than a CORTEX-M0 processor, which typically offers about 50 MIPS). Also, look for features that help maximize core performance. For example, direct access to the low-level APIs for a UART, including an interrupt handler, make it easier for the CPU to drive external chipsets for things like GPS, Bluetooth, or ZigBee. 7

Memory Resources As with CPU resources, the wireless module s memory resources are shared between the cellular firmware and the main application. A memory management unit (MMU), designed into the ARM9 core, protects any partitioned memory and keeps them separate. Figure 3 shows the portion of memory used by firmware in a sample 3G module. Figure 3. Memory usage in a sample module. The sample 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 8

memory, and a 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 applications with a very long lifespan, some modules offer a feature that extends 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 also increases the speed of restarts, especially after an unexpected event, because data can be retained in RAM. Power Consumption Most modules include features that help save power, especially when the system is idle. Standby power consumption typically ranges between 1.9 ma and 5.7 ma, which is likely to be good enough for a battery-powered system. It may not, however, be low enough for an application with extreme requirements for power consumption, in which case, using an external microcontroller may yield better results. Look for modules that go into sleep mode when the GSM stack isn t active, and check for other features, like fast boot sequences or the ability to power individual blocks according to their operating state, which can lower consumption even more. Radio transmission is taxing on the battery, so suspending services requiring peak current during transmission can lower overall power consumption. For example, some modules offer a special feature that suspends other battery-intensive operations, such as printing, when wireless transmissions are taking place. Software programmability The wireless module should give maximum flexibility for configuring the ARM9 core. Most embedded systems benefit from a real-time operating system (RTOS). The best option is a multi-tasking, pre-emptive RTOS that supports a familiar programming language, such as ANSI C or C++, and that is royalty-free to keep the total cost of ownership low. Also look for available scripting languages and application libraries, which save time and simplify design-in. RTOS Several modules are available with an RTOS customized for machine-to-machine (M2M) applications. They include GSM and TCP/IP stacks, and are optimized for air time and power consumption. Consider audio features, too, such as VDA class 2A for automotive, audio diagnostics and filters, and audio player/recorder/sniffer functions. Features for data protection, such as fail safe file system, SSL, and encryption engines, also help increase application security. 9

The ARM9 will probably have to manage several external asynchronous events and will need accurate timing functions. Look for an RTOS that reduces latency for asynchronous events and that can drive several ICs that are connected either through SPI or I²C. This makes it possible to extend the design with additional functions, such as a CAN controller, odometer or airbag sensors, Ethernet or Wi-Fi controllers, or supplemental USB or UART devices. Also, an integrated hardware timer (often a timer/capture unit), combined with low interrupt latency, makes it possible to time-stamp external events with a relatively high degree of accuracy, and can eliminate the need for external timers. Many embedded devices need to be in service for a very long time. Choosing an RTOS with support for remote software upgrades can make it easier to manage devices once they re in the field. If the carrier changes its network or if the application needs to be updated, the software upgrade feature can be used to make changes. Over-the-air updates can also reduce the need for service calls and help companies avoid recalls. Application Libraries Few things can save the designer more time than a good selection of libraries. These pre-configured software components, optimized for specific applications, save the designer from having to write code for commonly used functions, so development moves quickly and debug is simpler and faster. Table 3 gives a sample list of available libraries and the functions to look for. Table 3. Sample libraries Library Internet Security Location ecall Aplix Custom libraries Supported features UDP, TCP, FTP, HTTP, SNMP, email, gateway SSL, HTTPS, jamming detection GPS, NMEA frame, TTFF In-band modem Java virtual machine Proprietary IP Design support The idea is to choose a module that offers a complete framework for creating a full application. Review the development environment and ask about support services that can help simplify design and reduce time-to-market. Some modules are available with a PC-based tool, often called an integrated development environment (IDE), that 10

lets the designer develop, compile, download, test, and debug an entire application. Look for an IDE based on Eclipse, a multi-language environment that lets developers create applications using Java, C, or C++. Other time-saving features include project compilation with toolchain and GCC parameters, embedded debuggers with breakpoints, step-by-step, and watchpoints, and the ability to monitor the target with AT, trace, and memory controls. Application libraries, mentioned above, are are often accompanied by sample applications and example designs. Device management services Once a wireless module has been configured, there is the question of how to securely deploy, service, and maintain the systems. Sending technicians into the field each time there s a software fix or a firmware upgrade is expensive and time-consuming, and issuing product recalls to address problems can seriously impair operations. Many of the applications that use wireless modules have quite long lifetimes it s not unusual for wireless systems to stay in the field for 10, 15, or even 20 years so ongoing maintenance can be a serious consideration. To ease the transition from development to deployment, and to support ongoing maintenance, some wireless modules are also available with a cloud-based management service that let companies monitor and upgrade deployed devices remotely, using a web portal. These services offer a way to test, install, and maintain wireless modules, on any scale and in any location, while ensuring security and keeping costs low. Management services can be useful with any system that has a wireless module, but they re particularly helpful when the entire application is on the module, because over-the-air monitoring and updates can be used to evaluate and modify the application itself, not just the telecom-related functions. Choosing a wireless module that is supported by management services can yield significant benefits during development and once devices are in the field. Conclusion Using the excess processing capacity of a wireless module to replace the microcontroller can yield a cellularequipped system that is smaller, more efficient, and much less expensive to produce. Not all wireless modules can be configured as application microcontrollers, but designers still have a number of options to choose from. When making their selection, it s important for designers to consider certain hardware specs, such as processing power, memory resources, and power consumption. Designers also need to consider the tools used for software programming, such as an application framework supported by an RTOS and a complete set of software libraries. Also, designers should look for a module supported by a complete and easy-to-use development environment and, ideally, one supported by a device management service that makes it easier and less expensive to provide longterm support for deployed systems. 11