Designing an embedded Web server - Embedded Computing Design

the HTML pages that make up the contentof the demo with the scripts and specialsoftware that provide the interactivefeatures.HTML interface for demoThe HTML interface to the demo was byfar the simplest part of the application.Figure 3 shows the three frames that werenecessary:Figure 3■ The first frame controls camera settings:contrast, white balance, andexposure. The user sets each of theseindividually inside an HTML form.Once set, the values are submitted tothe server.■ The second frame controls the camera’sorientation using the ISMAP commandwith a GIF image representing theangular orientation of the camera.■ The final frame is the resulting picturein GIF format.Figure 4 presents the HTML to generatethe three frames. Each frame has a namethat can be referenced as a target for possibleoutput from other Web pages and asource HTML file defined by src. TheUSBldpg utility converts each page into Cfiles to be compiled with the rest of theapplication.Servo controlThe servo control mechanism also usesCGI in conjunction with an ISMAP insidethe camera position frame. The ISMAPpicture is a GIF image of a camera withrays indicating angular orientation (seeFigure 3). The ISMAP is embedded insidea hypertext link that points to theturnserv() CGI function. The HTML forthe camera position image is:When the user clicks on the cam256.gifimage, the ISMAP statement tells thebrowser to send an X Y coordinate to theCGI function turnserv(). The functionreads the coordinates from the argv[]parameters and converts them to an anglerelative to the camera center. This informationis sent to the servo controllerthrough the servo driver over the seriallink. Once the value is received, the servorotates the camera to a new position totake a new picture. Function turnserv()then sends all its output to the frame“Current Picture,” as specified in theTARGET statement, and the cam_ctrl()CGI does the same.Note that we could not take advantage of aclient-side image map for this functionbecause we were interpreting the positionof the mouse click to actually instruct thesystem running the server to move a servoto the specified position. This is differentfrom a more common use of ISMAP inwhich the location of the mouse click isused as an indirect indication of the nextpage to be loaded.Camera controlThe camera settings are controlled by anHTML form where the user enters new valuesfor the settings in three fields, then clickson the “Submit” button. Original camera settingsare restored when the user clicks on the“Reset” button and then submits the requestfor the image. Figure 3 illustrates the formatUSWeb Demo PageFigure 4of the form. Figure 5 shows the HTML usedto generate this form.The form command action names the CGIfunction to execute when the form is submittedto the server. In this example, thename of the function is camcntrl(). Thisform uses the GET method of transferringdata, meaning the data is sent as part of theURL portion of the request and will befound in the QUERY_STRING serverenvironment variable. The name and valuespecify the format of the data inQUERY_STRING, so QUERY_STRINGwill be “Request=Color” for the radio buttoncontrol. The GET method is useful forsmall amounts of data or for largeramounts of data. The POST method canbe used to send the data in the messagebody of the request.The server executes the camctrl() functionwhen it receives the browser’s request. TheCGI routine parses the information inQUERY_STRING and responds to the databy sending information back to the browser.In the case of camctrl(), if the CGI retrievesa fresh camera frame using the submittedparameters, the function would look similarto the code in Figure 6 on page 26 and 27.In this example, the CGI assumes theserver has some sort of structure asso-Winter 2000 / Applied Computing TechnologiesCopyright ©2000 Applied Computing Technologies. All rights reserved.

Camera ControlCamera Controls Contrast White Balance Exposure Color Gray Red Green Blue Figure 5ciated with the incoming request,request_ptr. This pointer is used whenresponding to a browser’s request. Basedon the construction of the form, the CGIis expecting a string of the form“Request=x,” where x is the value specifiedfor each radio button. Once the valueis found, the CGI responds by calling theappropriate function. The output is standardHTML sent back to the browser viathe PRINTF() function written for usewithin the embedded server. This specialversion of PRINTF() directs the output toa buffer that will be read by the Webserver. Other implementations may havedifferent conventions.The camera setting form uses the GETmethod because there is relatively littledata. When the user clicks on the submitbutton, this sends a request to theserver to initiate the CGI functioncam_ctrl(), which reads the data from theQUERY_STRING environment variable,then sends the new settings to the cameravia the camera driver. Once the camerareceives the new settings, it takes a newpicture, which is stored on the board. TheCGI then sends the file “picture.html” tothe Current Picture frame, which displaysthe new image.PictureBoth CGIs, cam_ctrl(), and turnserv(),generate a picture after setting the newcamera settings or rotating the servo bycalling the take_picture() function. Thefunction take_picture() sends an instructionto the camera to snap a picture. Thecamera responds by sending a bitmap ofthe current picture in sixteen shades ofgray. At this point, the server converts thebitmap to a GIF by using the graphics utility.The new image replaces the old imagein server memory and is sent to thebrowser for display. The server handles allcomputation.When the interface pages were generatedfor the demo, a placeholder picture wasused for the image to reserve memorybecause the image varies in size fromsnapshot to snapshot. The file specifiedfor the image was defined to have a maximumsize of 20 Kbytes. When USBldpgwas run to configure the server, it set asidethe 20 Kbytes of memory. The serveroverwrites this memory every time a newpicture is taken. Since the image neverexceeds 14 Kbytes, there is no danger ofoverwriting other parts of memory when anew image is stored.Problems encounteredInitially, a PC developed the demo. Oncewe ported it to the Net186, we met severalproblems almost immediately. The problemsencountered were normal fare whenCopyright ©2000 Applied Computing Technologies. All rights reserved. Applied Computing Technologies / Winter 2000

