Slashdot Mirror
DIY Tiny Webserver
kyllikki writes "Oh no no another one? Yes but this time the idea is that its simple enough for those with just a small amount of electronics experience to actualy build it! Everything you need except the physical components and a PIC programmer (theres a link to a 11 component one) is on the website. There is source code , binary hex file (for those to lazy to assemble their own) , hardware design and layout even a parts list and costings... Go have a look and build your own!" No pretty pictures, but a lucid explanation of how you can (cheaply) build a tiny spitter-up-of-html, driven by their GPL'd software.
Its actually pretty common right now. I work in the Fibre Channel industry, and most new Fibre switches have a built in web server, which actually serves up Java applets to manage the switch. Pretty soon we'll be seeing toaster and coffee machines doing the same thing...
---- I made the Kessel Run in under 11 parsecs.
Microcontrolers are the best things on earth. Unfortunally, serial ports are not. With the speed of a serial port the power of the darn thing is quite limited. I would try something else out. How about using the cheep I2C chips out there and monitor the temp of the entire house? Maybe it can track the pressures on the carpet to report where there is the most traffic. The processor can then send the data to the computer or other device it is attached to then put it on the net via DSL or T1 or something. It would be more efficient.
A web server is 'way cheaper than switches and blinky lights, and doesn't wear out.
Of course putting in a Pic just to be a web server isn't ideal. But it serves as a proof-of-concept: If you can embed a web server in a Pic, you can embed it in whatever tiny micro you are using to control the device. It just costs you a little more ROM space, a sliver of RAM, and a connector for whaetever you're using for a line.
It will be better yet when embedded micros come with Homenet (or the like) support. Talk to your home computer over the power line at the cost of a couple capacitors on the board and the use of a couple otherwise unused pins, or something to that effect.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I agree :) However the Java involved is client-side only, for interfacing with the switch.
---- I made the Kessel Run in under 11 parsecs.
I've seen a number of comments above where the poster has lept to the conclusion that this thing is comparable to a "real" web server, such as apache running on a unix platform.
The most important limitation that I can see in the code is that it only remembers information from the previously received packet, and it can only send a packet in response to receiving one, but can't retransmit on a timeout not having received an ACK. Calling this TCP is a streatch at best. It's certainly a long way from RFC-1122.
For example, consider the case where two clients attempt to access this little web server at the same time, which is not unlikely running the data pipe at 19200 baud, and having CTS inhibiting data flow in between every received byte, and during all data transmission. The remote IP address is overwritten as the second packet is received, causing all knowledge of the first connection to be lost. Most of that information will be regained when the first host sends another packet, but the point is that this little web server isn't going to work well with multiple connections at the same time, and probably won't work at all if the TCP retransmit is require because of any packet loss.
It is a neat project, and doing even this minimal tx follows rx without pre-connection state is some impressive code for such a small chip. Neat as it is, it just isn't a viable web server for any application where multiple clients may use it. It probably won't do well on networks that have packet loss, duplicated packet and the other not-so-common problems that come with the best-effort (but unreliable) IP datagram service.
And now for a shameless plug.... for the posters above who were talking about connecting a disk drive, here's a little project I did that connects a IDE hard drive to a 8051 microcontroller. Maybe it could be used with a PIC? My code is public domain, so it could be combined with a GPL'd project, like this little web server.
PJRC: Electronic Projects, 8051 Microcontroller Tools
If you want a flexible, tiny webserver that can communicate over ethernet, serial, and can attach stuff using the wonderful 1-wire technology, a TINI is what you need.
This is what I am doing with my TINI, for those who think such a thing is not useful.
Forget about PICs, they may be useful for charging your phone (there is one in my phone's charging base) but they don't run Java, and they don't talk ethernet.
If you're interested in the PIC microcontrolers (specifically the 16C/F84) then visit my web site, the PIC archive. It hasnt been updated very recently but contains a lot of usefull stuff. Try it: http://come.to/thepicarchive.
--
Traditionally, you are right on. However, Linux will never win in the traditional marketplace. The expensive suit, bland, conformist, non threatening world will never accept anything that isn't backed by tons of money and meaningless marketing babble. The only way Linux will ever become more successful is the same way it got as far as it currently has; by changing the rules instead of playing by them. No longer is it true that a company who throws the most money at a project wins. Anything a company can create, we can eventually replicate, and make it better, more secure, and more stable.
Times are changing, and that muct scare the living crap out of marketers.
Finkployd
There's that swedish comppany (name I have skipped on) with a video camera that connects via built in RJ-11 or RJ-45 jacks (by modem or ethernet, that is) and contains its own web server, and some digicams have a little built in Web server as well, I believe.
...
It'd be cool to skip all the hassle of connecting a digital camera to yer avg Linux box (gPhoto is excellent but sometimes crashy and until vendors wise up is always playing catch up with new models of camera) by plugging in an ethernet or USB cable and being able to instantly download a page of thumbnails
My refrigerator should have one of these, too, and (especially) the diagnostic computer in my car.
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Here is the link to the cameras w/ a builtin webserver.
They seem to have a lot of nifty stuff there.
No, i'm not in any way associated with them.
Lev
I wonder if technology like this will open the door to web server adapters. Like a PCI card that looks like an ethernet card but is really a full featured web server. This sort of thing would be pretty cool. We offload 3d processing to the video card and SCSI handling to the disk controller so why not have a dedicated piece of hardware for a web server? Hmm, just a thought.
If you can embed a web server into it, you can embed a napster client into it. All you have to do is program the PIC chip for the napster protocol, hook up a network connection, and pop in one of those multi-gigabyte matchbook drives from IBM. Hook the whole thing up to your stero, and voila! Napster-in-a-box!
Of course, you would have to have some way of getting input from the user... a two-line display should handle that well.
Friends don't let friends misuse the subjunctive.
It's a novel concept, but I'm not sure about the applicability. If you are trying to create a micro web server, then you need to connect it to the rest of the world. Unless you want to lumber around with cables and large footprint isolation devices and so on, what you really want is wireless - wires are passe! The goal should be a supercompact, yet flexible and open, server based on an emerging ubiquitous wireless technology.
Your choice should be a Bluetooth ASIC with onboard CPU (e.g. Cambridge Silicon Radio and BlueCore[tm]). You could put the server onto the ASIC, and have a small footprint wireless device. What you also want is a generic interface out of the chip to external devices - so the chip holds the pages, their definitions, and everything else, but local fetches pull binary data from outside of the chip - or something like that.
I want to walk around a museum, and walk up to a painting by Carravagio, and have by palm device show up small icon - I select the device and can browse the image and text about the image, and listen to audio all while I'm standing in the gallery. But then later that night, while having dinner and talking about the day, I want to be able to surf over my 3G phone pull up the information again, while I'm explaning it to some one else. And if that work of art is taken to another gallery, then they can transport the micro webhost with it. That would be cool.
Disclaimer: I work for the parent company of Cambridge Silicon Radio.
-- Matthew - matthew.gream@pobox.com, http://matthewgream.net
http://world.std.com/~fwhite/ace/ http://www.csonline.net/bpaddock/tinytcp/default.h tm http://wearables.stanford.edu/ past postings on slashdot .. http://slashdot.org/articles/00/05/30/0314255.shtm l http://slashdot.org/articles/99/07/31/1654210.shtm l http://slashdot.org/articles/99/08/11/1820258.shtm l we'll never get enough tiny match box web servers.. they just keep getting smaller and smaller..
This sort of electronics is ideal for embeded web servers in hardware like printers, routers, and even household devices like dishwashers and refridgerators. They are mainly used to present status and alow for minimal device configuration. I like the idea, and do not know why these aren't used more in computer hardware. Heck, I would prefer http'ing to my printer or router to configure them rather than having to change dip switches or attach an async terminal. Heck, why not present status of the internals of servers via this route? The PIC controller could query status, and present it back to the user easily. Get the processor temperatures, the status of the fans, and even generate a hard reset remotely if necessary. Just a thought!