Unlock the processing power of wireless modules
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.
Currently no items