Post by thread:TCP/IP, smallest server, blah blah

Anyone get hold of code for the small dedicated TCP/IP stacks that have been implemented on PIC's? All I really need is HTML <GET> <SET> to make a sprinkler controller controllable, the interface programmable, and to get status updates. -- ________________________________________________________________ Dennis K. Gearon (Kegley) Scientific Instrument Technician, School of EIT Oregon Institute of Technology - One of USA's 100 Best College Buys 3201 Campus Drive Klamath Falls, OR 97601 Voice 1-541-885-1563 FAX 1-541-885-1689 email spam_OUTgearondTakeThisOuToit.edu I am here only to be truly helpful ________________________________________________________________

Dennis, I think you replied to an [OT] thread message, which can cause people to ignore your message despite the new subject line. Many mail readers will have connected your message to the [OT] thread because you used the reply function instead of posting a new message. Specifically, your message has a header including a line References: that has the message identification of the [OT] message. On Tue, Jan 11, 2000 at 04:25:47PM -0800, Dennis Gearon wrote: > Anyone get hold of code for the small dedicated TCP/IP stacks that have > been implemented on PIC's? All I really need is HTML <GET> <SET> to > make a sprinkler controller controllable, the interface programmable, > and to get status updates. Just like to point out that it is GET and POST. Also that you do not need to use POST, but can implement any functionality with GET as well. I too am interested to know if anybody has crammed TCP/IP over PPP or SLIP into something as small as a 16F84. Example code wanted. -- James Cameron .....quozlKILLspam@spam@us.netrek.org http://quozl.us.netrek.org/

www.embeddedethernet.com/EmbEthPICSample.html At 12:26 PM 1/12/00 +1100, you wrote: >I too am interested to know if anybody has crammed TCP/IP over PPP or >SLIP into something as small as a 16F84. Example code wanted. > >-- >James Cameron quozlKILLspamus.netrek.org http://quozl.us.netrek.org/ >

> I too am interested to know if anybody has crammed TCP/IP over PPP or > SLIP into something as small as a 16F84. Example code wanted. Personally I think it's too large a target. I plan to get a couple of my students working on UDP/SLIP. I think it's doable in a small PIC because UDP has none of TCP's overhead for flow control and sequencing. What I'm really interested in is figuring out a system where multiple RS-485 connected PIC hosts can use a single line to transmit UDP/SLIP packets into a gateway. BAJ

Seen it. Not useful. (a) uses Ethernet rather than PPP or SLIP, (b) uses UDP rather than TCP. I've already implemented UDP in Forth on an 8085 over SLIP. That's trivial by comparison to TCP. On Tue, Jan 11, 2000 at 06:43:35PM -0700, JB wrote: > www.embeddedethernet.com/EmbEthPICSample.html > At 12:26 PM 1/12/00 +1100, you wrote: > >I too am interested to know if anybody has crammed TCP/IP over PPP or > >SLIP into something as small as a 16F84. Example code wanted. -- James Cameron .....quozlKILLspam.....us.netrek.org http://quozl.us.netrek.org/

> > There's some info here, although no code. > http://www-ccs.cs.umass.edu/~shri/iPic.html > This one uses PIC 12c508, if i remember. It has to be a hoax. There's simply not enough space or speed to implement a full TCP stack plus a web server in the 12C509 @ 115.2kbs. There's no code and no independant duplication of the project. It's a hoax. My opinion is that small uC need not be full blown TCP servers anyway. The real objective is to use a protocol stack that is well defined and well debugged on the server end so that A) you don't have to write/debug the server side of the stack B) you can use easily written applications on the server side and C) so that you can actually route information over an intranet/internet. UDP serves this task beautifully. You can test simply by pinging the node. tcpdump is the perfect tool for observing traffic. Apps simply open a UDP port and start send/recv to communicate. With RS485 the cost is little more than an 8 pin transceiver and two I/O pins. I don't feel I need the world's smallest web server. What I really want to have is the world's smallest internet accessible switch/datalogger/etc. BAJ

