Control and Monitor Arduino Over the Web Using ENC28J60

The NanodeUIP web server provides a mobile-optimized web page to control and monitor your Ethernet-connected Arduino. All you need is an Arduino and an ENC28J60-based Ethernet shield, or get a Nanode which combines the two together.

The home page shows the three functions the webserver can handle:

• Monitor Buttons
• Control Lights
• Monitor Sensors

Buttons

The ‘Buttons’ page shows the current state, HIGH or LOW, of a pre-defined set of digital input pins. See ‘Configuring’ below for details on how to change which pins are reported and what they’re labeled.

Press the ‘Refresh’ button to update the current state.

Lights

The ‘Lights’ page allows control of a pre-defined set of digital output pins. While they’re called lights, they could really control anything like a motor or camera or anything the Arduino can do.

Sensors

The ‘Sensors’ page shows the current value of a pre-defined set of analog input pins. Press the ‘Refresh’ button to update the current state.

jQuery Mobile

The UI relies on jQuery Mobile for a pretty interface that’s optimized for a mobile phone. All the CSS and JavaScript files are hosted by jQuery, so the Arduino web server just needs to point the browser at the right place to go get them. The extra markup doubles the size of the HTML, but there is still plenty of flash memory to spare.

NanodeUIP

NanodeUIP is an Arduino-compatible library for ENC28J60-based Ethernet hardware, like Nanode and EtherShield. It’s based on uIP, a mature, stable, well-documented TCP/IP stack. The library was originally created by Stephen Early based on Adam Dunkels’ uIP and Guido Socher’s enc28j60 driver. My fork adds numerous examples, including this one.

Getting it

This web server is included in my NanodeUIP fork as an example, see examples/webserver.

Using a Nanode, you can upload this sketch straight away to your unit and all is well. You can watch the boot-up messages in the serial monitor, and this will tell you what IP address it used. Load up that IP address in your browser, touch “Lights”, and toggle the “Red Light” switch. You should see the Nanode LED turning on and off as you do it.

The default buttons are on pins 2,3 and 4. Try connecting those to ground and refreshing the ‘Buttons’. The default sensors are on analog 0 and 1, so likewise try connecting those to ground or VCC and refresh to see the values change.

Using on EtherShield

For an EtherShield, it’s almost as easy. There is a line right at the top of the sketch you’ll want to un-comment. After modification, the first line of code says this:

#define ETHERSHIELD // uncomment to run on EtherShield


For a regular EtherShield, with the chip select pin on #10, that is all you need to change. If you’ve got something custom with a special CS pin, change the networking bringup section in setup(). Change the ‘SS’ in this line to the pin you need.

uip.init(macaddr,SS);


Configuration

The main thing a person needs to change in order to make the web server useful is to describe the pins which need monitoring and control. This is done in the webserver.ino file. Look for the “Pin Descriptions” section.

/**************************************************************************/
/**
* @defgroup pins Pin Descriptions
*
* The main purpose of this app is to control or monitor a set of pins
* from a web server.  This sections defines which pins are controlled
* and what they are called.
*
* @{
*/


The first code block lists the human-readable labels of all the pins. What do you want to call them? Each label needs its own line here, because it must individually be placed into program (flash) memory.

/**
* Easy-to-remember names of pins used in this sketch
*/
const char led_red_str[] PROGMEM = "Red Light";
const char led_yellow_str[] PROGMEM = "Yellow Light";
const char led_green_str[] PROGMEM = "Green Light";
const char button_a_str[] PROGMEM = "Button A";
const char button_b_str[] PROGMEM = "Button B";
const char button_c_str[] PROGMEM = "Button C";
const char analog_0_str[] PROGMEM = "Analog 0";
const char analog_1_str[] PROGMEM = "Analog 1";


The following block defines which digital output pins are controllable through the ‘Lights’ page.

/**
* Lights controlled by the web server
*/
const pin_def_t lights[] PROGMEM =
{
  { led_red_str, led_red },
  { led_yellow_str, led_yellow },
  { led_green_str, led_green },
  { 0,0 } // terminator
};


