An Android tablet can serve as a touchscreen in a kiosk or embedded system, but communicating with it can be a problem when power must be supplied over USB.
Using Android Tablets as Embedded Components, Part 2
Communicating via NFC or WiFi
by Jerry Epplin
In Part 1 of this series, I proposed the use of low-cost and readily-available Android tablets for many embedded systems. An application in need of an attractive touchscreen, good processing power, and a mature and familiar API may be able to use an Android tablet for its front end. I also addressed a number of potential drawbacks, including quick tablet product cycles, a somewhat inflexible GUI API, and the simple matter of turning the unit on and off, and proposed some ways to manage these drawbacks.
Perhaps the greatest challenge is figuring out how to communicate with the unit when the only wired means of doing so is through the USB port, which in most cases must be used for powering the device. As I noted in Part 1 of this series, dual-function USB ports that serve as the tablet’s only power input are generally limited in charging current, such that an always-on display will typically drain the battery despite continuous charging. Consequently, with the sole wired connection devoted to power, one must choose among the various contactless options available on Android tablets.
In Part 1, I addressed the use of Bluetooth as an alternative to USB for embedded tablet communications. Bluetooth is mature, stable, and works well in practice for many applications. Below, we look at two other potential alternatives to USB for wireless communications with the system’s control board: WiFi and NFC. At first glance neither technology seems a good choice for internal communication in an embedded system, but a closer look may change that impression.
As a technology initially focused on reading RF tags and now expanded into payment systems and other transient forms of communication, NFC may not seem like an appropriate choice for ongoing communication between components of an embedded system. But some factors have come together to make this a good solution after all:
- Recent ICs have taken NFC capability well beyond reading and writing simple data. Here I’ll focus primarily on NXP’s NTAG I2C line, but TI has some similar chips.
- Android’s support for NFC is quite nice. As a result, adding the ability to pass data to and from an NFC-connected component to your application is straightforward.
Recent ICs take the older idea of RFID chips and simply add another interface so they can talk to a connected microcontroller. NXP’s have an I2C interface, while TI’s have both I2C and SPI. While the NXP and TI lines have similar capabilities, NXP excels in having an especially nice demo kit, available for about $20.
NXP’s OM5569 NFC demo kit
(click image to enlarge)
The NXP chips contain a small amount of EEPROM (888 bytes for the “1K” version and 1904 for the “2K”), but more important are the 64 bytes of SRAM.
NXP NT3H1x01 NFC controller block diagram
(click image to enlarge)
Data can be written to SRAM locations from either the NFC side or the I2C side, then read from the other side, all with access being coordinated through dedicated arbitration circuitry.
This model works well for many embedded systems in which the front end and back end communicate through a shared memory model; e.g., the front end indicates a user request for a particular operation by setting a “request” value, then the back end indicates the status of the operation by setting a “status” value. This approach works well in conjunction with a simple polled mechanism, and the NXP ICs also have an output pin that can be configured to assist if an interrupt-driven scheme is desired for the I2C side.
Using NXP’s NT3H1x01 chips to move data between I2C and NFC
(click image to enlarge)
The chips also provide a “pass-through” mode that is designed for streaming data from one side to the other. With a listed throughput of 106Kbps, the interface is plenty fast for most realistic embedded systems.
Testing the throughput of NXP’s NFC-to-microcontroller demo board
(click image to enlarge)
I found the NFC-to-microcontroller throughput to be about 500 bytes/sec, with the opposite direction about twice that fast using the pass-through mode. Data acquisition applications in which you want to stream collected data to a tablet might seem uncommon; but one could imagine, for example, healthcare or “quantified self” applications in which short bursts of biometric data are collected. Streaming the opposite direction is perhaps even less likely, but the capability is there.
The NXP and TI chips can be had for about $1 even at low quantities, so the use of the newer NFC chips looks like an attractive option for facilitating communication between an Android tablet and an attached embedded system.
The EEPROM included in the NXP chips is also nice in that it can be accessed via the RF interface. This makes it possible to program configuration data into your control board without needing to implement a separate connector for that purpose; or even implement firmware, as the EEPROM can be programmed directly without any firmware intervention. Indeed, this can even be done without the board being powered up, as the chips use an “energy harvesting” scheme to allow them to be powered from the tablet via NFC.
All of this becomes very attractive for streamlining your manufacturing process. With some simple Android app code you could be set up to configure your boards for specific customer use cases without any firmware intervention at all. This is quite handy even apart from any runtime use of the NFC capability.
NXP’s development support for the NTAG I2C line is especially nice. The demo kit comes with the 1k NTAG I2C chip, an ARM Cortex-M0+ microcontroller, a JTAG connector in case you want to develop some initial code with the board, and three switches and three LEDs for demonstrating and testing I/O. The firmware source code is available [zip file] for download. The well-designed Android app is available on Google Play, or you can download [zip file] the clear, well-written source code, which can serve as a nice basis for the interface part of your Android app.
Security for a system based on NFC might be considered superior to that of Bluetooth for the simple reason you have to be very close to the unit to communicate with it. Apart from any encryption used, an attacker would have to be working immediately adjacent to the unit to be effective. In my own use I had to position the NFC chip within a very small volume around the back of a Nexus 7 tablet to make it work at all. As with any wireless communication technology, you can always add an encryption layer on top if security is a concern.
What about WiFi?
A perhaps less intuitive choice for communication between a tablet and a control board in an embedded system is WiFi. Currently all current tablets have WiFi capability, and Android’s support for it is complete and mature, so certainly the tablet side is well covered.
On the other hand, WiFi interfaces have traditionally been quite expensive by the standards of embedded system components, and full networking stacks have typically not been implemented on low-cost control boards. Running a control board with Linux or another full operating system would take care of the stack nicely, but that still leaves the rather large class of systems either lacking an OS or with a minimal one.
There are a number of reasons you might begin to consider WiFi:
- As mentioned, you’re already using Linux, and your hardware already has a WiFi interface, or one can be added inexpensively.
- You need to stream data quickly, either to your tablet or to some upstream server. The ability to connect directly to some available wireless router and stream data directly might be helpful, albeit in rather limited circumstances.
If, for example, your back end control processor is a Linux SBC to which you can add a WiFi dongle, you can set up a VPN between it and the Android tablet, then communicate between the two using your favorite IP-based protocol; or, more likely, just use whatever WPA-based security is available. This approach may be attractive if the back end controller needs access to the Internet apart from communication with the tablet.
One might also consider one of the many newer modules dedicated to adding WiFi to embedded systems. Those based on the ESP8266 have become popular, especially among hobbyists. These have dramatically lower costs than the previous generation, and are commonly priced well under $10.
A typical ESP8266-based WiFi module
(click images to enlarge)
They also are quite compact, though certainly not as microscopic as the NFC chips I’ve addressed. They typically interface to your system via UART and provide an AT-style syntax [pdf file] for joining a network, connecting to a host, and communicating with the other side.
If the command set contains the functionality you need and you don’t mind the questionable long-term availability and poorly translated documentation of these newer modules, this might be a good choice for your device. The ESP8266 chip itself is an SoC that provides a variety of other I/O, so you could use the chip to build an entire system around it.
Depending on your needs, one of the newer NFC chips or recent WiFi modules might be a cheap and practical way to complete an embedded design based on an Android tablet.
Photo credit: The kiosk thumbnail image at the top of this post is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license. It depicts an Internet kiosk in Hemer, Germany that is not known to run Linux or Android software. Other images were obtained from the component vendors’ product documentation.