incidently, the link is from Microchip website. check: http://www.microchip.com/internet/index.htm If it is a hoax, too bad. BTW,Is it really impossible on a '509?? :-) anupam {Quote hidden}> > > > > There's some info here, although no code. > > http://www-ccs.cs.umass.edu/~shri/iPic.html > > This one uses PIC 12c508, if i remember. > > It has to be a hoax. There's simply not enough space or speed to implement > a full TCP stack plus a web server in the 12C509 @ 115.2kbs. > There's no code > and no independant duplication of the project. It's a hoax. > > My opinion is that small uC need not be full blown TCP servers > anyway. The real > objective is to use a protocol stack that is well defined and > well debugged > on the server end so that A) you don't have to write/debug the server side > of the stack B) you can use easily written applications on the server side > and C) so that you can actually route information over an > intranet/internet. > > UDP serves this task beautifully. You can test simply by pinging the node. > tcpdump is the perfect tool for observing traffic. Apps simply open a UDP > port and start send/recv to communicate. With RS485 the cost is > little more > than an 8 pin transceiver and two I/O pins. > > I don't feel I need the world's smallest web server. What I really want to > have is the world's smallest internet accessible switch/datalogger/etc. > > BAJ >

There's some info here, although no code. http://www-ccs.cs.umass.edu/~shri/iPic.html This one uses PIC 12c508, if i remember. Last time this came up, it was widely accused of being a fraud. The current offline status of the demo might support that theory... We did have some local discussions about whether there was a way to cheat that would be undetectable in normal operation ie "it's not a real tcp web server, it just looks and acts like a real tcp web server." I can't say much more till cisco decides whether they want to try for a patent along those lines. (I'm pushing for a "publish" scenario, which is more work for me (and less for lawyers.) It could allow nearly any micro to provide some degree of web service with very little code.) BillW

If you haven't read about the Seiko chip, take a look at http://www.mycal.net/wsweb/ The chip appears on the outside to behave like a nice UART, in fact it is used as a pass-through UART during dialing etc. Then a bit is flipped in a register and the chip establishes a PPP link. I believe the pricing is in the $8 range. -Jim

www.chat.ru/~zhengxi/wwwpic/source.htm 16F84 implementing TCP/IP, HTTP, CGI (?) with source! and others at: http://204.210.50.240/techref/default.asp?url=tcpip.htm which is back up the morning after the cleaning people kicked the power cord out last night... Arrrrghhhh! James Newton EraseMEjamesnewtonspam_OUTTakeThisOuTgeocities.com phone:1-619-652-0593 http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS! Members can add private/public comments/pages ($0 TANSTAAFL web hosting) {Original Message removed}

Byron A Jeff wrote: > > > I too am interested to know if anybody has crammed TCP/IP over PPP or > > SLIP into something as small as a 16F84. Example code wanted. > > Personally I think it's too large a target. I plan to get a couple of my > students working on UDP/SLIP. I think it's doable in a small PIC because > UDP has none of TCP's overhead for flow control and sequencing. Sequencing is ameliorated by making sure each page, file, etc fits into one TCP packet (I believe max 1024 bytes) which is still substantial. Flow control is not too difficult if using PPP or SLIP, as the serial connection has hardware flow control. Let the PPP or SLIP server do the buffering for you... -Adam

James, I keep getting "FILE NOT AVAILABLE" errors whenever I try to access this site.... http://www.chat.ru/~zhengxi/wwwpic/source.htm 16F84 Are you sure it's still active? Regards, Jim On Wed, 12 January 2000, James Newton wrote: {Quote hidden}> > http://www.chat.ru/~zhengxi/wwwpic/source.htm 16F84 implementing TCP/IP, > HTTP, CGI (?) with source! > > and others at: > http://204.210.50.240/techref/default.asp?url=tcpip.htm > > which is back up the morning after the cleaning people kicked the power cord > out last night... Arrrrghhhh! > > James Newton jamesnewtonspam_OUTgeocities.com phone:1-619-652-0593 > http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS! > Members can add private/public comments/pages ($0 TANSTAAFL web hosting) > > > {Original Message removed}

Yup, I'm a looken at the page! I didn't put the 16F84 on the end though. The URL stops with source.htm. James Newton @spam@jamesnewtonKILLspamgeocities.com phone:1-619-652-0593 http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS! Members can add private/public comments/pages ($0 TANSTAAFL web hosting) {Original Message removed}

