Re: [uCsimm] Breaking the workload.

From: Geoffrey Wossum (gpw0341@omega.uta.edu)
Date: Fri Oct 06 2000 - 17:40:44 EDT


> I had the thought of using decent sized PICs programmed as http parsers
> along with a uCsimm. The simm could listen on port 80, pass the headers
> onto the PIC, and receive the header to send back, and some information on
> what file to send with it, or what CGI program to run (if at all.) I
> assume this would help lots in offloading work from the simm. I was also
> wondering if it were possible to create limited SMTP, POP3, DNS, etc
> servers using $8-12 PICs. You don't have to worry about writing TCP/IP
> stacks or limited file system junk for the PICs like everyone else running
> "the world's smallest webserver" does :)

If you've been on this list long, you might recognize that I want to use a
PIC in every design ;) But I don't think you would benefit from using
PIC's for webserving.

First, you need to pass the data to the PIC. Fastest way to do this is
the PIC's PSP port. But you have to use I/O pins on the uCsimm, which
aren't a particularly fast way of doing it (BTW, I'm looking forward to
the uCdimm with the memory bus brought out to the pins!)

And then the PIC has to process it. The $8-$12 dollar PIC's you mention
have at most 80 contiguous bytes of memory, so processing headers more
than 80 bytes is painful. Plus, with the PIC16 series ultra-purist RISC
instruction set, it's going to take a lot of cycles to "parse" it. The
'ez328, with it's richer instruction set + a good compiler can probably do
the processing faster than the PIC anyway.

So now you've procesed the header. Now you have to interrupt the uCsimm,
wait for the top half interrupt handler to kick in, and then read the data
back from the PSP across the Dragonball's I/O pins.

So now that you've got the data back, guess what? You have to interpret
the data again! So instead of interpretting an HTTP header, you're now
interpretting the data stream coming back from the PIC, which is in your
own special format. And HTTP headers are so simple, the data coming back
from the PIC couldn't be that much easier to interpret.

> What could be the limitations of this? Is the general I/O of the uCsimm
> too slow, or could the simplicity of the amount of data being transferred
> help this process (the simm transferring files, etc)?

Interpretting HTTP headers is so simple that I bet you'd spend more time
sending the data back and forth from the PIC than it would take just to
process it in the uCsimm. Remember, you can't DMA transfer it to the PIC,
so your CPU still has to work to send data off to the PIC.

> It would be neat to be able to create a webserver with good speed and
> functionality for $30-$45 extra. I'm not talking about saturating a
> 10megabit link, but maybe 600k/1mbit :)

I can get a 486 SBC for a $100-$150 that could easily beat a uCsimm for
web serving.

You can do some very cool things with a uCsimm + PIC's, but this isn't one
of them.

---
Geoffrey Wossum
gwossum@acm.org
Project AKO - http://rover1.uta.edu/~ako
Internet Imperialists - http://inetimperial.sourceforge.net
This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/



This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:38 EST