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.

  • \$\begingroup\$ This questions is very broad, please try to focus in on a specific technical question. \$\endgroup\$
    – Kortuk
    Jun 12, 2013 at 20:51
  • 10
    \$\begingroup\$ Voting to reopen. This question is good enough. \$\endgroup\$ Jun 12, 2013 at 22:28
  • \$\begingroup\$ "We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion." \$\endgroup\$
    – The Photon
    Jun 13, 2013 at 16:23
  • \$\begingroup\$ I am glad that finally I can see how this concept is use in the industry. But from this a new question is generated, seeing that implementing a server on a uC and than creating user interface that runs in an internet browser makes things so easy, why do many people still resort to harder ways like USB? \$\endgroup\$
    – quantum231
    Jun 27, 2013 at 9:00
  • \$\begingroup\$ @quantum231 Please ask a fresh question if you have a fresh question. :-) \$\endgroup\$ Jun 28, 2013 at 8:16

6 Answers 6


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.

  • \$\begingroup\$ It's worth noting that many simple web servers, when they receive a request, will immediately send out everything they're ever going to send in response to the request, close the connection, and forget about it. This reduces the TCP RAM requirements, but puts some severe limits on web-page complexity. It's possible to design a stateless TCP server which can keep an unlimited number of connections open (I've done it), but such a thing would require a custom client-side front-end. It's simplest to keep things small enough to allow stateless HTTP operation. \$\endgroup\$
    – supercat
    Jun 13, 2013 at 15:25
  • \$\begingroup\$ NOTICE: I tried downloading "install_picdev.exe" but Firefox (or Windows Security Essentials) said it is malware. Not going to open it. \$\endgroup\$
    – ahogen
    Nov 27, 2018 at 1:13

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.

  • \$\begingroup\$ Good answer. Regarding applications i miss the mentioning of some common consumer electronics that often can also be accessed and configured using a browser. Printers, TV sets, home cinema audio receivers, routers... I bet there are even remotely accessible coffee machines :) EDIT: Granted, some of those have the processing power of a modern PC and are not micro controller based. \$\endgroup\$
    – Rev
    Jun 13, 2013 at 7:18
  • \$\begingroup\$ I would add that the choice between having something like an appliance communicate via HTTP versus something else is generally a choice between making the appliance itself slightly more complicated, versus requiring the user to buy or install some dedicated hardware or software to communicate with it. It may be cheaper and more energy-efficient to build a temperature sensor that uses a proprietary RF scheme to communicate wirelessly with a USB dongle than to include a WiFi adapter in the temperature sensor, but the latter approach avoids the need for the dongle. \$\endgroup\$
    – supercat
    Jun 13, 2013 at 21:29

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:/// (if I remember correctly...).

  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.

  • \$\begingroup\$ Consider also the Texas Instruments MSP430 family of microcontrollers: Insanely low power consumption and ample capability for web serving. 16 bit processing. Some options include wireless networking out of the box. Size: A complete board with wireless connectivity can fit into a thumb drive. \$\endgroup\$ Jun 13, 2013 at 6:42
  • \$\begingroup\$ These answers just answer one part of the question. Why do we do it? What about the next part; How do we do it? What skill sets are required? \$\endgroup\$
    – Anshul
    Jun 13, 2013 at 6:48
  • 1
    \$\begingroup\$ @Anshul You need to code to the http server specification, and you need a network stack (ip/tcp/udp) or similar, depending on which network IC you choose. \$\endgroup\$
    – Passerby
    Jun 13, 2013 at 7:07

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.

webACE chip webACE cable

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

  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.


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

  • 3
    \$\begingroup\$ It's hardly much of a challenge. You can download demos that have a web server built in. \$\endgroup\$ Jun 13, 2013 at 10:48
  • 1
    \$\begingroup\$ It would be a challenge if you'd write your own TCP/IP stack from scratch.. \$\endgroup\$
    – m.Alin
    Jun 28, 2013 at 9:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.