The best guess takes place when one notices that the files on the server are all at different ports. (http://128.119.41.46:4176/index0.html - replace "index0.html" with any text, same 'file') If you make ANY request on a different port, you will get different portions of the eeprom memory, until the end of file character the eeprom probably has. It does seem to be non communicative now, but that was it's behavior when it first came out. -Adam William Chops Westfield wrote: > > There's some info here, although no code. > http://www-ccs.cs.umass.edu/~shri/iPic.html > This one uses PIC 12c508, if i remember. > > Last time this came up, it was widely accused of being a fraud. The current > offline status of the demo might support that theory...

Actually, what I said before isn't totally accurate. I can get to the page listed, but when I try to look at the files listed there, thats when I get the errors. Thanks and Regards, Jim On Wed, 12 January 2000, "James Newton" wrote: > > Yup, I'm a looken at the page! I didn't put the 16F84 on the end though. The > URL stops with source.htm. > > James Newton KILLspamjamesnewtonKILLspamgeocities.com phone:1-619-652-0593 > http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS! > Members can add private/public comments/pages ($0 TANSTAAFL web hosting) > > {Original Message removed}

Well, the site is slow as heck, probably because its getting /.'d right now buy the PICList members <GRIN> but the .zip file link works and has all the other files, masmpic.htm works, pic2.htm works... What exact link isn't working and, not that I mind helping, but wouldn't it be better to ask the guy who's site this is if you find a broken link on his site? I'm going to email him and ask if he wants a mirror site. James Newton RemoveMEjamesnewtonTakeThisOuTgeocities.com phone:1-619-652-0593 http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS! Members can add private/public comments/pages ($0 TANSTAAFL web hosting) {Original Message removed}

Jim, I just got the download. You might just want to keep trying and be a bit patient (it is slow). Dan {Quote hidden}> James, > > I keep getting "FILE NOT AVAILABLE" errors whenever I try to > access this site.... > http://www.chat.ru/~zhengxi/wwwpic/source.htm 16F84 > > Are you sure it's still active? > > Regards, > > Jim > > > On Wed, 12 January 2000, James Newton wrote: > > > > > http://www.chat.ru/~zhengxi/wwwpic/source.htm 16F84 implementing TCP/IP, > > HTTP, CGI (?) with source! > > > > and others at: > > 204.210.50.240/techref/default.asp?url=tcpip.htm > > > > which is back up the morning after the cleaning people kicked the power cord > > out last night... Arrrrghhhh! > > > > James Newton spamBeGonejamesnewtonspamBeGonegeocities.com phone:1-619-652-0593 > > http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS! > > Members can add private/public comments/pages ($0 TANSTAAFL web hosting) > > > > > > {Original Message removed}

I've asked the site owner for permission to do so, if he responds with a yes, I will. James Newton TakeThisOuTjamesnewtonEraseMEspam_OUTgeocities.com phone:1-619-652-0593 http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS! Members can add private/public comments/pages ($0 TANSTAAFL web hosting) -----Original Message----- From: Severson, Rob [RemoveMEseversonTakeThisOuTjged.com] Sent: Wednesday, January 12, 2000 08:19 To: 'jamesnewtonEraseME.....efplus.com'; EraseMEPICLISTMITVMA.MIT.EDU Subject: RE: TCP/IP, smallest server, blah blah James, Can you post or email the wwwpic.zip file? When I download the file it is corrupt. Thanks

part 0 701 bytes > James, > > Can you post or email the wwwpic.zip file? When I download the file it is > corrupt. > > Thanks > I've attached the zip file. I don't know if the list truncates attachments. -- ________________________________________________________________ Dennis K. Gearon (Kegley) Scientific Instrument Technician, School of EIT Oregon Institute of Technology - One of USA's 100 Best College Buys 3201 Campus Drive Klamath Falls, OR 97601 Voice 1-541-885-1563 FAX 1-541-885-1689 email RemoveMEgearondEraseMEEraseMEoit.edu I am here only to be truly helpful ________________________________________________________________ Attachment converted: wonderland:wwwpic.zip (pZIP/pZIP) (000149D5)

> > Byron A Jeff wrote: > > > > > I too am interested to know if anybody has crammed TCP/IP over PPP or > > > SLIP into something as small as a 16F84. Example code wanted. > > > > Personally I think it's too large a target. I plan to get a couple of my > > students working on UDP/SLIP. I think it's doable in a small PIC because > > UDP has none of TCP's overhead for flow control and sequencing. > > Sequencing is ameliorated by making sure each page, file, etc fits into > one TCP packet (I believe max 1024 bytes) which is still substantial. TCP packets can be up to 65536 bytes. > > Flow control is not too difficult if using PPP or SLIP, as the serial > connection has hardware flow control. Let the PPP or SLIP server do the > buffering for you... Not UART flow control, TCP flowcontrol. BAJ

On Wed, Jan 12, 2000 at 05:34:11PM -0500, Byron A Jeff wrote: > TCP packets can be up to 65536 bytes. TCP segments, that is. ;-) > Not UART flow control, TCP flowcontrol. TCP flow control can be just ignored. Packets get repeated. Not nice, but it is better than not communicating. I think the RFC allows for this for embedded devices. -- James Cameron RemoveMEquozlspam_OUTKILLspamus.netrek.org http://quozl.us.netrek.org/