converting from a standard application toan embedded application. We knew thiswhen designing the demo, so each part ofthe demo that had to communicate withthe board was modularized. This allowedus to rebuild just the board dependentparts without making modifications to theoverall demo.Hardware interfaceThe camera was designed to run from aPC parallel port, not an embedded board.Thus, the most significant problem was todevelop the low-level interface to thehardware. To ensure that the board couldreceive picture data, we wrote a high-leveldriver on a PC to control the camera. Thisdriver interfaced with a low-level hardwaredriver that actually communicatedwith the camera through the parallel port.Once the camera software ran on a PC, wedeveloped a new low-level driver to turnthe thirty-one programmable pins on theNet186 into a parallel-port-like interface.Another driver was developed in a similarfashion for the serial port on the Net186.This driver provided the low-level communicationto the servo controller.Memory managementand image sizesMemory and memory management alsobecame an important issue when the softwarewas moved from the developmentPC to the embedded board. The picturegenerated by the camera is a 320 x 240pixel bitmap, which could easily consumeover 75 Kbytes of data space. Tosolve this minor problem, the picture wasgenerated using sixteen shades of gray soeach pixel required only four bits, andtwo pixels could be stored in a singlebyte. In addition, the picture was compressedinto a PNG using a free graphicslibrary available on the Web. Thisreduced the size of the stored image toapproximately 14 Kbytes. The graphicslibrary makes heavy use of malloc() andfile I/O functions. Therefore, we wroteembedded versions of these functions forthe Net186. These functions could beeasily replaced by using an embeddedfile system such as US Software’sUSFiles ® , which provides an interfacethrough the traditional file system functioncalls for a file system that is implementedusing a RAMDISK.ConclusionOnce all the pieces are integrated with eachother, the application becomes a functioningWeb server that can be accessed via serialor Ethernet connection. Each part of thecontrol interface has an associated CGIfunction capable of manipulating the cameraor servo hardware. In this particularembedded server, the CGI functions are thecore of the application. Several minor problemswere overcome to generate the demo.Replacement functions for malloc() andfile I/O were generated to replace the functionsused in the graphics utility. New driverswere also developed to interface theNet186 board to the parallel port cable ofthe camera and to the serial port of theservo control.Embedded developers who use this technologyin their projects can be assured ofsaving time while providing an industrystandardformat to their users.Nicholas Witcheyreceived his Ph.D. inHigh Energy Physicsfrom Ohio StateUniversity. He currentlyworks as an EngineeringManager at U SSoftware, applying his experience in software-hardwareintegration to developingand enhancing product technologies.Witchey’s interests include networkingand product research and development.His e-mail address is nick@ussw.com.ReferencesThe following references provide valuableinsight and techniques in generating Webinterfaces. They are intended for disk-basedWeb servers. However, most of the informationis also directly applicable to embeddedWeb servers.■ Foundations of WWW programmingwith HTML and CGI. Ed Tittel, MarkGaither, Sebastian Hassinger & MikeErwin. IDG Books, ISBN 1-56884-703-3.■ Kim, Eugene Eric. CGI DevelopersGuide. Sams Net, ISBN 1-57521-087-8.■ Boutell, Thomas. CGI Programmingin C and Perl. Addison Wesley, ISBN0-0201-42219-0.■ Graham, Ian S. HTML 4.0Sourcebook. John Wiley & Sons,ISBN 0-471-14242-5.Key issues in implementingan embedded web server■ What kind of throughput will theprocessor have to handle?Any selected processor must beable to handle the maximumexpected number of user requestsand expected data throughput.Also, the application’s designmust take the user load intoconsideration. For instance, iflarge data samples will bedownloaded, the CPU must beable to handle the outgoing datastream while being able to handlenew incoming requests. Thisimplies the application should beIO bound, thus allowing sufficientCPU cycles to handle any otheractivities. For infrequent requestsfrom the server, that is, onerequest at a time by one user at atime, a smaller CPU can be usedbecause large throughput and datarates are not an issue.■ How many users will use theapplication?The application will have tomanage the resources available tousers in order to resolve potentialaccess conflicts. This process canbe achieved through use ofsemaphores or mutual exclusionmechanisms found in most realtime operating systems.■ How many resources does theapplication need?If pages or images are builtdynamically, sufficient memorymust be available for storage andmanipulation. Images require alarge amount of space. Forexample, a bitmap image of 320 x240 pixels with 256 colors canrequire over 75K of data space.This requirement can be reducedif the image is compressed usingGIF or JPG file formats. However,adequate resources must beallocated to cover the greatestneeds of the application.■ How will the application interfacewith the server?The application can interfacedirectly with the server throughthe use of CGI functions in asingle threaded system. In a multithreadedsystem, the server canexist as a separate task. The rest ofthe application can update any ofthe pages, images, or other data inglobal data space, while the servertask’s only function is to send thedata to the browser.Winter 2000 / Applied Computing TechnologiesCopyright ©2000 Applied Computing Technologies. All rights reserved.

