Microcontroller Solutions TechZone Magazine, April 2011 - Digikey

In all of the aforementioned deeply embedded devices, latency
is not critical. Other applications where latency is not critical
include security or environmental sensors, data-upload services
for medical monitoring, and consumer news devices, as well as
information servers.
Deeply embedded devices don’t need 300 Mbps, 54 Mbps or often
even 11 Mbps of throughput. A majority of deeply embedded devices
use a low amount of bandwidth. They have data for transmission
a few times a day, or expect to receive data possibly once a day.
The amount of data they deal with is on the order of 100 bytes. By
keeping external memory minimized or not using it at all, the overall
system cost and power consumption remain low.
A normal infrastructure connection provides about a 5-10 second
reconnect period from the hibernation stage. The connect processing
between the Wi-Fi radio and an access point takes about 176 ms.
Connecting takes longer than this, so the majority of the time is
spent in the delays associated with the access point dealing with the
connection. This can be easily seen by virtue of the time it takes a
standard laptop (a high-end open system) to connect to a network.
This time can be reduced by using the static addressing feature of the
Microchip TCP/IP stack. With such an operation, the connect time with
security can be reduced to less than a second.
Ad hoc connection from a power up can take less than 200 ms.
For point-to-point-only remote-control devices, ad hoc operation is
suitable because the achievable connection times are short. This
method of operation is not often used for remotes because while
it does resolve the connection-time problem, the limited use of the
wireless technology for simple point–to-point only communications
without LAN or internet connectivity can be better served by other
wireless technologies, such as basic RF transceivers or the IEEE
802.15.4 protocol.
A very good application of the ad hoc mode of operation is as a
default mechanism to enable easy confi guration of the device onto
the network of interest. Deeply embedded products that do not
have a screen/keyboard to enter data need a method for the end
user to confi gure the network, as well as the security parameters
of their network. In this case, the codes can be entered using a
temporary network. To use a temporary network, the product must
be preconfi gured to start either searching for a pre-determined
infrastructure network, or by creating a pre-determined ad hoc
network. In either case, another computer or Wi-Fi-enabled device
(e.g. iPhone, Smartphone, etc.) connects to the product using the
pre-determined network, and then confi gures the product to the
fi nal desired network. Once the appropriate network information
is entered, a command can be sent to the product to restart in the
desired network.
One advantage of 802.11 for deeply embedded devices is the
ability to use pre-existing networks and the Internet. There is some
concern regarding the impact to performance for other computers
that use the network, when a low-bandwidth, deeply embedded
device is also attached to that network. Wireless communication
is a shared-bandwidth, media-access mechanism. There is a fi nite
amount of bandwidth available for all to use before the airwaves get
saturated with signals. The biggest impact is from clients utilizing
the available bandwidth. Thus, adding a second 802.11g laptop
to a network that already has an 802.11g-connected laptop on it
will reduce the available bandwidth by 50 percent. The hibernate
mode described earlier for power savings also serves, in this
case, to minimize the effect on the network of embedded devices.
Embedded devices should be confi gured to buffer their information
and burst as required. Such usage will allow the devices to get on
the network, transfer their data, and then get off the network. The
effect of this will be maximum power savings and minimal impact
on network-bandwidth capabilities.
Figure 4: Example of mixed devices in a network.
A critical need of deeply embedded systems is to keep the
communication system easy to implement and use. While the
802.11 protocol makes an ideal candidate for communication for
these devices, many manufacturers are specialized in the art of
their own product, and not in wireless IP communications. There
is often no room in a critically costed product for more memory
to run an operating system, in order to use an off-the-shelf driver
that traditional 802.11 solutions offer. These drivers are created for
complex operating systems, such as Windows, Windows Embedded
CE, or Linux.
A signifi cant benefi t of a solution like the Microchip 802.11 one is
the ease of implementation to the developer. Along with the basic
networking features of security, infrastructure, and ad hoc; the
stack supports various services that a deeply embedded product
developer would require. Some of the services supported are ICMP,
HTTP, SSL, DHCP, FTP, SMTP, SNMP, TFTP, DNS, and Telnet. These
are suffi cient for serving Web pages, sending and receiving data
fi les, and handling e-mail services. The value to the customer is
the ability to minimize code-space requirements by selecting only
the services they require, accelerated time-to-market, and allowing
concentration on device application and user interface, rather than
on the underlying communications protocol.
The “Internet of Things” is about connecting a diverse set of simple,
deeply embedded devices to the tools we already use. It allows
servers and other instruments that can work in the background to
provide a clearer understanding of what is happening—whether
the interest is in energy conservation, product maintenance, health
and safety, or just information retrieval. The Microchip 802.11
solution has been designed with the mindset for deeply embedded
devices. This solution takes into consideration the speed, bandwidth,
and latency needs of embedded devices—these being much
42