Attachment decoded fine. Fascinating code. Strange character set. I might try getting it working. Byron, for your interest the mail address of the ipic's author is listed in the PIC2.ASM file as the source of the idea. -- James Cameron RemoveMEquozlTakeThisOuTspamus.netrek.org http://quozl.us.netrek.org/

> Sequencing is ameliorated by making sure each page, file, etc fits into > one TCP packet (I believe max 1024 bytes) which is still substantial. TCP packets can be up to 65536 bytes. Irrelevant, since "we" are sending the data. Realistically, each packet should be "not larger" than an ethernet packet (and *officially* not larger than an IMP packet (576 bytes.)) The receiving side of a TCP connection gets to specify the maximum packet size that it is willing to accept. Expecting it to allow very large packets will lead to an implementation that will not work very often... BillW

I think the subject chip merely has to 'SLIP' (!) the info packet to the local INET host who can (will?) fragment it to suit a broader distr. So it is likely that _all_ messages in this <implementation> are single packets. Simplifies TCP a bit<!> What the size lim on SLIP? R.Martin William Chops Westfield wrote: {Quote hidden}> > Sequencing is ameliorated by making sure each page, file, etc fits into > > one TCP packet (I believe max 1024 bytes) which is still substantial. > > TCP packets can be up to 65536 bytes. > > Irrelevant, since "we" are sending the data. Realistically, each packet > should be "not larger" than an ethernet packet (and *officially* not larger > than an IMP packet (576 bytes.)) > > The receiving side of a TCP connection gets to specify the maximum packet > size that it is willing to accept. Expecting it to allow very large packets > will lead to an implementation that will not work very often... > > BillW

I think the subject chip merely has to 'SLIP' (!) the info packet to the local INET host who can (will?) fragment it to suit a broader distr. So it is likely that _all_ messages in this <implementation> are single packets. Simplifies TCP a bit<!> No. The inet host can fragment a large IP *packet* into smaller fragments, but it can't fragment a TCP *segment*. If there was a single large TCP segment fragmented into tiny IP packets, it would get reassembled on the destination host BEFORE TCP got to look at it, and then TCP would claim that it's too big. What the size limit on SLIP? Originally, 1006. Practically, 1500 or so (ie same size as an ethernet packet.) Fundamentally, 64k... I would expect that there's quite a lot one could do within the confines of 536 bytes of payload. In the absense of huge graphics and fancy HTML, that's quite a bit of data for a small microcontroller to have to send in the first place, right? I think some sort of "eternal filesystem" to hold the "pure data" part of the conversation is fundamental to TCP on very small microcontrollers. A serial eeprom/flash device would work fine. BillW

I've taken the liberty of removing the other (crazy projects, biographical info, etc...) links and adding a reference to Denis Petrov and his home page. You will find it at http://www.piclist.com/petrovwwwpic/index.htm and listed under http://www.piclist.com/projects.htm http://204.210.50.240/techref/default.asp?url=inet/embedded.htm Please email me if you have questions, comments, requests or updates. Thank you! James Newton EraseMEjamesnewtonspamspamBeGonegeocities.com phone:1-619-652-0593 http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS! Members can add private/public comments/pages ($0 TANSTAAFL web hosting) {Original Message removed}