I am having a question about a design of a system. My goal is to integrate a single board computer into a existing measurement system. A webserver should run on the SBC so that the system can be configured with a browser. If it is possible it would be great if the website could display und update the measurement values without clicking refresh button etc. The approach that i can think of:
1.) use of linux or windows ce and their built-in webservers
2.) programming of a application which controls the measurement system.
3.) using some interface-technology (cgi?) to connect the webserver with the control-application.
4.) using some scripts embedded in html which the webserver then parses and fills in the values which the control-application returned for example.
So far so bad :) As i am a newbie i would be glad about all comments or suggestions about which technologies to use (cgi for interface? , php for scripts?, win ce with asp? or linux?,...) or about possible designs for this problem. I have googled quite long but it hard to find examples for such a application.
Well, if you can put an OS that has a webserver on the SBC, that's certainly simplest. OTOH, writing a basic web server is not all that difficult either (particularly if you have a TCP/IP stack already), but you're only going to have basic functions, and there will be a non- trivial learning curve if you don't know what a web server really does already.
CGI is only sort-of a technology. The term gets used two ways. First as a general reference to any program (script, compiled, or whatever), that the web server will invoke based on the contents of the HTLM request it receives (usually based on the extension). The more traditional definition is of the original (and still used) process where a web server does that by launching a new process to run that program, and passing a handle to the stream (the old stdin/out thing) and other data in environment variables. Again, that's usually based on the query string, and is a common way to generate dynamic, rather than static pages. You'll almost certainly want to do something like that to actaully get the data out of your device and into the server web page. Alternatively some sort of server-side scripting can be embedded in static pages, which can then call out to other code (this is often done with PHP). In any case, the exact details are up to the web server.
A major part will be defining exactly how complex you need things to be. If you need only limited security, and have only a few dynamic pages, then a simple solution will do. If you have hundreds of pages, animations, need SSL, etc., you really need a full function web server.
It sounds like you don't have that much experience on the web side, it would probably be a useful exercise for you to hack up a prototype on whatever development environment you have available. You'll be able to do traditional CGI scripts, server side scripting, and many other things under either Linux or Windows, if you want to play with ASP (in its various flavors), you'll be limited to Windows.
Another possibility, especially if there will be a limited number of instances of this device, is to leave the device fairly dumb, and put the management web server on a "real" machine, and just send commands and queries back to the device. Although it sort of sounds like that=92s what you=92re trying to do =96 hang a full fledged computer, running a real OS, off the side of the existing device. If that=92s the case, and you can actually toss a copy of Linux or Windows on there, do that =96 the development tools available for a =93real=94 web server are so much better.
As for updating the display, there are a variety of methods, but the simplest is to just throw a "refresh" meta tag into the served web page - that will cause the browser to reload the page after the specified interval.
You might have a look at mongoose ... I haven't used it, but LinuxJournal this month did a feature article on it. AFAICT, it is an embedded, threaded web server framework which does the heavy lifting for you, and has a light footprint, and language bindings for C, Python, C#, Ruby and Lua ... should be suitable for embedding ... providing you have an underlying OS ... (perhaps something like an AVR32 - NGW100??)
formatting link
As indicated, I haven't tried it, but it does look interesting ...
My approach was different (and is far from what "most" people are doing). I did all the work on the side of the embedded system, as if it had a monitor, keyboard and mouse - only it did not, it fits into an MPC5200B based SOC and gets accessed via RFB ( VNC ). There are various vnc clients freely available ( realVNC being the best I have tried so far). At 100 MbpS , 16 bits per pixel, one won't know this is a remote system. At 10 MbpS it is noticeable, but still quite usable, one could work with it without swearing. Actually this is valid even much below 10 (not sure how much, did it recently over the net to maintain a customer system, must have been 2-3 MbpS or so). All this at 800 x
600 display size, at 1280 x 800 and 100 MbpS there was no noticeable difference to 800 x 600(just tried it a few times in that format).
formatting link
Not really recommending this approach as it implies having a lot readily available to build on (which I did have); but it is a possibility. I want to make all the DPS and stuff available some time this year so one can just write his application, but I have to write some description of the whole thing for users which will be pretty bulky so I am not even starting it yet :-).
Why not push the complexity into the browser? E.g., write a Java applet so the "remote" end just has to serve up bytes (that the applet can interpret however is appropriate)?
and certainly others will have hardware that is offered with everything from boot only, to romdos, to linux to windows CE or better. So lots of chances for w'ever gui/browser you want.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.