On Wed, Sep 05, 2001 at 08:54:51AM -0400, Olin Lathrop wrote:
> > I feel there are a few compelling arguments for the continued use of IP in
> the
> > above situation:
> >
> > 1) By using standard internet protocols, the collection/gateway server can
> > physically be decoupled from its sources. For example UDP/IP can be used
> to
> > deliver data from multiple disparate sites, where the data is then
> coalesed
> > and presented to the rest of the Internet via a web interface.
> >
> > 2) By using standard internet protocols, the network stacks, applications,
> > and developement tools are well known and well tested. With a rock solid
> > foundation on one site, one can be pretty sure that any errors that occur
> > can be isolated to the simple PIC stack. This is instead of having to
> create
> > and debug both ends of the network link. Even with only UDP building an
> > application is little more than picking a language, opening the socket,
> > and sending/receiving the data. All of the underlaying network/OS
> > infrastructure is already in place.
> >
> > 3) By using standard internet protocols, a well honed, widespread, and
> deeply
> > developed knowledge of the IP infrastructure can be utilized and
> retargeted
> > from their normal usage. Lots of folks are intimately familiar with
> internet
> > protocols. It's the same reason that many many Intranets are TCP/IP based:
> > it allows the releveraging of the existing knowledge base.
> >
> > 4) By using standard internet protocols, there is a wide variety of
> commodity
> > networking hardware available. Of course other protocol can be run on the
> > same hardware, but see #2 above as to why that may not be a good idea.
> > Check out the tiny Crystal Semiconductor 8900A based boards located at
> > www.embeddedethernet.com as a sample. I also found the discussion and
> board
> > here: http://www.seanadams.com/cs8900 quite interesting...
> >
> > 5) By using standard internet protocols, one can get ubiquitous
> connectivity
> > to the largest network on the planet. Instant accessibility from anywhere.
> > (OK this one isn't really that compelling! ;-)
> >
> > I'm pretty sure that using IP protocols wasn't a point of contention.
> There are
> > compelling arguments why it's a good thing. The only debate is whether
> there's
> > a win in embedding some form of TCP into the target so that some standard
> > applications and directly interface with the network connected embedded
> device
> > (i.e. the embedded webserver) or if requiring only UDP/IP and the support
> > protocols are sufficient for implementing an effective device, but
> requiring
> > some amount of heft, in the form of a server or custom written client, on
> > the other side.
>
> I think you are missing the point.  I agree that something based on IP is
> the right way to present a little device to the "outside world", whether
> that is the whole planet or the rest of the office.  At some point, however
> it is implemented, there is going to be a conversion from IP packets to raw
> data inside the tiny device, which is then used to run a D/A, turn on a
> motor, or whatever.  All I'm saying is that this conversion need not happen
> on the tiny device itself.  In many cases the conversion to/from IP can be
> done on a host that already has a full blown TCP/IP stack with all the bells
> an whistles.  Data can then be exchanged between the tiny system and the
> host by private means which can allow the tiny systems to be simpler and
> cheaper.  A simple RS-232 point to point connection between a host and a
> tiny system is certainly simpler and cheaper in hardware and much simpler in
> the firmware.  Now that micros are available that have built in CAN and USB
> hardware, there are other attractive options.

I see where you're coming from. I feel my discussion was right on point with
this. I'm arguing that it's better to releverage the TCP based knowledge and
tools instead of having to implement another data link/transport layer.

BTW if you can run IP on CAN/USB then it would be fine with me as a physical
layer.

With the RS-232, it can easily be used point to point as TCP/IP physical
layer. Ethernet is becoming almost as simple. In the data link PPP/PPPOE
are ideal. But I will admit they are a bit complicated. SLIP is dead dumb
simple: Transmit ASCII character 192 (END) at the beginning and end of each
IP packet. If the END character is in the packet replace it with an ASCII 219
(ESC) followed by an ASCII 220. If the ESC is in the packet, replace it with a
second ESC followed by an ASCII 221. That's all there is.

Neither IP or UDP are particularly heavyweight. Many of the header bytes of
both are the same in every packet.


>
> I guess it comes down to what you consider the overall system you paint the
> black box around.  Especially in cases where a host is already present for
> other reasons, including the host inside the black box that talks TCP/IP to
> the rest of the world can be cheaper and simpler than having each tiny
> system implement TCP/IP.

It makes it a tough call when you get a UDP/IP stack together. Because once
you have it, you can reuse it over and over again knowing that you can
have ubiquitious connectivity and outstanding hardware flexibility underneath.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics