TCP/IP for uControllers
Mart Hugh Rogers
microcontroller. I would guess that the assembler source at least would
be in 10's of KB which I guess would preclude relying on onboard
resources. It strikes me that the internet would be an ideal channel
for transmission of telemetry data from embedded systems.
Anyone had any thoughts along these lines or am I even more barking mad
than I thought (woof).
mart
--
Mart Hugh Rogers
Joseph A. Legris
http://www-ccs.cs.umass.edu/~shri/iPic.html
J.Legris
change the x to s to reply
Tom Trumma
/T
Richard A. Daniel
manufactures a line of Ethernet based data acquisition systems which
can transmit telemetry data over the internet using TCP/IP. They use
a commercially available TCP/IP stack which is on-board.
Rick Daniel
PeteD
colleague had to add internet capability to a project and found a board that
has a serial port at one end and an ethernet port at the other. It's
completely transparent to his project (except for internet latency) and thus
required no development time. Circuit Cellar Ink magazine (8/99 issue) had
an article about a $25 web server that implemented a subset of TCP/IP. See
www.circuitcellar.com/online/index.htm . Also the magazines web site
www.circellar.com has a link to the 1998 Embedded Internet Workshop
Proceedings.
Roberto Waltman
> Does anyone know of any succesful ports of TCP/IP/PPP to a
> microcontroller. I would guess that the assembler source at least would
> be in 10's of KB which I guess would preclude relying on onboard
> resources. It strikes me that the internet would be an ideal channel
> for transmission of telemetry data from embedded systems.
Take a look at the just announced Seiko S7600A:
http://www.seiko-usa-ecd.com/intcir/html/whatsnew/
From the "what's new" page:
"The iChip S7600A TCP/IP Protocol Stack ...... allows
TCP/IP stack to be added to consumer or commercial devices
easily and inexpensively. The iChip permits users to connect
to the Internet, or any network that uses the TCP/IP
protocol, using their PDAs, organizers, cell phones or even
pagers as well as many other non-portable electronic
devices. Adding Internet functionality to these types of
devices is now as simple as selecting any other pre-defined
component, such as a resistor or controller. The iChip
S7600A is fast, and it consumes very little power. It runs
at a typical speed of 256 kHz and consumes less than 3 mW in
typical operation."
Roberto Waltman
Ken Tindell
Tom Trumma wrote in message <37D543...@NOSPAMlysator.liu.se>...
The IP address of the PIC is supposed to be 128.119.41.46.
That's actually the IP address of a Unix box at the CS
department at UMass, despite the above Web site saying:
"The iPic web-server is connected directly to a router
running SLIP at 115200bps. There is no intermediary host,
no protocol converter"
Sounds like a hoax to me.
K.
Herman
small processor is to reduce the features. Select a subset of features
that do what you need and ignore everything else. I'm doing these
things for a living - interface small DSPs to complex networks.
Quentin David Jones
of hype about this iPic
Webserver but no supporting
details - hoax I'd say.
Q.
Stephen Pelc
>Does anyone know of any succesful ports of TCP/IP/PPP to a
>microcontroller. I would guess that the assembler source at least would
>be in 10's of KB which I guess would preclude relying on onboard
>resources.
on-chip RAM and restricted to 16 bit addressing.
Our PowerNet stack can be coerced into controllers, but not as it stands.
The problem is one of generality. If you take *all* the features and compile
it for general purpose use, then you will get a big stack.
If, however, you are focused on a specific application, and strip away
*everything* that isn't needed, then you can have reasonbly small code
that could fit into a controller.
--
Stephen Pelc, s...@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 1703 631441, fax: +44 1703 339691
web: http://www.mpeltd.demon.co.uk
Tim Tsai
>No it's most probably not a hoax. The way to implement a protocol on a
>small processor is to reduce the features. Select a subset of features
>that do what you need and ignore everything else. I'm doing these
>things for a living - interface small DSPs to complex networks.
I think most on this list understands that - the spec. just sounds pretty
darn amazing.
bit banging 115k on a 4Mhz PIC is interesting enough by itself (and the
website claims that it is fully buffered). Throw in TCP/UDP/ICMP/SLIP,
a file system, a telnet server, and a webserver just sounds a bit far
fetch. Oh, let's not forget an RTOS in 3-15 instructions. I will reserve
judgement until somebody actually can verify this but again, it'd be some
pretty tight coding even if you assume the absolute minimalist approach.
I believe the closest one I've seen was a PIC contest winner from Circuit
Cellar Ink a few years ago and the author did implement PPP/UDP/ICMP (which
is more than enough if you ask me in this environment).
BTW, it is 256 12-bit words so it's a bit more than 256 bytes.
Tim
Jan Panteltje
> bit banging 115k on a 4Mhz PIC is interesting enough by itself (and the
>website claims that it is fully buffered). Throw in TCP/UDP/ICMP/SLIP,
>a file system, a telnet server, and a webserver just sounds a bit far
>fetch. Oh, let's not forget an RTOS in 3-15 instructions. I will reserve
>judgement until somebody actually can verify this but again, it'd be some
>pretty tight coding even if you assume the absolute minimalist approach.
>
> I believe the closest one I've seen was a PIC contest winner from Circuit
>Cellar Ink a few years ago and the author did implement PPP/UDP/ICMP (which
>is more than enough if you ask me in this environment).
>
> BTW, it is 256 12-bit words so it's a bit more than 256 bytes.
>
> Tim
>
I think he did it this way:
Take byte TCP/IP packet - what is it? discard if not of interest
(keep a counter)
Take second byte .... etc.
And so on..
Is it my ip? if not discard packet..
Is it port 80? Yes then it is for the http, branch same procedure http 'server'
Is it port for telnet ? yes then ...
other services here...
else discard packet.
mmm, efficient and why not.
J
Tim Tsai
>Is it port 80? Yes then it is for the http, branch same procedure http 'server'
>Is it port for telnet ? yes then ...
>other services here...
>else discard packet.
>mmm, efficient and why not.
Let's not forget timeouts, retransmissions, packet reassembly, etc.
and I am hardly a TCP/IP internals guru! TCP/IP is not a byte/word encoded
state machine and is a bit more complicated than what you have outlined.
Tim
Jan Panteltje
>and I am hardly a TCP/IP internals guru!
I wrote a complete CP/M (BTW operating system) in less then 8k,
using 256 variables, and yes, I took the liberty of allocating 2 512 bytes
buffers for the floppy I/O.
Al that on a Z80.
That included the command processor, bios, and basic disk operating system,
floppy driver, video driver, etc.
Now those 256 variables had 256 * 8 bits for flags :)
That simple TCP/IP packet would fit in anywhere in what I would have freed
up after a first code optimizing session, but alas, give or take a byte or 2
there would still be spare space in the PIC.
But I would prefer a z80.
As far as the state machine goes, here are the first lines from
/usr/src/linux/net/ipv4/tcp.c (part of the linux kernel)
/*
* INET An implementation of the TCP/IP protocol suite for the LINUX
* operating system. INET is implemented using the BSD Socket
* interface as the means of communication with the user level.
*
* Implementation of the Transmission Control Protocol(TCP).
*
* Version: @(#)tcp.c 1.0.16 05/25/93
*
* Authors: Ross Biro, <bi...@leland.Stanford.Edu>
* Fred N. van Kempen, <wal...@uWalt.NL.Mugnet.ORG>
* Mark Evans, <eva...@uhura.aston.ac.uk>
* Corey Minyard <wf-rch!min...@relay.EU.net>
* Florian La Roche, <fl...@stud.uni-sb.de>
* Charles Hedrick, <hed...@klinzhai.rutgers.edu>
* Linus Torvalds, <torv...@cs.helsinki.fi>
* Alan Cox, <gw4...@gw4pts.ampr.org>
* Matthew Dillon, <dil...@apollo.west.oic.com>
* Arnt Gulbrandsen, <agu...@nvg.unit.no>
* Jorge Cwik, <jo...@laser.satlink.net>
*
* Fixes:
* Alan Cox : Numerous verify_area() calls
* Alan Cox : Set the ACK bit on a reset
* Alan Cox : Stopped it crashing if it closed while
* sk->inuse=1 and was trying to connect
* (tcp_err()).
* Alan Cox : All icmp error handling was broken
* pointers passed where wrong and the
* socket was looked up backwards. Nobody
* tested any icmp error code obviously.
* Alan Cox : tcp_err() now handled properly. It
* wakes people on errors. select
* behaves and the icmp error race
* has gone by moving it into sock.c
* Alan Cox : tcp_send_reset() fixed to work for
* everything not just packets for
* unknown sockets.
* Alan Cox : tcp option processing.
* Alan Cox : Reset tweaked (still not 100%) [Had
* syn rule wrong]
* Herp Rosmanith : More reset fixes
* Alan Cox : No longer acks invalid rst frames.
* Acking any kind of RST is right out.
* Alan Cox : Sets an ignore me flag on an rst
* receive otherwise odd bits of prattle
* escape still
* Alan Cox : Fixed another acking RST frame bug.
* Should stop LAN workplace lockups.
* Alan Cox : Some tidyups using the new skb list
* facilities
* Alan Cox : sk->keepopen now seems to work
* Alan Cox : Pulls options out correctly on accepts
* Alan Cox : Fixed assorted sk->rqueue->next errors
* Alan Cox : PSH doesn't end a TCP read. Switched a
* bit to skb ops.
* Alan Cox : Tidied tcp_data to avoid a potential
* nasty.
* Alan Cox : Added some better commenting, as the
* tcp is hard to follow
* Alan Cox : Removed incorrect check for 20 * psh
* Michael O'Reilly : ack < copied bug fix.
* Johannes Stille : Misc tcp fixes (not all in yet).
* Alan Cox : FIN with no memory -> CRASH
* Alan Cox : Added socket option proto entries.
* Also added awareness of them to accept.
* Alan Cox : Added TCP options (SOL_TCP)
* Alan Cox : Switched wakeup calls to callbacks,
* so the kernel can layer network
* sockets.
* Alan Cox : Use ip_tos/ip_ttl settings.
* Alan Cox : Handle FIN (more) properly (we hope).
* Alan Cox : RST frames sent on unsynchronised
* state ack error.
* Alan Cox : Put in missing check for SYN bit.
* Alan Cox : Added tcp_select_window() aka NET2E
* window non shrink trick.
* Alan Cox : Added a couple of small NET2E timer
* fixes
* Charles Hedrick : TCP fixes
* Toomas Tamm : TCP window fixes
* Alan Cox : Small URG fix to rlogin ^C ack fight
* Charles Hedrick : Rewrote most of it to actually work
* Linus : Rewrote tcp_read() and URG handling
* completely
* Gerhard Koerting: Fixed some missing timer handling
* Matthew Dillon : Reworked TCP machine states as per RFC
* Gerhard Koerting: PC/TCP workarounds
* Adam Caldwell : Assorted timer/timing errors
* Matthew Dillon : Fixed another RST bug
* Alan Cox : Move to kernel side addressing changes.
* Alan Cox : Beginning work on TCP fastpathing
* (not yet usable)
* Arnt Gulbrandsen: Turbocharged tcp_check() routine.
* Alan Cox : TCP fast path debugging
* Alan Cox : Window clamping
* Michael Riepe : Bug in tcp_check()
* Matt Dillon : More TCP improvements and RST bug fixes
* Matt Dillon : Yet more small nasties remove from the
* TCP code (Be very nice to this man if
* tcp finally works 100%) 8)
* Alan Cox : BSD accept semantics.
* Alan Cox : Reset on closedown bug.
* Peter De Schrijver : ENOTCONN check missing in tcp_sendto().
* Michael Pall : Handle select() after URG properly in
* all cases.
* Michael Pall : Undo the last fix in tcp_read_urg()
* (multi URG PUSH broke rlogin).
* Michael Pall : Fix the multi URG PUSH problem in
* tcp_readable(), select() after URG
* works now.
* Michael Pall : recv(...,MSG_OOB) never blocks in the
* BSD api.
* Alan Cox : Changed the semantics of sk->socket to
* fix a race and a signal problem with
* accept() and async I/O.
* Alan Cox : Relaxed the rules on tcp_sendto().
* Yury Shevchuk : Really fixed accept() blocking problem.
* Craig I. Hagan : Allow for BSD compatible TIME_WAIT for
* clients/servers which listen in on
* fixed ports.
* Alan Cox : Cleaned the above up and shrank it to
* a sensible code size.
* Alan Cox : Self connect lockup fix.
* Alan Cox : No connect to multicast.
* Ross Biro : Close unaccepted children on master
* socket close.
* Alan Cox : Reset tracing code.
* Alan Cox : Spurious resets on shutdown.
* Alan Cox : Giant 15 minute/60 second timer error
* Alan Cox : Small whoops in selecting before an
* accept.
* Alan Cox : Kept the state trace facility since
* it's handy for debugging.
* Alan Cox : More reset handler fixes.
* Alan Cox : Started rewriting the code based on
* the RFC's for other useful protocol
* references see: Comer, KA9Q NOS, and
* for a reference on the difference
* between specifications and how BSD
* works see the 4.4lite source.
* A.N.Kuznetsov : Don't time wait on completion of tidy
* close.
* Linus Torvalds : Fin/Shutdown & copied_seq changes.
* Linus Torvalds : Fixed BSD port reuse to work first syn
* Alan Cox : Reimplemented timers as per the RFC
* and using multiple timers for sanity.
* Alan Cox : Small bug fixes, and a lot of new
* comments.
* Alan Cox : Fixed dual reader crash by locking
* the buffers (much like datagram.c)
* Alan Cox : Fixed stuck sockets in probe. A probe
* now gets fed up of retrying without
* (even a no space) answer.
* Alan Cox : Extracted closing code better
* Alan Cox : Fixed the closing state machine to
* resemble the RFC.
* Alan Cox : More 'per spec' fixes.
* Jorge Cwik : Even faster checksumming.
* Alan Cox : tcp_data() doesn't ack illegal PSH
* only frames. At least one pc tcp stack
* generates them.
* Alan Cox : Cache last socket.
* Alan Cox : Per route irtt.
* Matt Day : Select() match BSD precisely on error
* Alan Cox : New buffers
* Marc Tamsky : Various sk->prot->retransmits and
* sk->retransmits misupdating fixed.
* Fixed tcp_write_timeout: stuck close,
* and TCP syn retries gets used now.
* Mark Yarvis : In tcp_read_wakeup(), don't send an
* ack if stat is TCP_CLOSED.
* Alan Cox : Look up device on a retransmit - routes may
* change. Doesn't yet cope with MSS shrink right
* but it's a start!
* Marc Tamsky : Closing in closing fixes.
* Mike Shaver : RFC1122 verifications.
* Alan Cox : rcv_saddr errors.
* Alan Cox : Block double connect().
* Alan Cox : Small hooks for enSKIP.
* Alexey Kuznetsov: Path MTU discovery.
* Alan Cox : Support soft errors.
* Alan Cox : Fix MTU discovery pathological case
* when the remote claims no mtu!
* Marc Tamsky : TCP_CLOSE fix.
* Colin (G3TNE) : Send a reset on syn ack replies in
* window but wrong (fixes NT lpd problems)
* Pedro Roque : Better TCP window handling, delayed ack.
* Joerg Reuter : No modification of locked buffers in
* tcp_do_retransmit()
* Eric Schenk : Changed receiver side silly window
* avoidance algorithm to BSD style
* algorithm. This doubles throughput
* against machines running Solaris,
* and seems to result in general
* improvement.
* Eric Schenk : Changed receiver side silly window
* avoidance algorithm to BSD style
* algorithm. This doubles throughput
* against machines running Solaris,
* and seems to result in general
* improvement.
* Stefan Magdalinski : adjusted tcp_readable() to fix FIONREAD
* Willy Konynenberg : Transparent proxying support.
* Theodore Ts'o : Do secure TCP sequence numbers.
* David S. Miller : New socket lookup architecture for ISS.
* This code is dedicated to John Dyson.
*
* To Fix:
* Fast path the code. Two things here - fix the window calculation
* so it doesn't iterate over the queue, also spot packets with no funny
* options arriving in order and process directly.
*
* Rewrite output state machine to use a single queue.
* Speed up input assembly algorithm.
* RFC1323 - PAWS and window scaling. PAWS is required for IPv6 so we
* could do with it working on IPv4
* User settable/learned rtt/max window/mtu
*
* Change the fundamental structure to a single send queue maintained
* by TCP (removing the bogus ip stuff [thus fixing mtu drops on
* active routes too]). Cut the queue off in tcp_retransmit/
* tcp_transmit.
* Change the receive queue to assemble as it goes. This lets us
* dispose of most of tcp_sequence, half of tcp_ack and chunks of
* tcp_data/tcp_read as well as the window shrink crud.
* Separate out duplicated code - tcp_alloc_skb, tcp_build_ack
* tcp_queue_skb seem obvious routines to extract.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or(at your option) any later version.
*
* Description of States:
*
* TCP_SYN_SENT sent a connection request, waiting for ack
*
* TCP_SYN_RECV received a connection request, sent ack,
* waiting for final ack in three-way handshake.
*
* TCP_ESTABLISHED connection established
*
* TCP_FIN_WAIT1 our side has shutdown, waiting to complete
* transmission of remaining buffered data
*
* TCP_FIN_WAIT2 all buffered data sent, waiting for remote
* to shutdown
*
* TCP_CLOSING both sides have shutdown but we still have
* data we have to finish sending
*
* TCP_TIME_WAIT timeout to catch resent junk before entering
* closed, can only be entered from FIN_WAIT2
* or CLOSING. Required because the other end
* may not have gotten our last ACK causing it
* to retransmit the data packet (which we ignore)
*
* TCP_CLOSE_WAIT remote side has shutdown and is waiting for
* us to finish writing our data and to shutdown
* (we have to close() to move on to LAST_ACK)
*
* TCP_LAST_ACK out side has shutdown after remote has
* shutdown. There may still be data in our
* buffer that we have to finish sending
*
* TCP_CLOSE socket is finished
*/
Now look for the word 'state' (upper or lower case) in the above, and even
better, get a linux distribution and study the complete sources.
See you in a couple of years :)
I am now studying the pport 1284 protocol, as much 'fun', not
TCP/IP, but made me think microsoft was crazy, if we interfaced chips in
hardware the same way they do their software handshakes, then we would have to
go to .01 micron to get all the transistors on the chip....
OK, I am no TCP/IP expert either, but wait until you see what I can do with
what I know about programming.
Herman
side; you just ignore problems in your little engine and use error
handling and retransmissions of the other guy, to get things done. This
trick also buys you a lot of time and can help a small, slow processor
interface with a complex system.
It seems that doing things with limited resources is almost a lost
art...
Cheers,
Herman
http://www.AerospaceSoftware.com
Tim Tsai wrote:
>
> >Is it my ip? if not discard packet..
> >Is it port 80? Yes then it is for the http, branch same procedure http 'server'
> >Is it port for telnet ? yes then ...
> >other services here...
> >else discard packet.
> >mmm, efficient and why not.
>
> Let's not forget timeouts, retransmissions, packet reassembly, etc.
Dave VanHorn
> I wrote a complete CP/M (BTW operating system) in less then 8k,
> using 256 variables, and yes, I took the liberty of allocating 2 512 bytes
> buffers for the floppy I/O.
> Al that on a Z80.
Ah, but did you have multi-initiator arbitrating SCSI also in 8k? I did :)
Ampro Little board. A wonderful little machine. My first real computer
Tim Tsai
You guys are preaching to the choir as far as designing small systems
go. Most of us wouldn't be reading comp.realtime if we are not aware of
at least some of the embedded systems issues (and I realize realtime !=
embedded). The spec. just doesn't quite add up (which I am sure most of
you can appreciate).
Remember that the subject at hand is a single 4Mhz PIC (without external
storage) doing 115k in software, an RTOS, an *RFC compliant* TCP/IP stack
(which would generally imply handling error conditions correctly), an HTTP
1.1 compliant web server, a telnet server, and a filesystem. I am not
saying it's impossible, just that I haven't read or heard of anybody else
that's seen or verified the system. Guess we'll just have to speculate
until that happens.
Tim
Tim Tsai
>better, get a linux distribution and study the complete sources.
>See you in a couple of years :)
Your argument is amazing. If that is the case then I can probably claim
that all event driven programs are state machines. Perhaps I wasn't clear
in my original argument but just because the Linux TCP/IP stack uses
"states" doesn't make it comparable to the discussion at hand.
>OK, I am no TCP/IP expert either, but wait until you see what I can do with
>what I know about programming.
I think you are assuming that the rest of us are amateurs in programming,
or that we don't know how to program small/efficient systems. :-)
Tim
John West McKenna
> Let's not forget timeouts, retransmissions, packet reassembly, etc.
>and I am hardly a TCP/IP internals guru! TCP/IP is not a byte/word encoded
>state machine and is a bit more complicated than what you have outlined.
No, let's forget all of that. If you read the specs very carefully, and
only implement the bare minimum for the specific function that you're
performing, you can ignore a lot. Packet reassembly is easy - wait until
the next chunk that you're after arrives safely and append it to what
you've got. Ignore everything until that happens. If you're feeling
generous, you can tell the other end that you're only prepared to support a
window of size 1. But you don't have to - you can just pretend that all
those other packets got lost somewhere.
Timeouts are easy. If you haven't heard a full request from the one person
you're dealing with at the moment (dropping packets from everyone else, of
course) within N seconds, forget they ever existed.
Retransmissions are easy. Send a packet. If you don't get an ACK, don't
send the next one. Don't even start to prepare the data for the next one.
This is all within spec. It's horribly inefficient, but it's in spec.
There's no need to check the destination address - we're the only thing at
the end of this serial line, and the computer at the other end wouldn't
have sent this packet if it wasn't addressed to us. If you were pushed for
space, you could ignore a few checksums too. Assume that the packet
wouldn't have got here at all if they were wrong.
If I was doing this project, I'd encode my web pages as nice little IP
packets, all ready to have the destination address dropped in and sent on
their way.
Also don't even think about seperating HTTP/TCP/IP/SLIP. Lump it all in
together, and do the bare minimum with it.
If you think this is cheating, you haven't done enough embedded work.
Embedded work is almost entirely cheating everywhere you can get away with
it.
Remember - the goal is not to write a general purpose TCP stack. It is to
make a device that will respond to a few particular HTTP requests when
they're encoded in something that looks like TCP/IP/SLIP.
(I read the specs a little while after I heard about this device, and I'd
say the more of a guru you are, the more you'd know about what you can get
away with ignoring)
John West
Jan Panteltje
>> I wrote a complete CP/M (BTW operating system) in less then 8k,
>> using 256 variables, and yes, I took the liberty of allocating 2 512 bytes
>> buffers for the floppy I/O.
>> Al that on a Z80.
>
>Ampro Little board. A wonderful little machine. My first real computer
>
>
Apart from the fact I know next to nothing about SCSI, it shows that megabytes
are not always needed, and maybe the coding even takes less time in assembler ?
then in Visual G+- + 3000 or so libraries needed...
Or something like that..
Nice job.
I propose the 'green bits' label, it should only be given to those companies
that manage to decrease the code size of a next software release?
mmm that may not work, but something like that.
J
Herman
printer works, which explains why they tend to get lost in thought or go
off-line for no apparant reason from time to time. When one cuts
corners, it usually has a reliability penalty somewhere, but that is
fine if the advantages outweigh the disadvantages.
This guy with his PIC didn't say that he has a file system and the
response from his 'page' is a constant, so I assume that he has a
precooked packet in ROM which responds to a very specific string from
the server and that's it. No more!
Cheers,
Herman
http://www.AerospaceSoftware.com
Dave VanHorn
> Apart from the fact I know next to nothing about SCSI, it shows that
megabytes
> are not always needed, and maybe the coding even takes less time in
assembler ?
> then in Visual G+- + 3000 or so libraries needed...
The multi-initiator and arbitrating functions are part of the SCSI spec,
which most mfgrs seem to ignore. This lets you use two computers into one
hard drive, for example.
I get a little disturbed when I see mouse drivers that are larger than my
whole development system used to be.
The current project is an RTOS for a single chip micro, with many "library"
functions. I'm up to 1400 words of code, and already it's got a lot going
on in there.
> I propose the 'green bits' label, it should only be given to those
companies
> that manage to decrease the code size of a next software release?
> mmm that may not work, but something like that.
With clusters if they fixed alll the bugs in the previous release!
Very good idea indeed!
Of course you've got MS products with easter eggs slightly smaller than
exodus, and hidden flight simulators.. It's no wonder the stuff is bloated
and buggy.
Jan Panteltje
>Remember - the goal is not to write a general purpose TCP stack. It is to
>make a device that will respond to a few particular HTTP requests when
>they're encoded in something that looks like TCP/IP/SLIP.
>
Jan
Jan Panteltje
>storage) doing 115k in software, an RTOS, an *RFC compliant* TCP/IP stack
a read only memory.
Jan Panteltje
>>better, get a linux distribution and study the complete sources.
>>See you in a couple of years :)
>
>that all event driven programs are state machines. Perhaps I wasn't clear
>in my original argument but just because the Linux TCP/IP stack uses
>"states" doesn't make it comparable to the discussion at hand.
>
>>what I know about programming.
>
>or that we don't know how to program small/efficient systems. :-)
>
> Tim
>
if you have the time.
But having done several of these type of projects in asm I think it will not
be that difficult.
But I am not in immediate need of such a programmed micro chip, but if need was
to arise, I would publish the source, as I did with most programs I wrote that
were not property of some company or other.
That is why I would like that guy with his webserver PIC see the source code
published.
Anyway, I am not into arguing with you, you know best yourself what you are
capable of.
J
Zoltan Kocsi
> In a pinch, another trick is to rely on error handling on the other
> side; you just ignore problems in your little engine and use error
> handling and retransmissions of the other guy, to get things done.
With the notable exception of the other guy relying on your
error handling and retransmissions, in a similar fashion ...
Zoltan
--
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi | I don't believe in miracles |
| Bendor Research Pty. Ltd. | but I rely on them. |
+--------------------------------+---------------------------------+
Herman
can take advantage of it! For instance: TCP/IP is notable for its error
handling methodology. If you get a packet, but don't have time to
process it, simply don't ack it. Eventually you'll get another one.
So, if you have a slow PIC or something interfacing to a server, then
you can ack every other packet and slow things down that way. Messy, but
it'll work. There are many other tricks to aid you in designing a
small, dedicated little page server.
Tim Tsai
>say the more of a guru you are, the more you'd know about what you can get
>away with ignoring)
I am sorry, but I believe that the more of a guru you are, the more you
learn to first do 'back of the envelope' estimates to see whether the
system is even feasible given the hardware/software requirements. Gurus
don't spend 3 months implementing a system and then realize that it can
not be done.
According to *my* estimates, it approaches the impossible (and I am not
the only one). I'd like to be proven wrong, but not in generic terms.
Again, I am familiar with all the issues you have raised. You still
haven't qualified in the terms of the 4Mhz PIC, etc.
Tim
Tim Tsai
>This guy with his PIC didn't say that he has a file system and the
No, he *does* say that he has a filesystem. The web site even outlines
the file system hierarchy and the list of files in it.
Am I the only one who's gone to the webpage and read the spec?
Tim
Tim Tsai
He probably doesn't need an RTOS but he specifies in his web site.
I am also assuming that the system works here, which implies at the
minimum it can handle short bursts of packets at 115k without dropping
characters (a TCP/IP packet is 64 bytes minimum and is probably larger
for SLIP). I'd like somebody to tell me how to do that and still have
any cycles leftover using a 4Mhz PIC, assuming 10 bits per byte
transmitted.
Tim
Tim Tsai
the spec. (total is 512 words for program space and there is an EEPROM
for file storage. Also HTTP 1.0 vs. HTTP 1.1). The device itself is
supposed to be on the net but has been down since 9/1/99. I am just going
to stay out of this discussion until somebody verifies the implementation.
It is based on the world's smallest implementation of a TCP/IP stack --
which is implmented on a small 8-pin low-power microcontroller .. using
a mere 512 words of program ROM. If IPic can fit in a PIC, it can fit
in just about anything.
The TCP/IP code itself fits in about 256 bytes (12-bit), and the rest
is some extra salt-and-pepper and miscellaneous code.
1. The chip is a PIC 12C509A, running at 4MHz (Internal RC clock).
2. implementing the IPic tiny TCP/IP stack,
3. a HTTP 1.0 compliant web-server,
4. a simple telnet server (for editing files on the chip),
5. an 24LC256 i2c EEPROM
This is true real TCP/IP: Despite its small size, this wee tee cee pee
is a true implementation of very carefully hand-packed TCP/IP stack.
Perhaps I dont need to tell you any more than to say that it is compliant
with all applicable requirements of RFC-1122, Host Requirements Document,
the current standard which all implementations of TCP/IP on all hosts
on the Internet are required to meet in order to be connected to the
Internet.
Joseph A. Legris
between characters.
J.Legris
change the x to s to reply
Joseph A. Legris
between the bits of a 115K bps character. The handshaking lines on the RS-232
port can be manipulated to get as much time is required between characters.
The simple RTOS scheduler just plays with the handshaking, grabs a character,
stops further characters through handshaking and hands the character to the
next level. A task switch is very simple - no interrupts are available- the
RTOSsimply steps through a series of tasks each of which maintains its own
state counter and FSM.
A 4MHz PIC has a 1 MHz instruction rate. 115K is bits-per-second provides a
processing budget of 8 to 9 instructions per bit. Assume there are no false bit
transitions because of the direct connection to the router. Even though the
connection to the router is full-duplex, transmit/receive operation does not
have to be simultaneous.The RC oscillator of the PIC is adjusted so that the
instruction rate is an integral multiple of the bit rate:115K = 115200 Hz =
8.68 us. Adjust 4 Mhz RC oscillator to give 9 instructions ber bit time = 4.15
MHz or 8 instructions per bit time = 3.69 Mhz. I'll use the slower speed for
this example. It is not optimized. A clever programmer might be able to
actually sneak in some additional processing between bits instead of throwing
the time away in NOPS.
;-----Wait for start bit (input ==0)and synchronize-----
start_bit btfsc serial_port,receive_bit ;This loop uses 3 cycles =
1/3 bit time
goto start_bit
;-----Receive remaining 8 bits - at this point we are somewhere between 1/3 and
; 2/3 of the way into the start bit. Initialization of loop plus added
delay puts
; us 1 bit time later into the middle of the first data bit. Continue
delaying and
; sampling for all 8 bits.
get8bits movlw 8
movwf bit_counter
bcf uart_status,framing_error
nop
nop
nop
nop
nop
get1bit rlf serial_port,W ; N.B.: assumes receive bit is MSB
of port
rrf input_buffer, F ;rotates bit in via carry.
nop ;delay sufficiently to
make correct bit rate
nop
nop
decfsz bit_counter,F ;continue for 8 bits.
goto get1bit
;-----At this point the received charater is in the buffer. Receive the stop
bit to
; to check for framing error
stop_bit nop
btfss serial_port,receive_bit ;skip if stop bit = 1
bsf uart_status,framing_error
;--------Character received with time to spare
Tim Tsai
>between characters.
I've already thought about that - but all those compromises added
together and it feels more like a toy (proof-of-concept) vs. something
that's really usable in my book. Which might be the only reason we're
debating.
Personally, given all the compromises, I'd rather just see a small SNMP
implementation and forget about the web server, telnet server, etc.
Tim
Roberto Waltman
in the Mycal web site (of Seiko s7600 fame):
http://www.mycal.net/wsweb/links/
Links to Other Small Internet Servers
"iPic Webserver - Neat Demo. I hear it uses
a very stripped down version of what we at
iReady call stateless tcp with precomputed
packets in eeprom and very minor header
manipulation. Despite it's claims it is not RFC
compliant."
RW.
Neil Cherry
> http://www.mycal.net/wsweb/links/
>
> Links to Other Small Internet Servers
>
> "iPic Webserver - Neat Demo. I hear it uses
> a very stripped down version of what we at
> iReady call stateless tcp with precomputed
> packets in eeprom and very minor header
> manipulation. Despite it's claims it is not RFC
> compliant."
Wow, that was nicely put and reflects my feelings on that particular
web server. I'm going to save that for future slashdot articles on the
subject. :-)
--
Linux Home Automation Neil Cherry nch...@home.net
http://members.home.net/ncherry (Text only)
http://meltingpot.fortunecity.com/lightsey/52 (Graphics GB)
Herman
necessary parts of the RFC. This shows how much crud there is in the
RFC!
Have fun!
Herman
http://www.AerospaceSoftware.com
Adam Anderson
The future of Industrial Control systems lies within embedded TCP/IP devices on an
industrial network, fieldbus, so keep your eyes out someone like Allan
Bradley/Rockwell Automation will probably have a devices out soon.
Adam Anderson
"Joseph A. Legris" wrote:
--
TUNRA Industrial Electronics Division
1st Floor IDC Building
University Drive Callaghan
NSW 2308 Australia
Tel: (+61 2) 4967 1811
Fax: (+61 2) 4967 4946
EMail: aand...@mail.newcastle.edu.au
URL: http://www.newcastle.edu.au/tunra/tied/