The following block defines which digital input pins are monitored on the ‘Buttons’ page.

/**
* Buttons monitored by the web server
*/
const pin_def_t buttons[] PROGMEM =
{
  { button_a_str, button_a },
  { button_b_str, button_b },
  { button_c_str, button_c },
  { 0,0 } // terminator
};


The following block defines which analog input pins are monitored on the ‘Sensors’ page.

/**
* Sensors monitored by the web server
*/
const pin_def_t sensors[] PROGMEM =
{
  { analog_0_str, 0 },
  { analog_1_str, 1 },
  { 0,0 } // terminator
};


Finally, the following function is called at startup to set the pins to the right input/output direction, and to register the pins with the CGI handler.

/**
* Ensure the pins are set correctly, and register them with the
* web server.
*/
void setup_pins()
{
  // led's are outputs
  pinMode(led_red,OUTPUT);
  pinMode(led_yellow,OUTPUT);
  pinMode(led_green,OUTPUT);
 
  // buttons are inputs
  pinMode(button_a,INPUT);
  digitalWrite(button_a,HIGH);
  pinMode(button_b,INPUT);
  digitalWrite(button_b,HIGH);
  pinMode(button_c,INPUT);
  digitalWrite(button_c,HIGH);
 
  // Tell the CGI which pins we care about
  cgi_register(buttons,lights,sensors);
}
/** @} */


Flash Filesystem

The web server builds a simple file system in program memory (flash), so it can serve those files back out to clients who request them. It is not necessary to modify the files on the flash filesystem under normal use. For more advanced use, it’s interesting to look under the covers. For a good explanation of what’s involved, let’s take a look at the Makefile in the fs directory.

The purpose of the Makefile is to create three files in the root directory. fs.cpp will contain the files themselves, transalated into C arrays so they can be processed by the compiler. files.h lists those files out, so they can be referenced by dir.h which works as a directory listing of files.

OUTDIR = ..
ALLFILES = $(OUTDIR)/fs.cpp $(OUTDIR)/files.h $(OUTDIR)/dir.h
all: $(ALLFILES)


The INFILES are the files from disk which will be compiled into the flash filesystem.

INFILES = $(wildcard *.html) $(wildcard *.shtml) $(wildcard *.txt) $(wildcard *.js)


The first step is to run xxd on all the input files, turning them into C files. These C files are collected in the xxd directory. They are run through an awk script to put them into program memory.

XXDDIR = xxd
XXDFILES = $(addprefix $(XXDDIR)/, $(addsuffix .cpp, $(INFILES)))
$(XXDDIR)/%.cpp : %
       xxd -i $< | gawk -f ../xxd.awk > $@


Next, the files are scanned into a directory structure using another pair of awk scripts. dir.h contains entries for each file, telling us the name of each file, where it’s located in memory, and how large it is.

$(OUTDIR)/files.h : $(XXDFILES)
       gawk -f ../files.awk $^ > $@
 
$(OUTDIR)/dir.h : $(XXDFILES)
       gawk -f ../dir.awk $^ > $@


Finally, all the C files are collapsed into a single CPP file, and copied up to the sketch folder.

$(OUTDIR)/fs.cpp : $(XXDFILES)
       cat $(XXDFILES) > $@


Common Gateway Interface (CGI)

CGI is the old-time term for web pages generated by code. This harkens back to a day when it was something new, because people actually hand-wrote HTML pages. Sounds shocking now! 🙂

uIP differentiates between three sources of HTML:

• HTML files (served by the httpd_fs file system)
• Server-generated HTML files (also served by the file system, but processed for special commands)
• Scripts (created by the httpd_cgi subsystem)

A file with an .html extention will simply be written straight out to the client when it’s requested.

An .shtml file is an html file with special handling. From an SHTML file, you can include other files, or run scripts.

A script causes one of the registered CGI handlers in httpd_cgi to be called. This is what’s used to generate the dynamic portion of the HTML result, including the current state of pins, and of course selecting which pins to display at all.