TCP/IP on 8 bit micros
Renzo MARCANZIN
I have to develop a network of up to 20 subsystems connected
on a network. All system must check up to five "info receivers" that
talk in rs232 mode (CTS/RTS), and then all subsystems are connected to
an host PC.
The role of the subsystems is preatty easy to explain: listen all
receivers, pre-process information and then communicate with the host.
The problem is to choose the protocol between PC and subsystems.
I am experienced on C51 and H8S, but I will prefear to use C51
components for several reason, or, as second choice AVRs.
The subsystems must be fit into open space, no industrial space with
particular kind of noise.
I am evaluation if TCP/IP (or a subset) is a good choice for my
project. The QUESTION IS... ARE:
- has an 8 bit uP lice C51 power enough to run TCP/IP and then to pool
some other virtual serial ports?
Please not that I am NOT experienced on TCP/IP, but I developed a
software able to pool up to twelve virtual RS232 with autosense and
autobaudrate on a C51. The problem is that I have NOT any Idea of the
complexity of TCP/IP. Then....
- is an RTOS a Must when you use TCP/IP or any foreground/bkgrn
application could be implemented?
- Which is the best TCP/IP (free or commercial) implementation for 8
bit micros? (C51, AVR and more)
Thanks
Tauno Voipio
"Renzo MARCANZIN" <ai...@cutthis.poboxdotcom> wrote in message
news:91di4u47ctugfsfc9...@4ax.com...
1. The full RFC -compliant TCP/IP stack does not fit into a 8051 family (or
any other 8-bit) processor, even with an external data memory. The
buffering requirements of a worst case IP packet already exceeds the
addressing capability of the processor: the maximum packet size is 65535
bytes.
2. A significant question is: which hardware connection is intended between
the 8051 and the host PC. The options I see are:
2.1 Ethernet (10Base-T or 100Base-T)
2.2 Asynchronous serial ('RS-232') with SLIP
2.3 Asynchronous serial ('RS-232') with PPP
3. The TCP part of the TCP/IP stack is more complicated than the rest of an
UDP/IP stack together.
4. IMHO, the serial interface methods (2.2 or 2.3) and TCP need some kind of
multi-thread capability of the processor. The 8-bit processors are poor in
this respect (see a discussion on this forum a couple of days ago). An
intelligent Ethernet controller (like the SMSC LAN91C96 and relatives) with
a suitably stripped UDP/IP stack (surely non-RFC-compliant) could be made to
run without a multi-thread system.
5. There is no need for the 100 Mbit Ethernet. A 10Base-T interface is more
than sufficient and much easier to make work.
6. You should also consider the combination of a 10Base-T Ethernet
transferring frames at the basic Ethernet level without TCP/IP at all. This
option requires more programming effort on the PC side, but is easy in the
slaves.
HTH
Tauno Voipio
tauno voipio @ iki fi
Harald Kipp
> some other virtual serial ports?
Yes, no question. However, the task is quite complex, you probably
need a high level language.
> - is an RTOS a Must when you use TCP/IP or any foreground/bkgrn
> application could be implemented?
There had been some discussions in this group. At least you
need timer handling. Multithreading support simplifies the
TCP stack even further. I'd recommend a simple RTOS.
> - Which is the best TCP/IP (free or commercial) implementation for 8
> bit micros? (C51, AVR and more)
www.ethernut.de offers the most hyperduperfroggle TCP/IP for
AVR micros...just kidding (am I?) :-)
Many 8-bit ports are based on Waterloo TCP, many other on KA9Q.
Both are a bit old-fashioned and also require lots of RAM.
Harald Kipp
can live with UDP. It's much simpler and could even
be done in assembly language. You have to do your
own handshaking, but with your application this
might be easily done.
Renzo MARCANZIN
On Sat, 19 Jan 2002 11:21:06 GMT, "Tauno Voipio"
<tauno....@iki.fi.SPAMBAIT_REMOVE> wrote:
>1. The full RFC -compliant TCP/IP stack does not fit into a 8051 family (or
>any other 8-bit) processor, even with an external data memory. The
>buffering requirements of a worst case IP packet already exceeds the
>addressing capability of the processor: the maximum packet size is 65535
>bytes.
Yes, but I need just a subset of the protocol just to allow
some peripherals to communicate. In truth I do NOT need Real Time
communicatoions.
>2. A significant question is: which hardware connection is intended between
>the 8051 and the host PC. The options I see are:
>
> 2.1 Ethernet (10Base-T or 100Base-T)
> 2.2 Asynchronous serial ('RS-232') with SLIP
> 2.3 Asynchronous serial ('RS-232') with PPP
Is secondary, also because the PC software will be developed
in our company using Visual tools from M$.
>3. The TCP part of the TCP/IP stack is more complicated than the rest of an
>UDP/IP stack together.
Please note that i do NOT know TCP/IP nor UDP/IP.
Could you please explain to me differences?
>4. IMHO, the serial interface methods (2.2 or 2.3) and TCP need some kind of
>multi-thread capability of the processor. The 8-bit processors are poor in
>this respect (see a discussion on this forum a couple of days ago). An
>intelligent Ethernet controller (like the SMSC LAN91C96 and relatives) with
>a suitably stripped UDP/IP stack (surely non-RFC-compliant) could be made to
>run without a multi-thread system.
This appear to me the best choice too.
>5. There is no need for the 100 Mbit Ethernet. A 10Base-T interface is more
>than sufficient and much easier to make work.
You can bet.
>6. You should also consider the combination of a 10Base-T Ethernet
>transferring frames at the basic Ethernet level without TCP/IP at all. This
>option requires more programming effort on the PC side, but is easy in the
>slaves.
AT the present time the old project work on 485 with a
proprietary (our) protocol. I would like something of more "standard"
and compatible. This is the reason of TCP/IP.
Any suggestion is welcome.
>HTH
This help me a lot.
Adam Dunkels
Renzo MARCANZIN wrote:
> - has an 8 bit uP lice C51 power enough to run TCP/IP and then to pool
> some other virtual serial ports?
> Please not that I am NOT experienced on TCP/IP, but I developed a
> software able to pool up to twelve virtual RS232 with autosense and
> autobaudrate on a C51. The problem is that I have NOT any Idea of the
> complexity of TCP/IP. Then....
If you plan on using C, the absolutely smallest code size to expect is
probably 3-4k for a very stripped down TCP/ICMP/IP stack. Since you'll need
some kind of networking hardware, the code for that would have to be added
to the above figure. An RS232/SLIP implementation would add some 2k of
code, and an Ethernet/ARP implementation would probably be slightly larger.
Some kind of application program is also needed to actually use the TCP/IP
stack. The code size of the application program is of course depending on
the complexity of your particular application. A very basic web server
(HTTP) with simple script capabilities can be fitted into 1-2k of code.
The RAM requirements depend on your particular application (i.e., how many
simulateneous TCP connections that are needed, what packet sizes that
you'll need to use, etc.) but the minumum is somewhere around 200 bytes.
To sum that up, the code size for the TCP/IP stack, device driver and
application program is somewhere around 10k.
Of couse, such a stripped down TCP/IP stack does not provide very high
throughput, but it is sufficient if all you need to do is transfer some
data between your device and a PC.
To have an even smaller stack, you could use UDP instead of TCP. The main
difference between UDP and TCP is that UDP is best-effort whereas TCP is
relieable. UDP datagrams may be lost or reordered in transit, but TCP data
is reliably delivered in order. To achieve reliability, TCP uses sequence
numbers and retransmissions. Since UDP does not implement any such
mechanisms, it is significantly simpler.
If your application could handle a few missing pieces of data, UDP is
probably the right choise.
> - is an RTOS a Must when you use TCP/IP or any foreground/bkgrn
> application could be implemented?
While a TCP/IP stack as such does not require an RTOS, it will affect how
you write your application program. In a multithreaded system, the
application program can be written in a sequential fashion similar to how
BSD socket programs are writte. In a system without an RTOS, the
application program would have to be event based (i.e., driven by
callbacks) and coded as a state machine. While the latter is not
necessarily harder, it is different from what a lot of people might be used
to.
The TCP/IP stack will have to be more complex to be able to deal with
multithreaded applications.
> - Which is the best TCP/IP (free or commercial) implementation for 8
> bit micros? (C51, AVR and more)
I wouldn't know which one is the best, but I can give you a few pointers.
The commercial CMX Micronet stack seems to be the TCP/IP stack that has
been ported to the most microcontrollers. I have heard that their techincal
support is very good as well. CMX can be found at http://www.cmx.com.
LiveDevices also offer a commerical TCP/IP stack:
http://www.livedevices.com.
My own free uIP stack (from which the above code size figures are taken)
can be downloaded from http://dunkels.com/adam/uip/.
/adam
--
Adam Dunkels <ad...@dunkels.net> (Spambait)
http://dunkels.com/adam/
Adam Dunkels
Tauno Voipio wrote:
> 1. The full RFC -compliant TCP/IP stack does not fit into a 8051 family
> (or any other 8-bit)  processor, even with an external data memory. The
> buffering requirements of a worst case IP packet already exceeds the
> addressing capability of the processor: the maximum packet size is 65535
> bytes.
No, to be RFC compliant only 576 bytes large IP packets have to be handled.
While IP allows packets to be as large as 65536 bytes, no packets are ever
that large. The larges packet size that is actually in wide use is NFS' 8k
UDP datagrams.
The reason for not using such large packets is that IP will have to chop it
up into smaller IP fragments. If one such fragment is lost in the network,
the entire packet will have to be discarded.
Jeremy Bentham
> 1. The full RFC -compliant TCP/IP stack does not fit into a 8051 family
(or
> any other 8-bit) processor, even with an external data memory. The
> buffering requirements of a worst case IP packet already exceeds the
> addressing capability of the processor: the maximum packet size is 65535
> bytes.
..and the minimum packet size is 576 bytes, which will fit in many
microcontrollers, even without the use of on-the-fly packet assembly and
decoding techniques. The sole purpose of the 65535 number is to frighten
small children, who may be thinking of developing their own TCP/IP stack,
against their parents' advice.
> 2. A significant question is: which hardware connection is intended
between
> the 8051 and the host PC. The options I see are:
>
> 2.1 Ethernet (10Base-T or 100Base-T)
> 2.2 Asynchronous serial ('RS-232') with SLIP
> 2.3 Asynchronous serial ('RS-232') with PPP
A considerable range of difficulty; PPP really isn't for the faint-hearted.
Ethernet can be easier to use than SLIP or PPP on microcontrollers with
limited RAM, since the Ethernet controller has a generous 8KB of on-chip RAM
to buffer incoming and outgoing packets.
> 3. The TCP part of the TCP/IP stack is more complicated than the rest of
an
> UDP/IP stack together.
Agreed, unless PPP is required.
> 4. IMHO, the serial interface methods (2.2 or 2.3) and TCP need some kind
of
> multi-thread capability of the processor. The 8-bit processors are poor in
> this respect (see a discussion on this forum a couple of days ago).
I disagree; SLIP is trivial to implement using serial interrupts alone. PPP
state machines would be slightly easier using multi-threading, but a simple
event-handling scheme is a viable alternative.
> An intelligent Ethernet controller (like the SMSC LAN91C96 and relatives)
with
> a suitably stripped UDP/IP stack (surely non-RFC-compliant) could be made
to
> run without a multi-thread system.
I prefer the NE2000-compatible RTL8019AS chip, and would say that such a
scheme isn't difficult to implement; look up the packet formats, and fill in
the blanks. Assuming ARP and ICMP were included, and small datagrams were
sent so there were no fragmentation issues, why can't it be RFC-compliant?
> 5. There is no need for the 100 Mbit Ethernet. A 10Base-T interface is
more
> than sufficient and much easier to make work.
Agreed - though a recent thread discussed some interesting 100M controllers.
> 6. You should also consider the combination of a 10Base-T Ethernet
> transferring frames at the basic Ethernet level without TCP/IP at all.
This
> option requires more programming effort on the PC side, but is easy in the
> slaves.
In the 'good old days' of RS232 communication, everyone used their own
proprietary protocol, and inter-operability was a nightmare. We now have a
standard set of networking protocols, and I think everyone should be
encouraged to use them wherever possible. Which programmer is more hireable;
one who develops strange non-standard protocols, or one who has developed a
TCP/IP stack?
Renzo Marcanzin asked which was the best TCP/IP for 8-bit micros; in all
conscience, I can't claim that title for my book 'TCP/IP Lean', though I do
claim it has the best explanation of TCP/IP miniaturisation techniques,
particularly when the second edition (with 5 extra chapters) comes out.
Jeremy Bentham
Iosoft Ltd.
Paul J. Bosselaers
>- is an RTOS a Must when you use TCP/IP or any foreground/bkgrn
>application could be implemented?
It depends on your application but in general an RTOS is not a must when using a
TCP/IP stack.
>- Which is the best TCP/IP (free or commercial) implementation for 8
>bit micros? (C51, AVR and more)
Check out CMX-MicroNet at http://www.cmx.com. CMX-MicroNet was written from
scratch to be run on 8-bit processors like the 8051 and Atmel AVR and uses very
little ROM and RAM.
Byron A Jeff
Renzo MARCANZIN <ai...@cutthis.poboxdotcom> wrote:
-As first, THANKS to everyone.
-
-On Sat, 19 Jan 2002 11:21:06 GMT, "Tauno Voipio"
-<tauno....@iki.fi.SPAMBAIT_REMOVE> wrote:
-
->1. The full RFC -compliant TCP/IP stack does not fit into a 8051 family (or
->any other 8-bit) processor, even with an external data memory. The
->buffering requirements of a worst case IP packet already exceeds the
->addressing capability of the processor: the maximum packet size is 65535
->bytes.
-
- Yes, but I need just a subset of the protocol just to allow
-some peripherals to communicate. In truth I do NOT need Real Time
-communicatoions.
I didn't real-time in the original quote anywhere.
-
->2. A significant question is: which hardware connection is intended between
->the 8051 and the host PC. The options I see are:
->
-> 2.1 Ethernet (10Base-T or 100Base-T)
-> 2.2 Asynchronous serial ('RS-232') with SLIP
-> 2.3 Asynchronous serial ('RS-232') with PPP
-
- Is secondary, also because the PC software will be developed
-in our company using Visual tools from M$.
-
This wasn't about PC software. This was a question of the physical interface
used to connect the components. You state below that you are using RS-485.
If this works, you may want to consider keeping it.
->3. The TCP part of the TCP/IP stack is more complicated than the rest of an
->UDP/IP stack together.
-
- Please note that i do NOT know TCP/IP nor UDP/IP.
- Could you please explain to me differences?
TCP/IP protocols are stacked in 4 layers:
Application: Protocols like HTTP, SMTP, FTP, POP, IMAP, DNS, NFS that used
for web, mail, file transfer, print services and the like.
Transport: protocols for end to end delivery of data. Also has multiplexing
so that multiple applications can use the network at the same time.
Comes in two complementary subtypes:
TCP: bidirectional virtual-circuit protocol that guarantees the in-order
delivery of data. It encapulates acknoledgements, flow control, and
congestion control to ensure that everything gets deliever and that
it doesn't flood the network while doing it.
UDP: unicast unreliable datagram delivery. Has no sequencing, flow control
and makes no guarantees about the delivery of data. Ofter used
for short call response sequences such as DNS.
Internet: The Internet Protocol (IP) does it's best to deliver packets across
multiple possibly unreliable networks. It's the protocol that links
all of the internet's local networks into a single global net.
Physical: Bit transport. Includes ethernet, wireless, RS232 and RS485, and
all other physical data transports.
-
->4. IMHO, the serial interface methods (2.2 or 2.3) and TCP need some kind of
->multi-thread capability of the processor. The 8-bit processors are poor in
->this respect (see a discussion on this forum a couple of days ago). An
->intelligent Ethernet controller (like the SMSC LAN91C96 and relatives) with
->a suitably stripped UDP/IP stack (surely non-RFC-compliant) could be made to
->run without a multi-thread system.
-
- This appear to me the best choice too.
I'd argue against it. Since you already have a physical transport, RS485,
I'd suggest using it.
-
->5. There is no need for the 100 Mbit Ethernet. A 10Base-T interface is more
->than sufficient and much easier to make work.
-
- You can bet.
-
->6. You should also consider the combination of a 10Base-T Ethernet
->transferring frames at the basic Ethernet level without TCP/IP at all. This
->option requires more programming effort on the PC side, but is easy in the
->slaves.
-
- AT the present time the old project work on 485 with a
-proprietary (our) protocol. I would like something of more "standard"
-and compatible. This is the reason of TCP/IP.
I think you should simply implement UDP/IP on top of RS485. Then have either
a simple primary/secondary or simulated token ring protocol to get rid of
collisions.
BAJ
Desilva
Do you have experience in working with udp in real life?
I am wondering how often you will have the case where ´datagram 2 arrives
before datagram 1. Udp doesnt garantee that the sending order is the
receiving order, but in real life.. how often does it not?
After all... more often than not, all packets will be routed the same way.
Just being currious.. i am allso implementing tcp, and frankly i cant see
how to do it on my avr 90s8515 withough making it a quite simple
implementation.. like the one i have now.
So i am allso thinking about just using udp and then make my own simpler tcp
on top of that.
But... how about the sequence? Is it needed?
Robert Reimiller
<j...@iosoft.nospam.uk> wrote:
>..and the minimum packet size is 576 bytes, which will fit in many
>microcontrollers, even without the use of on-the-fly packet assembly and
>decoding techniques. The sole purpose of the 65535 number is to frighten
>small children, who may be thinking of developing their own TCP/IP stack,
>against their parents' advice.
>
Dave Hudson
Jeremy Bentham wrote:
>
> ..and the minimum packet size is 576 bytes, which will fit in many
> microcontrollers, even without the use of on-the-fly packet assembly and
> decoding techniques. The sole purpose of the 65535 number is to frighten
> small children, who may be thinking of developing their own TCP/IP stack,
> against their parents' advice.
Whilst 576 is the minimum requirement in the RFC's it's proabably fair
to say that for performance reasons it makes sense to support 1504 bytes
so that full size Ethernet frames can be supported - this makes quite a
difference when trying to achieve high levels of throughput.
> A considerable range of difficulty; PPP really isn't for the faint-hearted.
> Ethernet can be easier to use than SLIP or PPP on microcontrollers with
> limited RAM, since the Ethernet controller has a generous 8KB of on-chip RAM
> to buffer incoming and outgoing packets.
It is possible to do PPP on pretty small microcontrollers (one of my
colleagues did this), but, certainly it's a tight squeeze.
>>3. The TCP part of the TCP/IP stack is more complicated than the rest of
>> an UDP/IP stack together.
>
> Agreed, unless PPP is required.
Again, I think it rather depends on the level of RFC-compliance being
sought. The experience I had when writing the TCP and PPP stacks for
Liquorice (open source) and subsequently writing much of the ipStack and
ipPPP modules for the Ubicom IP2022 has been that there's little to
choose between the two protocols in terms of complexity. Potentially
PPP can be significantly larger than TCP in fact because it's really
more a collection of protocols rather than one and can be used for so
many purposes - there are many possible protocol negotiations,
authentication and compression schemes, etc. Conversely specific
aspects of TCP implementation (especially where performance is an issue)
can be problematic too.
>>4. IMHO, the serial interface methods (2.2 or 2.3) and TCP need some kind
>>of multi-thread capability of the processor. The 8-bit processors are poor in
>>this respect (see a discussion on this forum a couple of days ago).
>
> I disagree; SLIP is trivial to implement using serial interrupts alone. PPP
> state machines would be slightly easier using multi-threading, but a simple
> event-handling scheme is a viable alternative.
FWIW I've written implementations that work both ways and found that the
event-based solutions have been by far the most efficient (lower MIPs
and memory requirements), but they're perhaps more awkward to use (but
then there's nothing to prevent event-driven code being wrapped by
threading code - going the other way doesn't really work though).
To give an example of where threading is unecessary I've recently been
working on a Bluetooth LAN access point solution using an 8-bit CPU
(IP2022 - running some code at 120 MIPs and some at 30 MIPs). It's been
quite possible to saturate (sustained) a 921 kbps UART connection to a
Bluetooth module in a LAN access point. The same processor is running
both the ~ 1 Mbps UART and 10 base-T Ethernet connections in software
(every 10 bits on the UART and every 16 on the Ethernet connection
require servicing an interrupt), running a full Bluetooth stack
(HCI/UART, HCI, L2CAP, RFCOMM), running PPP (async-HDLC, LCP, and IPCP)
over the Bluetooth stack, running IP over PPP and then running IP
routing between the PPP and Ethernet connections. None of the code in
question had to be specialized for the application.
The problem perhaps is that 8-bit processors have a very wide range of
performance characteristics - the high end is more than 100x the
peformance of the low end.
> In the 'good old days' of RS232 communication, everyone used their own
> proprietary protocol, and inter-operability was a nightmare. We now have a
> standard set of networking protocols, and I think everyone should be
> encouraged to use them wherever possible. Which programmer is more hireable;
> one who develops strange non-standard protocols, or one who has developed a
> TCP/IP stack?
Not only this, but in many applications the use of non-standard
protocols is becoming increasingly frowned upon by end-users. I used to
develop software to integrate control and monitoring systems (typically
more than 100 per site) and the end users of these systems were
completely dismayed by their inability to mix and match units from
different suppliers. TCP/IP over Ethernet doesn't necessarily solve
this problem but it certainly makes it a lot easier.
> Renzo Marcanzin asked which was the best TCP/IP for 8-bit micros; in all
> conscience, I can't claim that title for my book 'TCP/IP Lean', though I do
> claim it has the best explanation of TCP/IP miniaturisation techniques,
> particularly when the second edition (with 5 extra chapters) comes out.
I think the answer to the original question must be to work out exactly
which protocols are needed, how much throughput is required, what other
processing needs to happen and whether scalability to other systems or
reusability for other projects is a consideration. There are a *lot* of
IP-based solutions out there for 8-bit CPUs :-)
Regards,
Dave
Steve Cashmore
>> Argh..one thing I forget. Make up your mind if you
>> can live with UDP. It's much simpler and could even
>> be done in assembly language. You have to do your
>> own handshaking, but with your application this
>> might be easily done.
>
>Do you have experience in working with udp in real life?
>I am wondering how often you will have the case where 悲atagram 2 arrives
>before datagram 1. Udp doesnt garantee that the sending order is the
>receiving order, but in real life.. how often does it not?
>After all... more often than not, all packets will be routed the same way.
>
>Just being currious.. i am allso implementing tcp, and frankly i cant see
>how to do it on my avr 90s8515 withough making it a quite simple
>implementation.. like the one i have now.
>So i am allso thinking about just using udp and then make my own simpler tcp
>on top of that.
>But... how about the sequence? Is it needed?
Datagrams arriving out of sequence only tends to occur on wider
internets involving routers. If you're talking about a local Ethernet
network without routers then UDP packets don't arrive out of sequence.
Packets may of course go missing just like they might with say a RS485
network so some sort of sequencing and error management must be
employed.
I have implemented several small embedded systems using Ethernet both
with raw ethernet packets and UDP. Using UDP usually makes
interfacing with 3rd party systems easier as I've already mentioned in
another post. There is only a small additional overhead to using UDP
depending on the size of the packets used.
--
Steve
Renzo MARCANZIN
Your web site was the first one I visited as I decided to
learn more about TCP/P!
On Sat, 19 Jan 2002 16:53:37 +0100, Adam Dunkels <ad...@dunkels.net>
wrote:
>The TCP/IP stack will have to be more complex to be able to deal with
>multithreaded applications.
The application does NOT require any kind of RT, so NO RTOS
is required, Just a question in order to start with the right step.
> [...]UDP datagrams may be lost or reordered in transit,
Only the order of packets may be lost or also some packets.
I have NO problems of order, but I can NOT risk that any
packet be lost.
>> - Which is the best TCP/IP (free or commercial) implementation for 8
>> bit micros? (C51, AVR and more)
>
>I wouldn't know which one is the best, but I can give you a few pointers.
>
>The commercial CMX Micronet stack seems to be the TCP/IP stack that has
>been ported to the most microcontrollers. I have heard that their techincal
>support is very good as well. CMX can be found at http://www.cmx.com.
>
>LiveDevices also offer a commerical TCP/IP stack:
>http://www.livedevices.com.
>
>My own free uIP stack (from which the above code size figures are taken)
>can be downloaded from http://dunkels.com/adam/uip/.
I usually use the Temic T89C51RD2, it's a 64Kbytes of Flash,
In APPLICATION programmable with more than 1 kbyte of ram. X2 mode and
more. A very nice micro. I ABSOLUTELY need
>/adam
Renzo MARCANZIN
On Sat, 19 Jan 2002 16:55:17 -0000, "Jeremy Bentham"
<j...@iosoft.nospam.uk> wrote:
>In the 'good old days' of RS232 communication, everyone used their own
>proprietary protocol, and inter-operability was a nightmare. We now have a
>standard set of networking protocols, and I think everyone should be
>encouraged to use them wherever possible. Which programmer is more hireable;
>one who develops strange non-standard protocols, or one who has developed a
>TCP/IP stack?
I like your sentence. That's exactly my mind when I wrote the
Original news. Now we have a system with a strange protocol, yes, it
works, but it's completely custom and unable to talk with other
subsystems.
Now we are planning a completely new system, and I would like to be
the more standard It will be possible.
I do not need ethernet, but what I need is a STANDARD protocol that
ensure that everything gets delievered.
I think that TCP/IP will be the best choice.
Now I only have to find it!
>Renzo Marcanzin asked which was the best TCP/IP for 8-bit micros; in all
>conscience, I can't claim that title for my book 'TCP/IP Lean', though I do
>claim it has the best explanation of TCP/IP miniaturisation techniques,
>particularly when the second edition (with 5 extra chapters) comes out.
>
>Jeremy Bentham
>Iosoft Ltd.
>
You can bet that I il buy it!
Renzo
Dr Peter
"Renzo MARCANZIN" <ai...@cutthis.poboxdotcom> wrote in message
Why not rework the 485 protocol for better efficiency/speed then connect a
"hub" or data concentrator to the system, one or more ports talking to the
old system and one port ( ethernet or say USB ) to the pc..??
Tauno Voipio
"Desilva" <n...@mail.here> wrote in message
news:a2cope$ia0$1...@news.cybercity.dk...
> > Argh..one thing I forget. Make up your mind if you
> > can live with UDP. It's much simpler and could even
> > be done in assembly language. You have to do your
> > own handshaking, but with your application this
> > might be easily done.
>
> Do you have experience in working with udp in real life?
Please send me your E-mail address.
Change the spaces in the address in the sig to periods where sensible.
Tauno Voipio
"Renzo MARCANZIN" <ai...@cutthis.poboxdotcom> wrote in message
> Thanks again for all answers. I apreciate a lot.
>
> the more standard It will be possible.
> I do not need ethernet, but what I need is a STANDARD protocol that
> ensure that everything gets delievered.
> I think that TCP/IP will be the best choice.
> Now I only have to find it!
>
Please note that a strictly STANDARD TCP/IP is too heavy for 8-bit micros
despite of the other opinions here. Everybody has assumed some slip from the
standards.
For reference see RFC 1122 and RFC 1123 and the standards referenced there.
The MTU of 576 bytes applies to a fragment of an IP packet, the
STANDARD -compliant stack has to be able to cope with a 65535 byte packet,
even if it is not sensible to send such long packets.
An useable TCP/IP implementation can be done with much less, as most of the
constructions referenced here have successfully done.
I have been using a simple non-STANDARD, but working, UDP/IP implementation
with SMSC Ethernet controllers for quite a while with AVRs and Atmel ARMs
successsfully.
As long as there are no routers with alternative routings between the
communication endpoints, even the UDP datagrams do all arrive in order sent.
By far the simplest way to get a TCP/IP compatible connection is to use a
SLIP connection with a stripped UDP/IP stack. The problem with your
environment is that there is a possibility of overloading the controller
with the serial line traffic. An Ethernet controller is pretty good in
unloading the networking data-link level traffic from the controller.
Besides, a serial connection needs one interface per connected slave at the
host PC, but Ethernet will do with a single interface card and a cheap hub.
Dave Hudson
Tauno Voipio wrote:
> "Renzo MARCANZIN" <ai...@cutthis.poboxdotcom> wrote in message
> news:g81k4ukbjr40dlvq6...@4ax.com...
>
>>Thanks again for all answers. I apreciate a lot.
>>
>>Now we are planning a completely new system, and I would like to be
>>the more standard It will be possible.
>>I do not need ethernet, but what I need is a STANDARD protocol that
>>ensure that everything gets delievered.
>>I think that TCP/IP will be the best choice.
>>Now I only have to find it!
>>
>>
>
> Please note that a strictly STANDARD TCP/IP is too heavy for 8-bit micros
> despite of the other opinions here. Everybody has assumed some slip from the
> standards.
Whilst there may be non-compliances in many stacks simply by virtue of
using an 8-bit CPU does not mean that a stack is non-compliant.
There are plenty of examples where major IP stacks (generally regarded
as fully compliant) do not follow the letter of the RFCs and there's
considerable room for interpretation in other areas.
> For reference see RFC 1122 and RFC 1123 and the standards referenced there.
>
> The MTU of 576 bytes applies to a fragment of an IP packet, the
> STANDARD -compliant stack has to be able to cope with a 65535 byte packet,
> even if it is not sensible to send such long packets.
RFC1122 page 56:
--
3.3.2 Reassembly
The IP layer MUST implement reassembly of IP datagrams.
We designate the largest datagram size that can be reassembled by EMTU_R
("Effective MTU to receive"); this is sometimes called the "reassembly
buffer size". EMTU_R MUST be greater than or equal to 576, SHOULD be
configurable or indefinite, and SHOULD be greater than or equal to the
MTU of the connected network(s).
--
This states clearly that 576 alone is the requirement for standards
compliance (MUST clause) but it's recommended (but not required) that
the MTU be larger. Ideally it's stated that it should be greater than
or equal to the MTU of the network so this would say that a 1.5k MTU is
more than sufficient for Ethernet. It does not say that the smallest
fragment must be 576 bytes but that the host must be able to reassemble
a 576 byte fragemented packet.
Similarly RFC1122 page 59:
--
(a) In general, no host is required to accept an IP datagram larger than
576 bytes (including header and data), so a host must not send a larger
datagram without explicit knowledge or prior arrangement with the
destination host. Thus, MMS_S is only an upper bound on the datagram
size that a transport protocol may send; even when MMS_S exceeds 556,
the transport layer must limit its messages to 556 bytes in the absence
of other knowledge about the destination host.
--
A previous poster (sorry I forget who) noted that NFS packets may wish
to use 8 kByte datagrams, however that's clearly an example of where the
hosts involved in using NFS agree in advance to use a larger minimum.
Equally though there are plenty of RFCs that stipulate that packets must
be less that 576 bytes in order to allow all standards-compliant systems
to work - e.g. RFC1157 (SNMP) which stipulates a maximum SNMP message
size of 484 bytes or RFC2131 (DHCP) which notes that DHCP messages
should not exceed 576 octets unless a specific negotiation has taken
place to agree a larger MTU.
> As long as there are no routers with alternative routings between the
> communication endpoints, even the UDP datagrams do all arrive in order sent.
Whilst true this doesn't note that some datagrams may go missing in
transport. If an Ethernet packet is badly framed, if there are
excessive collisions on the network or if the receiving host is under
very heavy load it's quite possible to drop frames from the sequence.
They may arrive in order but with gaps. Strictly though there is no
requirement on UDP that it must deliver in order, although most
implementations do. Given corner-case situations even the best behaved
IP stacks can do strange things.
Regards,
Dave
Tauno Voipio
"Dave Hudson" <da...@cyclicode.net> wrote in message
news:3C4AD4F7...@cyclicode.net...
I agree.
I tried to point out that the standards are for HEAVY networking. Actually,
there is a strong need for a compatible stripped TCP standard for embedded
devices.
Dave Hudson
Tauno Voipio wrote:
I'd tend to agree - although I wonder if a block-oriented (rather than
stream-oriented) reliable protocol with the ability to handle congestion
control might fit this need better. The recently proposed DCP protocol
comes close to this but doesn't quite meet ideal embedded requirements
(where in-order delivery would be very desireable) whereas SCTP is just
far too heavyweight :-(
I'm not really sure that I'd like to see TCP stripped down though - the
loss of any part of the existing behaviour (even just that specified up
to and including RFC1122) would potentially cause problems (the sort of
congestion they were designed to avoid) on networks, especially if any
form of traffic routing is required. Increasingly as embedded systems
are put onto IP networks there's a greater liklihood of routing being a
requirement (if it's not already) as remote service or performance
monitoring becomes the norm.
Regards,
Dave
Tauno Voipio
"Dave Hudson" <da...@cyclicode.remove-this.net> wrote in message
news:3C4AE5C0...@cyclicode.remove-this.net...
This begins to be slightly OT ...
The main points giving trouble with TCP are:
- bi-directionality, especially half-closed connections
- out-of-band (urgent) data
There are other problematic points, too, but most connections would do
without OOB or the special arrangements for bulk data flow.
Adam Dunkels
Renzo MARCANZIN wrote:
>> [...]UDP datagrams may be lost or reordered in transit,
>
> Only the order of packets may be lost or also some packets.
> I have NO problems of order, but I can NOT risk that any
> packet be lost.
Then you should definately go with TCP. Adding a reliability layer on top
of UDP is as difficult as doing a simple TCP.
Adam Dunkels
Desilva wrote:
> Do you have experience in working with udp in real life?
> I am wondering how often you will have the case where ´datagram 2 arrives
> before datagram 1. Udp doesnt garantee that the sending order is the
> receiving order, but in real life.. how often does it not?
> After all... more often than not, all packets will be routed the same way.
A 1999 paper by Bennet, Partridge, and Shectman called "Packet Reordering
is Not Pathological Network Behaviour", showed that packet reordering in
the Internet is far more frequent than previously thought. The paper can be
downloaded from this web page:
http://www-iepm.slac.stanford.edu/monitoring/reorder/
Local area networks are much less likely to reorder packets, but since more
and more intelligence is added to LANs in the form of hubs, switches and
proxy-ARP routers, packet reordering can happen even on a local network.
Adam Dunkels
> The main points giving trouble with TCP are:
>
> - bi-directionality, especially half-closed connections
> - out-of-band (urgent) data
None of these are really necessary to implement in TCP, unless the
application specifically requires it.
Adam Dunkels
Tauno Voipio wrote:
> I tried to point out that the standards are for HEAVY networking.
> Actually, there is a strong need for a compatible stripped TCP standard
> for embedded devices.
The protocols in the TCP/IP suite were not really designed for todays'
heavy gigabit networks - rather, extra tweaking has been made to make TCP
work nicely on gigabit networks. Window scaling, timestamps and protection
against wrapped sequence numbers are all such additions that have been made
to TCP.
Actually, TCP is quite nice for embedded devices; a stripped down,
RFC-compliant TCP is not as large as most people tend to think. By using a
very small TCP window and only allowing one in-flight segment per
connection, a lot of extra bookkeeping and mechanisms can be removed while
still being RFC-compliant. Other RFC requirements that can be safely
removed are those that deal with the TCP/application interface (such as
"SEND call can specify PUSH") and mechanisms that the application is not
interested in using anyway (such as urgent data).
The very small TCP implementation in uIP conforms to most TCP MUSTs - there
are a few that haven't been implemented as of yet such as zero-window
probing and RTT estimation. The implementation of those will not make the
code significantly larger or the increase the RAM requirements.
Dave Hudson
Adam Dunkels wrote:
>
> Actually, TCP is quite nice for embedded devices; a stripped down,
> RFC-compliant TCP is not as large as most people tend to think. By using a
> very small TCP window and only allowing one in-flight segment per
> connection, a lot of extra bookkeeping and mechanisms can be removed while
> still being RFC-compliant. Other RFC requirements that can be safely
> removed are those that deal with the TCP/application interface (such as
> "SEND call can specify PUSH") and mechanisms that the application is not
> interested in using anyway (such as urgent data).
Of course one problem with only allowing one segment in-flight is that
unless the remote system needs to send a segment back then deferred ACK
processing probably restricts things to 5 segments per second. While
many applications don't have a problem with this, for something like an
embedded web server this can become really quite irritating. It becomes
much worse when there's a significant round trip time between the
endpoints as with say a 200 ms RTT we end up only transferring 2.5
segments per second. One advantage with getting at least two segments
in-flight at a time is that the (resource limited) sender has to hold
the data in-flight ready for retransmission, but if it can get two
segments away then the remote end will ACK immediately the second one is
received and this will actually reduce memory pressure on the sender!
Again, there's some code required to do this, but not too much.
> The very small TCP implementation in uIP conforms to most TCP MUSTs - there
> are a few that haven't been implemented as of yet such as zero-window
> probing and RTT estimation. The implementation of those will not make the
> code significantly larger or the increase the RAM requirements.
IMHO RTT estimation is essential if the data's going to go over any
significant network path, or alternatively the sender has to adopt a
very conservative retransmission policy and that can slow things right down.
Regards,
Dave
Tauno Voipio
"Adam Dunkels" <ad...@dunkels.net> wrote in message
news:a2eqji$2cu0$2...@not.sics.se...
> Tauno Voipio wrote:
> > The main points giving trouble with TCP are:
> >
> > - bi-directionality, especially half-closed connections
> > - out-of-band (urgent) data
>
> None of these are really necessary to implement in TCP, unless the
> application specifically requires it.
>
Yes.
The original thread was about strictly standard implementation - it doen
require all the stuff.
Tauno Voipio
tauno voipio @ iki fi
PS.
I'm still of the opinion that we desperately need a standard of how to strip
TCP (and to a lesser degree IP) for small embedded devices.
My vision of an instrument's user interface is HTTP and a browser in the
customer's PC. Here we need a very simple, and standardised, implementation
of TCP.
TV
Tauno Voipio
"Tauno Voipio" <tauno....@iki.fi.SPAMBAIT_REMOVE> wrote in message
news:N6E28.295$b9.1...@read2.inet.fi...
>
> The original thread was about strictly standard implementation - it doen
Ooops: read 'does' instesd of 'doen'.
TV
Adam Dunkels
Dave Hudson wrote:
> Of course one problem with only allowing one segment in-flight is that
> unless the remote system needs to send a segment back then deferred ACK
> processing probably restricts things to 5 segments per second. While
> many applications don't have a problem with this, for something like an
> embedded web server this can become really quite irritating. It becomes
> much worse when there's a significant round trip time between the
> endpoints as with say a 200 ms RTT we end up only transferring 2.5
> segments per second. One advantage with getting at least two segments
> in-flight at a time is that the (resource limited) sender has to hold
> the data in-flight ready for retransmission, but if it can get two
> segments away then the remote end will ACK immediately the second one is
> received and this will actually reduce memory pressure on the sender!
> Again, there's some code required to do this, but not too much.
This is indeed the most serious problem with having only one in-flight
segment per connection. But an implementation that does allow two in-flight
segments would not be the minimal TCP implementation that Tauno requested.
Still, you are terribly right in that a TCP sender really should be able to
hold at least two segments in-flight. With two in-flight segments, the TCP
sender would also have to perform congestion control which would add a few
bytes of code (but not very many!) and one bit more of per-connection
state.
> IMHO RTT estimation is essential if the data's going to go over any
> significant network path, or alternatively the sender has to adopt a
> very conservative retransmission policy and that can slow things right
> down.
Indeed, and on paths with *very* large queueing delays (on the order of
10-60 seconds), even a quite conservative RTO of 5 seconds could contribute
to congestion collapse. Such long delays are unusual but can happen on
dial-up connections.
Adam Dunkels
Tauno Voipio wrote:
>> > The main points giving trouble with TCP are:
>> >
>> > - bi-directionality, especially half-closed connections
>> > - out-of-band (urgent) data
>>
>> None of these are really necessary to implement in TCP, unless the
>> application specifically requires it.
>>
>
> Yes.
>
> The original thread was about strictly standard implementation - it does
> require all the stuff.
Actually, my point was that none of those two mechanisms are needed even in
the most strictly standard implementation - unless the application
specifically needs it.
Consider this: a system which runs an application that never sends any
data, only listens to incoming connection requests and when a connection
has been set up, starts to receive data from the remote end of the
connection. Since this is all the system ever does, the TCP/IP stack does
not have to implement the ability to send TCP data. It will still be RFC
compliant, however, even though there are no code for doing slow-start,
retransmissions (other than the SYNACK) or other mechanisms that are
involved in sending TCP data.
Even though the RFC requires that a TCP sender should do slow-start, etc.,
this code would never be executed in this particular system, and is
therefore not needed.
The same goes for the two mechanisms you list; if the application never
ever uses them, the TCP/IP stack does not need to implement them. The TCP
will still be RFC compliant, however.
> I'm still of the opinion that we desperately need a standard of how to
> strip TCP (and to a lesser degree IP) for small embedded devices.
>
> My vision of an instrument's user interface is HTTP and a browser in the
> customer's PC. Here we need a very simple, and standardised,
> implementation of TCP.
Like I said, the essentials of TCP are already small enough to be
implemented in small embedded systems - uIP does stripped down IP/ICMP/TCP
in 3-4k for instance. Having an "almost-TCP" protocol would just be a
headache - having to run a TCP-to-almost-TCP proxy on the nodes which
connect the embedded devices increases the complexity of the system.
Still, I definately agree with you on that TCP should not be stripped
without doing some serious thinking first. If people start to strip things
such as congestion control from their TCPs, we could start seeing local
congestion collapses.
Bryan Whitton
a customer that used it on his CANOpne/TC/IP 591 project and it worked
very well.
Bryan Whitton
American Raisonance
American Raisonance, Inc.
PO Box 1784
Addison, TX 75001-1786
Voice: 877-315-0792 Fax: 972-818-0792
Michael Dombrowski
>conscience, I can't claim that title for my book 'TCP/IP Lean', though I do
>claim it has the best explanation of TCP/IP miniaturisation techniques,
>particularly when the second edition (with 5 extra chapters) comes out.
When is your new book coming out? I'd really like to pick up a copy...
Mike
Byron A Jeff
-Hi Renzo!
-
-Renzo MARCANZIN wrote:
->> [...]UDP datagrams may be lost or reordered in transit,
->
-> Only the order of packets may be lost or also some packets.
-> I have NO problems of order, but I can NOT risk that any
-> packet be lost.
-
-Then you should definately go with TCP. Adding a reliability layer on top
-of UDP is as difficult as doing a simple TCP.
This looks like a good place to get back into the conversation.
The problem I've always had with TCP is that it seems to be an all or nothing
affair. TCP has several major and orthogonal issue tracks:
* sequencing
* multiplexing/ports
* acknoledgements
* connection setup/teardown
* round trip times/timeouts
* retransmissions
* flow control/windowing
* congestion control
* bidirectional data transfer
* options
* buffering
* urgent/out of band data
* checksums
Now from my reading, a compliant TCP implementation must implement in some
form or fashion each of the areas above. My problem with this approach is
that unless you're compliant, there are no guarantees that your application
is going to converse properly with other TCP stacks.
I'm a big fan of UDP. There's only one or two implementable issues above IP:
* multiplexing/ports
* checksums
And RCF768 described a specific mechanism to indicate that a checksum was
not generated.
I'm a big fan of UDP for a few reasons:
* Since it rides on top of IP, it's just as internet routable as any other
internet traffic.
* Since it's a standard, nearly every internet based device has a well tested
solid stack to implement applications on. This limits the amount of system
debugging that's required, since a nonworking system points to the embedded
node being implemented.
* It's simple. Which means I can pick and choose which, if any, addition
features are required for my application.
So what I'm interested in how stripped down can TCP get and still be compliant.
For reliable UDP I can simply pick a very simple sequencing/ACK scheme with
no buffering, no windowing, no congestion control, etc. And since it's built
on top of a standard UDP stack, it's should be compliant and port anywhere.
TCP is great. It's designed for sequenced, reliable, bidirectional delivery
of data on an unstable underlaying network.
But I feel it's a stretch to say that implementing a simple sequencing/ACK
scheme in UDP is anywhere as near complex as implementing a compliant TCP
stack. And I'm going to insist on a compliant stack because it's not
possible to make guarantees of any type with an uncompliant one.
Comments?
BAJ
Tauno Voipio
"Byron A Jeff" <by...@cc.gatech.edu> wrote in message
news:a2gb15$4...@cleon.cc.gatech.edu...
Thanks.
You cannot get rid of all the checksums - the IP header needs it anyway.
IMHO, the checksums are badly designed:
- a checksum should guard the data between the hosts,
not between the layers in a host, so the only good
place for a checksum is at the data link layer,
- the layering is badly mixed up with the IP pseudo-headers
in TCP and UDP checksums.
One way of transferring data with UDP is TFTP.
My needs for stripped TCP:
- simpler than the full thing
- behaves well in larger network
- does not need to be fast or elegant
The main problem is that HTTP needs TCP to run. The single-segment
implementations already in this thread will do for most browser/OS
combinations, but are they good enough from the network standpoint?
Adam Dunkels
Byron A Jeff wrote:
> So what I'm interested in how stripped down can TCP get and still be
> compliant. For reliable UDP I can simply pick a very simple sequencing/ACK
> scheme with no buffering, no windowing, no congestion control, etc. And
> since it's built on top of a standard UDP stack, it's should be compliant
> and port anywhere.
>
> TCP is great. It's designed for sequenced, reliable, bidirectional
> delivery of data on an unstable underlaying network.
>
> But I feel it's a stretch to say that implementing a simple sequencing/ACK
> scheme in UDP is anywhere as near complex as implementing a compliant TCP
> stack. And I'm going to insist on a compliant stack because it's not
> possible to make guarantees of any type with an uncompliant one.
>
> Comments?
[This is actually discussed elsewhere in this thread.]
One reason for choosing TCP over UDP-with-reliable-application is that TCP
can be used directly with existing software such as web browsers, whereas a
reliable UDP solution requires special software on the PC side.
My experience with TCP after implementing it a number of times in different
ways is that the absolute core of the TCP functionality is fairly small,
after all. When first looking at the TCP specifications, the protocol seems
to be very heavy but a lot of the "heavy" functionality can be removed and
while still being compliant.
For instance, TCP uses a sliding window mechanism to allow data to be
reordered in transit without degrading throughput. The implementation of
such a sliding window mechanism will require some amount of bookkeeping
both on the sender side and the receiver side. This seems like a big
obstacle for implementing TCP is the smallest systems. But it turns out
that TCP does not strictly require this sliding window mechanism - it is
perfectly happy as a simple sequencing/ACK protocol. Without sliding
window, the buffering needs and code complexity drops dramatically.
Furthermore, when running TCP as a sequencing/ACK protocol with only one
in-flight segment, congestion control is reduced to maintaining a good RTT
estimation and using exponential backoff for retransmissions. In any case,
congestion control is not expensive to implement. All it requires is two
extra state variables and a few lines of code.
The bi-directionality of TCP can easily be avoided by designing your
application in such a way that data only flows in one direction. Then there
is no need to implement more than one part of TCP - either the sender or
the receiver.
The TCP options are relatively trivial - the SYN and SYNACK segments are
the only ones that will contain options that are useful to a small embedded
system. There is only one option that needs to be parsed - the maximum
segment size (MSS) option.
Urgent and out-of-band data can be safely omitted from the implementation
since not very many applications require it. The implementation will still
will be RFC compliant if the application does not use the feature.
In short: TCP can be stripped down to a minimum of functionality while
retaining RFC compliance. A small, RFC-compliant, implementation requires
around 3k of code.
Adam Dunkels
Tauno Voipio wrote:
> You cannot get rid of all the checksums - the IP header needs it anyway.
>
> IMHO, the checksums are badly designed:
>
> -áaáchecksumáshouldáguardátheádataábetweenátheáhosts,
> notábetweenátheálayersáináaáhost,ásoátheáonlyágood
> placeáforáaáchecksumáisáatátheádataálinkálayer,
You'd still want an end-to-end checksum. Since not even the combined link
and TCP/UDP checksums will catch all errors, an application level checksum
such as an MD5 hash is recommended for sensitive data.
> -átheálayeringáisábadlyámixedáupáwithátheáIPápseudo-headers
> ináTCPáandáUDPáchecksums.
>
> One way of transferring data with UDP is TFTP.
I may be wrong here, but one of the arguments against using TFTP is that it
does not do proper congestion control. Thus, it is not very suitable for
anything else than transfering small amounts of data over the local area
network.
> My needs for stripped TCP:
> -ásimpleráthanátheáfulláthing
> -ábehavesáwelláinálargeránetwork
> -ádoesánotáneedátoábeáfastáoráelegant
>
> The main problem is that HTTP needs TCP to run. The single-segment
> implementations already in this thread will do for most browser/OS
> combinations, but are they good enough from the network standpoint?
A single-segment TCP is even better than a multiple-segment TCP from the
network standpoint since it contributes less to congestion. A multi-segment
TCP connection can fill a router's, whereas a single-segment TCP connection
only can use one queue slot in one router along the path.
Adam Dunkels
> A single-segment TCP is even better than a multiple-segment TCP from the
> network standpoint since it contributes less to congestion. A
> multi-segment TCP connection can fill a router's, whereas a single-segment
> TCP connection only can use one queue slot in one router along the path.
... that should be read at "A multi-segment TCP connection can fill a
router's queue [...]".
Bahri Okuroglu
devices to the TCP/IP/Ethernet network. Terminal server has multiple RS232
ports and an Ethernet interface. It switches data between these RS232 ports
and TCP ports.
The microcontroller simply writes to the RS232 port and PC gets the data
written over TCP.
It is quite easy and there is no need for additional code/library for the
controller. The only thing you need is the terminal server which costs about
$1000+.
> I have to develop a network of up to 20 subsystems connected
> on a network. All system must check up to five "info receivers" that
> talk in rs232 mode (CTS/RTS), and then all subsystems are connected to
> an host PC.
Tauno Voipio
"Bahri Okuroglu" <bahrio@__yahoo__.com> wrote in message
news:a2gi9j$4tq$1...@bcarh8ab.ca.nortel.com...
> I think the easiest method would be using a terminal server to connect the
> devices to the TCP/IP/Ethernet network. Terminal server has multiple RS232
> ports and an Ethernet interface. It switches data between these RS232
ports
> and TCP ports.
>
> The microcontroller simply writes to the RS232 port and PC gets the data
> written over TCP.
>
> It is quite easy and there is no need for additional code/library for the
> controller. The only thing you need is the terminal server which costs
about
> $1000+.
Yes.
And that's no solution to a EUR 200 controller.
Jeremy Bentham
> When is your new book coming out? I'd really like to pick up a copy...
I'm told that TCP/IP Lean 2nd edition will be available in April. I've added
5 extra PICmicro chapters, covering Ethernet interfacing, PPP, UDP
client/server, DHCP, and TCP email clients.
I originally planned to include a detailed discussion of RFC conformance
issues, such as have been explored in this thread. After 36,000 words I
still hadn't made a start on this topic, the publisher's deadlines were
imminent, and writer's exhaustion was setting in, so it didn't get included.
This is a real shame - as microcontroller TCP/IP stacks graduate from being
a hobbyist curiosity to a commercial reality, we do need a concensus as to
what should/must be included in these stacks. Newsgroup threads such as this
do serve a useful purpose in achieving such as consensus, but are too
ephemeral to act as lasting guidance.
I've long thought we need our own version of RFC 1122 for embedded TCP/IP,
to formalise the points raised here, and avoid the necessity of
re-discussing the same issues every few months.
Jeremy Bentham
Iosoft Ltd.
Dave Hudson
Jeremy Bentham wrote:
> Michael Dombrowski wrote
>
> I've long thought we need our own version of RFC 1122 for embedded TCP/IP,
> to formalise the points raised here, and avoid the necessity of
> re-discussing the same issues every few months.
Perhaps something in the form of a "best current practice" document
w.r.t. low-cost embedded systems? I'm not sure that we need a new
version or RFC1122 with the accompanying MUST, SHOULD, MAY and MUST NOT
clauses because that would tend to lead to incompatibilities with
existing systems. There would certainly seem to be room to interpret
some of the non-mandatory parts w.r.t. implementation in low-cost or
low-performance applications though.
Regards,
Dave
Tauno Voipio
"Jeremy Bentham" <j...@iosoft.nospam.uk> wrote in message
news:TyR28.63375$WQ1.9...@news6-win.server.ntlworld.com...
>
> I've long thought we need our own version of RFC 1122 for embedded TCP/IP,
> to formalise the points raised here, and avoid the necessity of
> re-discussing the same issues every few months.
>
> Jeremy Bentham
> Iosoft Ltd.
>
Bravo!
Adam Dunkels
You are absolutely right; none of the requirements in the specifications of
the TCP/IP protocol suite should be changed, but discussions about the
trade-offs involved would be good to have in a BCP. Even small TCP/IP
implementations would have to adhere to RFC1122, but could benefit from
knowing what parts that could safely be removed or minimized without
sacrificing RFC compliance.
Jeremy, since you obviously have done some serious thinking in this area,
it would be very interesting to hear your comments on the recent
discussion.
Stuart Tyrrell
"Jeremy Bentham" <j...@iosoft.nospam.uk> wrote:
> Michael Dombrowski wrote
>
> > When is your new book coming out? I'd really like to pick up a
> > copy...
>
> I'm told that TCP/IP Lean 2nd edition will be available in April.
> I've added 5 extra PICmicro chapters, covering Ethernet interfacing,
> PPP, UDP client/server, DHCP, and TCP email clients.
>
> I originally planned to include a detailed discussion of RFC
> conformance issues, such as have been explored in this thread. After
> 36,000 words I still hadn't made a start on this topic, the
> publisher's deadlines were imminent, and writer's exhaustion was
> setting in, so it didn't get included.
OK, so we'll buy the 2nd edition.....
When's the 3rd edition coming out? ;-)
Stuart.
--
Stuart Tyrrell Developments Stu...@stdevel.demon.co.uk
PO Box 183, OLDHAM. OL2 8FB http://www.stdevel.demon.co.uk
Tel: 0845 458 8803 / 01706 848 600 Fax: 0870 164 1604
Blakely LaCroix
writes:
>Now from my reading, a compliant TCP implementation must implement in some
>form or fashion each of the areas above. My problem with this approach is
>that unless you're compliant, there are no guarantees that your application
>is going to converse properly with other TCP stacks.
Which raises a question: What tools or methods are used to validate a TCP/IP
implementation?. Are there formal validation software suites or even just a
disagnostic TCP/IP site where it will exercise your implementation and test all
of the various requirements and report any defeciencies?
Blakely LaCroix
Minneapolis, Minnesota, USA.
RBP Clique member # 86.
The best adventure is yet to come.
mi...@invalid.email.com
> Datagrams arriving out of sequence only tends to occur on wider
> internets involving routers. If you're talking about a local Ethernet
> network without routers then UDP packets don't arrive out of sequence.
> Packets may of course go missing just like they might with say a RS485
> network so some sort of sequencing and error management must be
> employed.
Actually out of order packets seem to occure in highspeed loaded networks
according to most of the data I've seen. There are some exceptions like
DoCoMo's DoPa network when the channel needs to be setup.
But it seems like most of the time it is when the interframe gap is razor
thin on 100mbps and 1G networks, and going through routers.
mike
Jeremy Bentham
> Jeremy, since you obviously have done some serious thinking in this area,
> it would be very interesting to hear your comments on the recent
> discussion.
I agree with most of the points made, except those taking a 'bah, humbug'
approach to microcontroller TCP/IP. It would be good to preserve this kind
of discussion for future reference; it does seem to resurface every few
months in this newsgroup.
As far as a replacement/clarification of RFC1122 goes, I think a new RFC
would be desirable as it could
1. Remove a lot of obsolete stuff (e.g. trailer encapsulation) that clutters
the current standard and confuses newcomers.
2. Acknowledge that there is a fundamental difference between a
multi-purpose OS with networking capability, and a cost-constrained embedded
system. The former should have every possible networking capability (in case
the user requires it); the latter should only have limited capabilites, as
dictated by the needs of the embedded application, and the requirements of
network inter-operability.
3. Remove the logging, error-handling and API function definitions of
RFC1122 that imply the existence of a filesystem, console and large RAM,
suggest smaller alternatives where possible.
4. Tackle some of the murkier waters of stripped-down TCP stacks, such as
- Must IP fragment reassembly be supported?
- Can one assume that a short TCP text message (e.g. start of HTTP
request) is in a single segment?
- How far may the standard routing (e.g. route cacheing) be simplified?
- Are stateless TCP implementations acceptable?
- Can lock-step TCP used as an alternative to congestion control?
I don't want to trigger (undoubtedly heated) discussion of these topics now,
but simply wish to flag them up as issues that need to be resolved - as an
example of this, I have a cheap RFC1122-compliant gateway from a well-known
vendor that doesn't perform as expected in 2 of these areas, but I can't
find any hint of this in their documentation.
Maybe a good way to start the ball rolling would be to write an 'Embedded
TCP/IP' FAQ...?
Jeremy Bentham
Iosoft Ltd.
Dave Hudson
Blakely LaCroix wrote:
> Which raises a question: What tools or methods are used to validate a TCP/IP
> implementation?. Are there formal validation software suites or even just a
> disagnostic TCP/IP site where it will exercise your implementation and test all
> of the various requirements and report any defeciencies?
There are some commercial testsuites around (e.g. the ANVL testsuite),
but nothing open-source (that I'm aware of). It would be possible to
build such a test system using ideas from something like hping2, but I
guess this isn't a particularly fun thing to write and so no-one has :-)
The bigger problem for embedded (resource constrained) systems is that
running anything but trivial conformance tests requires some sort of
application to be running on the embedded host that can interact with
the testsuite - this presents problems of portability, maintainability
and resource usage.
Regards,
Dave
Unknown
>I'm told that TCP/IP Lean 2nd edition will be available in April. I've added
>5 extra PICmicro chapters, covering Ethernet interfacing, PPP, UDP
>client/server, DHCP, and TCP email clients.
i have first edition, where i get the 2nd?
fast as possible?
thx
bye, klaus
Geoff McCaughan
>
> I may be wrong here, but one of the arguments against using TFTP is that it
> does not do proper congestion control. Thus, it is not very suitable for
> anything else than transfering small amounts of data over the local area
> network.
At a PPOE, I worked on an embedded system which we had deployed in some
rather out-of-the-way locations. I implemented the ability to upgrade
the firmware to these systems using HTTP upload, and because there
was little extra effort involved, added TFTP as well.
TFTP was significantly slower than HTTP, but I found it had less
tendency to quit when the going got rough [i.e. when the target system
is hanging off a wireless link at the back end of a mine pit somewhere
in Wyoming]. When it's winter in Wyoming, being able to reliably send
firmware upgrades over the wire from a *long* way away is a *big* plus.
When faced with a variable-latency link with packet loss, TCP seems
to curl up and die quicker than some dumber protocols.
Jeremy Bentham
> OK, so we'll buy the 2nd edition.....
> When's the 3rd edition coming out? ;-)
Ho ho ho - it takes me at least 18 months to forget quite how miserable the
writing process is, another 4 to agree an outline with the publisher, 2 to
prepare the code for publication, 1 month to decide the outline is
completely useless, and then 2 months to write the manuscript in a mad panic
as the deadline looms. As for the 3rd edition, your guess is as good as
mine.
<Klaus Volker> wrote
> i have first edition, where i get the 2nd? fast as possible?
'fraid I don't know much about book distribution; check out the various
on-line sites nearer the date.
Jeremy Bentham
Iosoft Ltd.
Tauno Voipio
Agreed.
> Maybe a good way to start the ball rolling would be to write an 'Embedded
> TCP/IP' FAQ...?
>
You're volunteering?
> Jeremy Bentham
> Iosoft Ltd.
Dave
little embedded device, how much congestion could it possibly create? I'm
having a hard time imagining a little embedded device that takes weather
measurements or something using up gigabytes of bandwidth. It's probably
down in the kilobytes. What kind of bandwidth are we talking about here?
How many of these devices will be online, etc?
Dave Hudson
Well, as an example I used to work with embedded networks with well over
100 devices per site (and several hundred such sites per end-user). One
kByte per second from each of these would add up to rather a lot :-)
The issue though is more likely to be what happens when traffic to or
from such devices needs to go through potentially congested links - two
badly behaved systems sending as little as say 30 kBytes per second each
would saturate 512 kbps broadband links in and out of the site rendering
other parts of the system inaccessible or unusable.
30 kBps is a pretty low data rate for quite a number of 8-bit embedded
processors these days where several people have noted throughputs
between 2 Mbps and 8 Mbps in recent discussions.
Regards,
Dave
Adam Dunkels
> I'm seeing so much emphasis on preventing congestion but if this is just a
> little embedded device, how much congestion could it possibly create? I'm
> having a hard time imagining a little embedded device that takes weather
> measurements or something using up gigabytes of bandwidth. It's probably
> down in the kilobytes. What kind of bandwidth are we talking about here?
> How many of these devices will be online, etc?
Imagine millions of small embedded devices - "one in every lightbulb" -
connected to the global Internet...
In general, congestion is caused by the amount of packets and not the size
of those packets. Even if a small device only is able to send a few 20 byte
packets, those will usually use as much router queue slots as a few 1500
byte packets.
Martin Schoeberl
Perhaps a little strange question:
Has anyone tried to implement a TCP/IP (via PPP) stack in Java?
The reason is, that I'm working on a pure Java processor
(http://www.jopdesign.com)
(as soft core for a FPGA) and all drivers have to be coded in Java.
If no one has done it before it's time for me to start :-)
Martin
--
"Adam Dunkels" <ad...@dunkels.net> schrieb im Newsbeitrag
news:a2c4q5$hq8$1...@not.sics.se...
> Hi Renzo!
>
> Renzo MARCANZIN wrote:
> > - has an 8 bit uP lice C51 power enough to run TCP/IP and then to pool
> > some other virtual serial ports?
> > Please not that I am NOT experienced on TCP/IP, but I developed a
> > software able to pool up to twelve virtual RS232 with autosense and
> > autobaudrate on a C51. The problem is that I have NOT any Idea of the
> > complexity of TCP/IP. Then....
>
> If you plan on using C, the absolutely smallest code size to expect is
> probably 3-4k for a very stripped down TCP/ICMP/IP stack. Since you'll
need
> some kind of networking hardware, the code for that would have to be added
> to the above figure. An RS232/SLIP implementation would add some 2k of
> code, and an Ethernet/ARP implementation would probably be slightly
larger.
>
> Some kind of application program is also needed to actually use the TCP/IP
> stack. The code size of the application program is of course depending on
> the complexity of your particular application. A very basic web server
> (HTTP) with simple script capabilities can be fitted into 1-2k of code.
>
> The RAM requirements depend on your particular application (i.e., how many
> simulateneous TCP connections that are needed, what packet sizes that
> you'll need to use, etc.) but the minumum is somewhere around 200 bytes.
>
> To sum that up, the code size for the TCP/IP stack, device driver and
> application program is somewhere around 10k.
>
> Of couse, such a stripped down TCP/IP stack does not provide very high
> throughput, but it is sufficient if all you need to do is transfer some
> data between your device and a PC.
>
> To have an even smaller stack, you could use UDP instead of TCP. The main
> difference between UDP and TCP is that UDP is best-effort whereas TCP is
> relieable. UDP datagrams may be lost or reordered in transit, but TCP data
> is reliably delivered in order. To achieve reliability, TCP uses sequence
> numbers and retransmissions. Since UDP does not implement any such
> mechanisms, it is significantly simpler.
>
> If your application could handle a few missing pieces of data, UDP is
> probably the right choise.
>
> > - is an RTOS a Must when you use TCP/IP or any foreground/bkgrn
> > application could be implemented?
>
> While a TCP/IP stack as such does not require an RTOS, it will affect how
> you write your application program. In a multithreaded system, the
> application program can be written in a sequential fashion similar to how
> BSD socket programs are writte. In a system without an RTOS, the
> application program would have to be event based (i.e., driven by
> callbacks) and coded as a state machine. While the latter is not
> necessarily harder, it is different from what a lot of people might be
used
> to.
>
> The TCP/IP stack will have to be more complex to be able to deal with
> multithreaded applications.
>
> > - Which is the best TCP/IP (free or commercial) implementation for 8
> > bit micros? (C51, AVR and more)
>
> I wouldn't know which one is the best, but I can give you a few pointers.
>
> The commercial CMX Micronet stack seems to be the TCP/IP stack that has
> been ported to the most microcontrollers. I have heard that their
techincal
> support is very good as well. CMX can be found at http://www.cmx.com.
>
> LiveDevices also offer a commerical TCP/IP stack:
> http://www.livedevices.com.
>
> My own free uIP stack (from which the above code size figures are taken)
> can be downloaded from http://dunkels.com/adam/uip/.
Dave
the over head in sending multiple data packets that could potentially
overload the network.
Dave
"Dave Hudson" <da...@cyclicode.remove-this.net> wrote in message
news:3C4EA18C...@cyclicode.remove-this.net...
Richard Rooney
Any micro (no matter how puny) can have a TCP/IP connection - use the Seiko
S-7600.
See http://www.iready.org
and
www.orlin.com
"Tauno Voipio" <tauno....@iki.fi.SPAMBAIT_REMOVE> wrote in message
news:CEc28.81$aY5....@read2.inet.fi...
>
> "Renzo MARCANZIN" <ai...@cutthis.poboxdotcom> wrote in message
> news:91di4u47ctugfsfc9...@4ax.com...
> > Hi all,
> > I have to develop a network of up to 20 subsystems connected
> > on a network. All system must check up to five "info receivers" that
> > talk in rs232 mode (CTS/RTS), and then all subsystems are connected to
> > an host PC.
> > The role of the subsystems is preatty easy to explain: listen all
> > receivers, pre-process information and then communicate with the host.
> > The problem is to choose the protocol between PC and subsystems.
>
> > I am experienced on C51 and H8S, but I will prefear to use C51
> > components for several reason, or, as second choice AVRs.
>
> > The subsystems must be fit into open space, no industrial space with
> > particular kind of noise.
> > I am evaluation if TCP/IP (or a subset) is a good choice for my
> > project. The QUESTION IS... ARE:
> > - has an 8 bit uP lice C51 power enough to run TCP/IP and then to pool
> > some other virtual serial ports?
>
> > Please not that I am NOT experienced on TCP/IP, but I developed a
> > software able to pool up to twelve virtual RS232 with autosense and
> > autobaudrate on a C51. The problem is that I have NOT any Idea of the
> > complexity of TCP/IP. Then....
>
> > - is an RTOS a Must when you use TCP/IP or any foreground/bkgrn
> > application could be implemented?
>
> > - Which is the best TCP/IP (free or commercial) implementation for 8
> > bit micros? (C51, AVR and more)
> >
>
> 1. The full RFC -compliant TCP/IP stack does not fit into a 8051 family
(or
> any other 8-bit) processor, even with an external data memory. The
> buffering requirements of a worst case IP packet already exceeds the
> addressing capability of the processor: the maximum packet size is 65535
> bytes.
>
> 2. A significant question is: which hardware connection is intended
between
> the 8051 and the host PC. The options I see are:
>
> 2.1 Ethernet (10Base-T or 100Base-T)
> 2.2 Asynchronous serial ('RS-232') with SLIP
> 2.3 Asynchronous serial ('RS-232') with PPP
>
> 3. The TCP part of the TCP/IP stack is more complicated than the rest of
an
> UDP/IP stack together.
>
> 4. IMHO, the serial interface methods (2.2 or 2.3) and TCP need some kind
of
> multi-thread capability of the processor. The 8-bit processors are poor in
> this respect (see a discussion on this forum a couple of days ago). An
> intelligent Ethernet controller (like the SMSC LAN91C96 and relatives)
with
> a suitably stripped UDP/IP stack (surely non-RFC-compliant) could be made
to
> run without a multi-thread system.
>
> 5. There is no need for the 100 Mbit Ethernet. A 10Base-T interface is
more
> than sufficient and much easier to make work.
>
> 6. You should also consider the combination of a 10Base-T Ethernet
> transferring frames at the basic Ethernet level without TCP/IP at all.
This
> option requires more programming effort on the PC side, but is easy in the
> slaves.
>
> HTH
Jeff Fox
>
> Any micro (no matter how puny) can have a TCP/IP connection
> - use the Seiko S-7600.
> See http://www.iready.org and www.orlin.com
Cute. I bookmarked it to add to the list of other similar
internet ready boards.
But perhaps you have never seen a really small micro.
But sure if your system has a free I/O bit you can also
attach a PC to it to do the TCP/IP and then say that
the tiny micro has a TCP/IP connection and hard disk
and windows interface and ...
Massuda
> Hi all,
> I have to develop a network of up to 20 subsystems connected
> on a network. All system must check up to five "info receivers" that
> talk in rs232 mode (CTS/RTS), and then all subsystems are connected to
> an host PC.
> - has an 8 bit uP lice C51 power enough to run TCP/IP and then to pool
> some other virtual serial ports?
> Please not that I am NOT experienced on TCP/IP, but I developed a
> software able to pool up to twelve virtual RS232 with autosense and
> autobaudrate on a C51. The problem is that I have NOT any Idea of the
> complexity of TCP/IP. Then....
> - is an RTOS a Must when you use TCP/IP or any foreground/bkgrn
> application could be implemented?
> - Which is the best TCP/IP (free or commercial) implementation for 8
> bit micros? (C51, AVR and more)
these are the smallest TCP/IP stacks that I know:
lwIP: http://www.sics.se/~adam/lwip/
uIP: http://dunkels.com/adam/uip/
Both support TCP and UDP. You can use SLIP as your network transport layer.
Massuda
Martin Schoeberl
A VERY simple web server complete in Java
running via slip on a PC and on JOP.
If anybody is interested I can mail the Java source.
Martin
--
"Martin Schoeberl" <martin.s...@chello.at> schrieb im Newsbeitrag
news:CQC38.48963$5G5.3...@news.chello.at...