While proprietary communications hardware and protocols can be defined for custom or secure applications, most of the time design engineers use hardware blocks to implement standards or protocols. Nowhere is this truer than with communications links.
Early on, links such as RS-485, RS-232, and IEE-488 were easy to understand and code. Simplified OSI models meant that designs could be forged from the ground up by a single engineer. Look at the complexities presented by USB, TCP/IP, Ethernet, and Power over Ethernet (PoE), and you can see that the once-simple solution is now a team effort.
To meet current time-to-market constraints, the design engineer requires higher level building blocks and a comprehensive development tool. The firmware and hardware chosen need to be integrated, tested, monitored, characterized, certified, and approved. Hardware and software engineers need to work together and the development tools are often where they become joined at the hip.
In the digital domain, the engineer usually can turn to his or her intuition or “hands on feel” to grasp how any part in a given design operates. We may not be able to design a better multiplier than the one in the processor we specify, but at least we understand what the multiplier is doing, how it works, and how to use it.
With analog, this becomes more abstract. While we may be knowledgeable about the function and use of an op amp, in all probability a relatively small percentage of us can say that they understand the intricacies and nuances of the well-designed op amp.
This uncertainty takes on an added layer when wireless technology is involved. Even for experienced RF engineers, it is an iterative process that often requires several spins. As a result, this is one area where an entire functional chunk of the design may be pasted onto a schematic and plopped onto a PC board, usually following a relatively risk-free “highly recommended” or “tried and true” layout.
To make the engineer’s life easier, chipmakers provide RF development and evaluation tools with working example boards or modules containing hooks that can be reprogrammed and used as a test and development platform.
A perfect example is the JN5148-EK010,596 from NXP. Supporting 2.4 GHz ZigBee (IEEE 802.15.4) designs, it contains five battery-powered wireless node modules that house temperature, humidity, and light level sensors based on the company’s JN5148 wireless microcontrollers (Figures 1A and 1B).
Figure 1A: NXP provides a very comprehensive design and development kit that contains five links, two of which are high powered. An LCD enhanced link is also useful for displaying parameters while field testing and evaluating performance.
Figure 1B: The 32-bit JN5148 architecture features a rich set of peripheral functions including audio, 12-bit A/D and D/A, and encryption engine.
These low-power 32-bit RISC CPU cores are aimed at home and building automation applications and implement the ZigBee stack with up to 128-Kbyte RAM and 128-Kbyte flash code and data space. They can be slave processors to a local host via the on chip SPI and UART peripherals.
For longer range tests and development, two of the five modules are higher power and provide 20-dBm maximum output levels. In addition, one of the modules contains an LCD so user code can display RSSI, for example, as well as other test and debug parameters that you may want to verify.
Tightly integrated is the C compiler, assembler, GNU debugger, and flash programming center based on the Eclipse standard IDE tool chain using JTAG as the connect mechanism. This environment supports RTOS implementations and helps manage the stack.
In this example the network stack is made available through an unrestricted development agreement with no licensing or fees needed.
Sometimes, third-party companies will partner with semiconductor suppliers to support the target chips. This lets a newer technology become available to designers sooner and enables additional expertise to be encapsulated in the development kits and modules. It also allows design engineers to use the chip maker’s tool chains.
A perfect example of this is Blue Radios’ BR-EVAL-LE4.0-S2A development kit for Bluetooth and Bluetooth Low Energy (Figure 2). As a fairly new standard, version 4.0 of the Bluetooth Spec is very different from the older standard Bluetooth (See the TechZone article “Low-Energy Bluetooth Gets Personal”).
Figure 2: The Blue Radio development kit supports both the Bluetooth Vers. 4 streaming audio link as well as the Bluetooth Low Energy mode.
The tiny Blue Radios (Figure 3) are based on TI wireless chips such as the CC2540. These embedded microcontroller radios also house both the RF protocol firmware, stack, user code and development space. Like the NXP parts, they include A/D converters for sensors, low power modes, flash (128 Kbytes), RAM (up to 256 Kbytes), I/O, and serial links like UART and even USB. A nice feature is that each CC2540 contains a unique 48-bit address
Figure 3: The tiny Blue Radio Chip Modules are based on the TI CC2540 embedded radio chip.
As a TI partner, the Blue Radio development environment uses the TI CC- Debugger to gain access to the chip during development and as a programming interface (Figure 4). By adding a two pin tx/rcv UART programming header to your board, you can update the firmware for the life cycle of the product. TI also provides a primer on Bluetooth technology.
Figure 4: Designers can take advantage of TI’s debugger for the CC series of RF systems to help develop and modify Blue Radios, or to help them design their own using the Blue Radios as a stable reference design.
Another reason to rely on development tools for complex technology is because standards often change, or are updated. Rather than become an expert on each standard, it is increasingly more prudent to let the chip suppliers keep track of, support, and implement updates and new versions.
A good example of this in the wireless link world is Wi-Fi. One highly integrated development environment that includes support for Wi-Fi comes from Freescale. For their Kinetis microcontrollers, based on the ARM Cortex-M4 32-bit architecture, Freescale offers a tower-based development platform using plug-in development boards (Figure 5). Freescale’s Wi-Fi development module is the TWR-WIFI-RS2101, which supports 802.11n data rates.
Figure. 5: The Tower-based Freescale development system provides designers with a flexible and reusable hardware and firmware development platform. Interface cards for debugging and PC interfacing can interact with specific development modules and user built prototypes.
The open-source Freescale Tower platform also uses the Eclipse development tool chain environment. Freescale can provide a rich selection of IP and includes an MQX RTOS. Its Code Warrior Studio manages projects and is kernel aware for MQX, Linux, and OSEK OS target environments. It also hooks to third-party compilers like IAR and Kiel, so you don’t have to relearn a new compiler if you already have experience and history with one.
This article has described development systems that target RF communications devices. Most often these integrate the development hardware, a PC, communications links, compilers, assemblers, libraries, and test tools to support application development at a high level. The tools discussed also measure the performance and effectiveness of your design. All development kits and the chips that they support have been linked to pages on the Hotenda website to further assist your design efforts.