You’ve heard a lot about Internet appliances and
intelligent homes. It appears that in the not too distant future everything will
be connected to everything else and to you. You’re also told all the time how
useful and important it is to stay connected not just with everybody (that has
already happened with mobile phones and e-mail) but with everything around you
including your light bulbs.
I won’t therefore debate the usefulness of Internet
appliances but instead will look at what it takes to create an Internet
appliance, or at least a part of what it takes to make one. I’ll also explore
what the market has to offer at the moment, and the directions this field is
Connecting non-computer devices (we exclude for the moment
information appliances such as PDAs and mobile phones that also come under the
category of non-computer devices) to the Internet obviously means providing the
communication capability of the computer in the device. This means putting all
the software that you need to connect to your ISP (as well as additional stuff
in case you want the device to act as a server) into the device. Further, add to
this the data that the device itself is supposed to send.
Now, putting software into a device, say a light bulb, will
mean that the light bulb has to carry a microprocessor or a microcontroller
inside it. It will also need to send or receive some information about itself
(else, why would you want it to have communication capability?) and take
appropriate action. So it’ll need additional hardware and software to perform
some self-diagnosis and take corrective action.
If adding this capability increases the bulb’s cost by ten
times, you as a customer would think as many times before buying it. The
challenge thus is to do all this in the smallest possible device consuming the
lowest possible power thus translating to a low-cost device. And this is where
the race begins.
The chips and the stack
You have a choice of 8-bit, 16-bit and 32-bit parts with
increasing order of cost. The 8-bit devices have smaller memories and consume
lesser power. The market trend is still in favour of 8-bit devices (Refer
www.instat.com). This means that most gadgets already have or will have 8-bit
devices in them.
Hence, the urgency amongst microcontroller manufacturers to
be the first to port Internet connectivity software in their devices. An average
microcontroller configuration is about 256 bytes of RAM and 4 kB of ROM. The
memory footprint of a full-blown TCP/IP stack running on a PC is a lot more than
this. A rough estimate is 4 to 8 kB of RAM and 30 to 60 kB of hard disk space.
You can imagine the downsizing that is required and the features that may have
to be cut down.
Connecting to the Net
You could use any of these approaches:
Implement TCP/IP stack on a standard microcontroller–you
could write your own routines or buy ready-made stacks from a vendor
Use a dedicated chip with TCP/IP stack or buy routines
that you can embed in an ASIC
Use a gateway–here the device will communicate with the
gateway and the gateway does network communication
What does it take to connect to the Internet? You’ll need
routines to connect to a modem, the point-to-point protocol (PPP) to connect to
an ISP, TCP/IP routines with some application protocol sitting on top of it such
as HTTP (to send data using the POST method) or FTP (send a file) or Email
(e-mail a file) or maybe all of these. And all this has to go into a device with
a tiny memory, low power consumption and low cost–so that the cost of the
container device does not increase significantly. In addition, you will also
have to make the device secure, reliable, useful and easy to upgrade.
You can treat the Internet access feature as yet another
feature you need to add to your application and accordingly develop the
necessary routines for the same.
This approach is not always a wise one especially if the
time-to-market for your application is small. Alternatively, you can buy
Internet connectivity routines from a vendor. There are a number of vendors who
provide routines customized to the processor you intend to use.
You have here a choice of buying a dedicated chip or buying
software modules that you can port to an ASIC.
Scenix Semiconductor (www.scenix.com)
offers the SX52BD, a 52 pin uP with 4k x 12-word flash/EEPROM program memory,
256 bytes of SRAM data memory and fifteen 8-bit global registers. The software
modules offered is SX-stack that comes in two configurations: iSX Web server and
eSX e-mail appliance. The iSX server implements the physical layer, PPP, TCP/IP,
ICMP and HTTP, and enables communication with a Web server. The eSX e-mail
appliance configuration gives the physical layer, PPP, TCP/IP, ICMP with SMTP
and POP3 e-mail protocols thus allowing the appliance to both send and receive
Connect One’s iChip, a 68-pin PLCC surface mount package,
sits between your application uP and the communications line. You use high level
commands provided by iChip in your application to run PPP, UDP, TCP/IP, SMTP,
POP3 and MIME protocols. Connect One also offers iModem, an evaluation board
that uses iChip and SocketModem (from Conexant Systems) and the necessary
connector to connect to the phone line and serial port. (www.connectone.com)
iReady Corp (www.iready.com)
offers i-1000 Internet tuner. This is available as a set of Verilog RTL modules
for ASICs. The design is modular–with separate modules for TCP, IP, PPP, UDP,
HTTP, HTML, SMTP, POP3 and IMAP4. You can pick and choose the modules you want
to include in your application with a C language API.
The key contention here is: why port resource intensive
TCP/IP routines to individual devices? Why not have a central device (a computer
which in any case is found in most urban homes) that handles communication with
the Internet? The device does just what it is supposed to–send relevant data
to the central device, the gateway, using simple serial communications (RS-232,
RS-485 or Ethernet).
takes the gateway approach by providing various modules that perform the
different functions. Their EMIT (Embedded Micro Internetworking Technology)
software enables networking of 8-, 16- and 32-bit embedded devices with one
another and the Internet.
It has these modules:
EmMicro: A tiny Web server that resides on the embedded
EmGateway: The server software that resides on a machine such
as a PC and provides connection between the PC and the embedded device
EmObjects: Java-based software interfaces to the physical
devices. The physical devices with emMicro on them can be accessed and
controlled from a Web browser using these objects.
There is also a device access library that allows one to
access the devices from a custom program built using C, C++, Java or Visual
EmWare is also spear-heading the formation of an alliance of
various microcontroller manufacturers and development tools developers to
provide complete end-to-end device networking solutions. Called the ETI
Alliance, it consists of major players such as Analog Devices, ATMEL and
To complete the picture, some related issues. Once you have a
device and a chip inside it with the necessary Internet connectivity software,
you still need a channel to connect to the Internet. This brings us to modems,
wireless, power lines and all that.
You will need a modem depending on what medium you are using
to connect to the Internet: a telephone modem, a cable modem, an RF modem or a
power-line modem. The latter three will need additional support from ISPs.
If you want your devices talking to each other or to a
central computer (a network of devices), you’ll have to decide on the medium
that you’ll use to interconnect them and the standards for communication. You
have a choice of Bluetooth and HomeRF for wireless RF communications, IrDA for
IR communications, X-10 or CEBus for power line, Home Phoneline Networking
Alliance (HomePNA) for telephone wires, USB or RS-485 or Ethernet for plain
Once you have made a choice, you still have to decide on what
standards to use at the application level. Here you can choose from Jini from
Sun Microsystems, Salutation from Salutation Consortium, JetSend from
Hewlett-Packard and UPnP (Universal Plug and Play) based on Microsoft’s PC
Plug and Play.
Big players…big moves?
Most microcontroller manufacturers are on the Internet
bandwagon. The major players are also members of the ETI alliance. They are also
independently encouraging individual users to develop Internet connectivity
routines for their respective chips.
Some examples: Microchip offers an application note, AN724,
that explains how to port PPP onto their chips. Xilog has the eZ80, an embedded
Internet processor. National Semiconductor has brought out the Geode processor
that can be used in information appliances. The list goes on.
Hands on: IP to the chip
We wanted to see for ourselves what it takes to port the
TCP/IP protocol onto a chip. The chip chosen was Microchip’s PIC16C73, a
28-pin RISC-based microcontroller. This was used partly because it was a low
power chip and had in-built ADCs and partly because all the tools were readily
available. There also existed an application note (AN724 at www.microchip.com)
that goes as far as porting PPP onto a similar chip. In a couple of months we
had the PIC16C73 connect to a Linux server and get itself an IP address using
PPP. The next step was the task of writing TCP routines.
TCP, though a reliable protocol, is terribly resource
intensive. The protocol ensures reliable communications by insisting that the
called computer or application acknowledge if it received correctly the message
sent to it. The simplest way of doing this is for the device to send one packet
of information and wait (do nothing) till it received an acknowledgment and then
send the next packet. This would be a terrible waste of bandwidth. So TCP uses
the concept of windowing. This means a set of messages are numbered sequentially
and sent one after the other without waiting for acknowledgment (imagine a
window or a lens being placed on this set). Once an acknowledgment is received
for a message, the lens shifts to include the next message, the size of the
message set remaining the same. As you can imagine, this involves a lot of
housekeeping–keeping track of which messages were sent, which were
acknowledged, which messages need to be resent…TCP also negotiates line speed,
automatically sending more messages (increasing the size of the window) if line
traffic is light. All this is makes it memory intensive.
In our case, the data we want to send as a TCP packet is
quite small–some bytes of control or sensor data. So we did away with
windowing as well as line speed negotiation to reduce memory requirement. Once a
TCP connection is established, data is sent in the form of an HTTP request to
the server. A program residing on the server takes this data and appends it to a
file. The C program to do this worked perfectly with the Linux server.
We now have to test the program by accessing our server
through an ISP and finally porting this program onto the PIC and do the same
with just the chip and the modem. The final stage would be to create a
meaningful application around this.
Will it work in India?
The obvious question, as with many technological innovations,
is: are intelligent homes a luxury or a necessity? How can this technology be
made useful to Indian homes where a majority are rural? There’s no immediate
answer to the latter. But some applications certainly make life more convenient
or hassle-free. For example, a home inverter that can sense when the battery
needs to be replaced and informs us and the manufacturer before-hand would be a
useful thing to have. Thus we do not have to wait for the inverter to actually
break down and therefore suffer the summer heat. Or a water purifier that can
sense the state of its filter and send automatically for the serviceman would be
quite useful. Or some means by which we can assure ourselves that our homes are
safe while we toil away at our offices would be even better. An instance is a
gadget that sends e-mail to me as well as the police control room as the front
door lock is being tampered with.
Apart from homes, other environments where embedded Internet
would prove useful needs to be looked at, such as universities, schools,
business establishments and hospitals. One thing we are told constantly is that
embedded Internet is here to stay. But as of now it appears to be more the case
of a technology waiting for a killer application.
Meera S Datta
human-computer interaction lab,
NIIT’s Center for Research in Cognitive Systems