Why do people create web server on a microcontroller?

Question

I have come across people creating web servers using microcontrollers, why would someone do that? What are its applications? What skill set besides C language does one need in order to create such servers? I am quite curious about these tiny servers having such small RAM.

Answer 1

I have done this in a few products. So far the reason has been to allow for simple field configuration. Each time the product already needed to be connected to ethernet for reason of its main operation. The web server was therefore merely added code in the microcontroller.

The big advantage of a HTTP server is that no special hardware or software is required to present a reasonable user interface to the end user. Everyone already has a web browser, so this is no bother for the customer. Think about other alternatives. You could provide a RS-232 port, but then you either have to provide a custom app or explain to someone how to set up a terminal program with the right baud rate, start bits, stop bits, and parity. You also either have to supply a cable or hope the customer has one, and someone has to go to the unit and physically connect to it. USB doesn't have the same configuration problem, but would generally mean a whole separate micro in the product and there you need a custom program to run on whatever platform the customer might have.

As for RAM, that's not much of a issue for a HTTP server. A TCP protocol stack needs some RAM, but the HTTP server not really, except for the extra resources it may require from the network stack. A web server mostly needs ROM space, since most of every page is constant, usually with a few values converted to text and inserted on the fly. Web servers for small micros work with ROM file systems and escape sequences in those files that cause your application code to be called to produce customizable strings for insertion at a few pre-defined places.

So far I have used a PIC 18 in all these cases. While the less then 4 kbytes of RAM is a limitation, there is still a lot you can do. ROM space hasn't even been close to a issue. My network stack for the PIC 18 (available in my PIC Development Tools release at www.embedinc.com/pic/dload.htm) takes only a small fraction of the ROM space of a 18F67J60, which is a nice part for such things since it has a complete ethernet MAC/PHY built in. In one case I have that PIC being a server for 6 simultaneous TCP connections. It's really not as heavyweight as people seem to think.

Answer 2

A key contributor to the recent rise in popularity of web servers on microcontrollers is the desire to access physical sensor information (temperature, humidity, light level, presence of carbon monoxide etc) remotely, as well as make things happen in the physical world (switch on an LED, trigger an alarm, switch on an emergency exhaust fan, turn on a coolant pump) also remotely. Those are the applications.

What better way to achieve generic, consistent, device independent, designer-independent remote access than the ubiquitous HTTP protocol, over the even more ubiquitous IP network? The physical layer of communication could be WiFi, wired Ethernet, or any other convenient option that supports IP networking. That is why web servers on embedded devices are being done.

For further insight, one could search for the "Internet of Things" and see the wide range of thought processes that brings up.

Regarding the "tiny servers having such small RAM", it is worth noting that the HTTP protocol is simple enough to be implementable on very little RAM, with very little processing power. Also, today's microcontrollers are comparable to, or in some cases more powerful than, the processors on the early personal computers on which people have implemented not only the web, but also carried out a variety of interactive tasks, even played games.

Answer 3

Many networked devices provide a web server for examining and setting configuration parameters, checking status of the device, etc. For example, I can configure the router in my system by pointing my browser at http:///192.168.0.254 (if I remember correctly...).

Answer 4

1. Because they can.

2. Because they can be very low power. Like under 1W with some peak draws. Under half an amp. Battery and solar power is practical, unlike bigger computers.

3. Physical size. A microcontroller + wifi or ethernet chip can be the size of a thumb drive.

4. Cost. A microcontroller suitable for this could be in the single dollar range. The networking parts almost as cheap.

5. Disposable. You can put them in one off projects and if they die, it's not as bad as if an expensive computer does.

6. Just cause.

With the advent of full blown computers for tens of dollars (free to $100) (shrevaplugs, raspberry pi, smartphones, linux thumb drives, android sticks, ROUTERS), you will probably see less of microcontroller web servers in the future, because there is no longer COST and Size as a driving factor. A 35 dollar Raspberry Pi or 45 dollar Beaglebone can outperform an Arduino + Ethernet or Wifi shield in cost, performance, ease of setup. It's barely bigger than the arduino. Only thing the arduino can do over it is power efficiency 0.1W (0.5mA to 50 mA sleep to full computing power [5v, 16mhz, 100% cpu] by the ATMEGA alone) vs 4W for the RPI with no ethernet/hdmi/usb usage at idle.

So microcontroller webservers can be battery powered due to low current consumption. Even then, some of the newer linux SoC like a pocket router with a webserver can be close to them.

Answer 5

Olin's answer pretty much hits on every reason I've used an embedded web server. I work developing industrial controls and almost every product we produce has an embedded web server.

Most customers will have all of their equipment on their network already for various reasons. So being able to configure and/or control it through a web browser instead of installing dozens of custom programs is highly desirable.

Even if they are using an industrial protocol like PROFINET, the physical layer is the same as the rest of their Ethernet and then they only need one piece of software (a PROFINET IO supervisor) to control dozens of machines. In my experience, this set up is fairly standard across many industries.

With regards to resources (processing power, RAM, ROM), when chopped down to the bear essentials, incredibly minimal hardware is needed to successfully serve up a web page. webACE I think holds the record for tiniest web server. It's a shame you can no longer visit the page it hosted.

The Software

Some code statistics for the original software. I had originally forgotten to include the on-chip 64 byte "data eeprom" in the totals, which led to the 1010 bytes figure quoted on TBTF.

Startup       36 bytes
Serial       179
SLIP          91
IP           144
ICMP          47
TCP          188
Checksum     132
Application  257
Total       1074 bytes

Comprising:
  454 instructions
  912 instruction bytes
  162 data bytes
 2.01 bytes/instruction average

As for other skills needed, a deep understanding of networking is not really necessary. I've never written a stack for any protocol because there are a plethora of libraries available to be linked in and used for every conceivable architecture. Knowing some basic raw HTML is useful for designing and writing the actual page.

Aside from that being able to read and understand a log from Wireshark or Fiddler (network analyzers) will probably be the most useful skill as it will greatly aid in debugging any issues you have. A little reading on the packet structure of whatever protocol you're using (TCP, IP, HTTP, UDP, PROFINET, etc.) will tell you where to look in the packet for whatever information you need. You can even fire up one of those analyzers right now and look at the traffic coming and going to your computer to get a feel for it.

Answer 6

One of the reasons is for the challenge. More so if you develop the microcontroller board and/or write your own software.