#include #include #if !defined(pyr) && !defined(NO_STDLIB_H)#include #else#include #include char *getenv();#include #endif#include #include #include #include #include #include #define MAXLINE 500#define MAXVERTS 100#define X 0#define Y 1//#define LF 10 /* Line Feed *///#define CR 13 /* Carriage Return */#define SERVPORT 1 /* Com port attached to servo controller */#define SERVBORD 1 /* Servo controller board number */#define SERVNUMB 1 /* Servo number on board *//*** Global picture paramters to be replaced by calls to** get_var() and set_var()*//*int CONtrast,WHItebal,EXPosure;char Color_MASK;*/#define TO255 256 / M_PIstatic void servererr(char *msg);static void html_print(char *msg);int takepicture(struct request_rec *reqp );int parse_parameters(struct request_rec *reqp, char *param_string);int loadnick(int argc, char **argv,struct request_rec *reqp){int rslt, rest, len;char *ptr;ENTRY *ep, *tep = reqp->fileinfo;ep=GetEntry(reqp,”nick.gif”,0);if(ep){rest = ep->ulen;ptr = ep->offset;rslt = Bwrite(reqp,ptr,rest);}}int camcontrol(int argc, char **argv,struct request_rec *reqp){char input[MAXLINE], *mapname, def[MAXLINE], conf[MAXLINE],errstr[MAXLINE];double testpoint[2];int i, x,y;double dist;char *t;ENTRY *ep;char *pParams;pParams = Ngetenv(reqp,”QUERY_STRING”);/*** Set camera settings based on QUERY_STRING setttings*/parse_parameters(reqp, pParams);/*** Take Picture*//*** html file specified by browser when clicked*/YIELD();takepicture(reqp);/* Figure 6Copyright ©2000 Applied Computing Technologies. All rights reserved. Applied Computing Technologies / Winter 2000

}** html file specified by browser when clicked*/pictureframe(1,&”pictureframe”,reqp);return 0;static void servererr(char *msg){printf(“Content-type: text/html%c%c”,10,10);printf(“Camera Control Setting Message”);printf(“Bad Camera Control Setting”);printf(“One or more settings for the camera are bad:”);printf(“%s”, msg);exit(-1);}typedef struct {char name[32];char val[16];} entry;extern int CONtrast;extern int WHItebal;extern int EXPosure;extern char Color_MASK;int parse_parameters(struct request_rec *reqp,char *parstr){int m,x, i=0, iscolor;entry entries[6];char *tmpstr;int icntrst;int iwhtbal;int iexpsr;char shades[2]; /* color shade */tmpstr = GETENV(“QUERY_STRING”);if(tmpstr == NULL) {PRINTF(reqp,”No query information to decode.\n”);EXIT(1);}for(x=0;tmpstr[0] != ‘\0’;x++) {m=x;getword(entries[x].val,tmpstr,’&’);plustospace(entries[x].val);unescape_url(entries[x].val);getword(entries[x].name,entries[x].val,’=’);}/* 0= contrast, 1=whtbal, 2=exposure, 3=color *//*** Work on finding the contrast first. We should always** have a contrast.*/icntrst = atoi( entries[0].val );if( icntrst < 1 || icntrst > 254 ){servererr(“ Bad Contrast Setting. Must be 1 to 254 “);return -1;}elseCONtrast = icntrst;/*** Next find the white balance.*/iwhtbal = atoi( entries[1].val );if( iwhtbal < 1 || iwhtbal > 254 ){servererr(“ Bad White Balance Setting. Must be 1 to 254 “);return -1;}elseWHItebal = iwhtbal;/*** Now find the exposure*/iexpsr = atoi( entries[2].val );}if( iexpsr < 1 || iexpsr > 254 ){servererr(“ Bad Exposure Setting. Must be 1 to 254 “);return -1;}elseEXPosure = iexpsr;/*** Now check to see if a color has been specified. This one** is different than the others because it’s at the end of** the query string. If they user forget to hit a radio button** nothing appears at the end of the string.*/shades[0] = *entries[3].val;shades[1] = ‘\0’;Color_MASK = shades[0];/* html_print((char *)&shades); *///servererr(“ Bad Color Setting. Must be Gray, Red, Green, or Blue “);Figure 6 (Continued)Winter 2000 / Applied Computing TechnologiesCopyright ©2000 Applied Computing Technologies. All rights reserved.