Advertisment

Downsizing Net Access

author-image
DQI Bureau
New Update

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.

Advertisment

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

taking.

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.

Advertisment

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.

Advertisment

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:

Advertisment
  • 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.

Approach A

Advertisment

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.

Approach B

Advertisment

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

e-mail.

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)

Advertisment

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.

Approach C

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).

EmWare (www.emware.com)

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

device

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

Basic.

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

Microchip.

The channel

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

wires.

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

Advertisment