> Hello all,
>
> I'm looking for some assistance in working on a small PIC project, to keep me out of mischief
> while
> living in London for a few years.
>
> What I wish to create is a PIC TCP/IP based board, that has the ability to be controlled
> entirely by TCP/IP and perhaps rs232 for monitoring/test purposes.  It will control a few 12 volt
> items lets say turn on a led, or a little motor,   and also have the ability to turn on/off a 240v
> load.
>
> So basically the board can be controlled by a standard PC, via TCP/IP or RS232 and it will allow
> you to turn on and off a couple of relays for lights and motors, and also a 240 load on and off.
>
> I also do not believe in reinventing the wheel, so thought I'd put out some feelers to see what
> others have done,  maybe there are some do's and dont's also.  Which particular PIC chip would
> be
> the best to use for this kind of a device...  I'd prefer to use the most powerful PIC chip that I
> can ... powerful being the most universal for future enhancement etc.
>
> I guess I'm kind of looking for a partner to work with remotely, or together on coming up with
> a prototype and to further the ideas and main idea for the devices use.
>
> I have seen a lot of the PIC based web servers, which could possibly be the core TCP/IP and
> control system for the device.  This will be a fun project to get into if anyone is interested.
>

> > API
> > > interface, it's perfect for a PIC to interact on the Internet.
> >
> >     Drawback with UDP is that there is no guarantee
> >     that a datagram will arrive at all, and if it
> >     arrives, a response is not guaranteed.
> >
> >     You probably need the higher layer apps to
> >     implement retry mechanism on top of UDP/IP stack.
>
> Of course. But it doesn't have to be the extremely complex mechanism that

>>>> I believe that the appropriate transport protocol is UDP...
>>>> ... it's perfect for a PIC to interact on the Internet.
>>>
>>>     Drawback with UDP is that there is no guarantee
>>>     that a datagram will arrive at all, and if it
>>>     arrives, a response is not guaranteed.
>>>
>>>     You probably need the higher layer apps to
>>>     implement retry mechanism on top of UDP/IP stack.
>>
>> Of course. But it doesn't have to be the extremely complex mechanism ...
>>
>
> Agreed.
>
> Jeremy Bentham (of TCPIP Lean book fame) did
> managed to squeeze a TCP handler onto a PIC16x76
> though. A quick look at the code, seems like it's
> not too complicated.
>
> Would be interesting if you have many UDP/IP lean
> devices connected to a host which translates
> UDP packets to full TCP packet and vice versa.
> This way, lean devices can enjoy full internet
> connectivity.

> -----Original Message-----
> From: pic microcontroller discussion list
> [PICLISTKILLspamMITVMA.MIT.EDU]On Behalf Of PeterTiang
> Sent: Tuesday, September 04, 2001 03:16
> To: .....PICLISTKILLspam.....MITVMA.MIT.EDU
> Subject: Re: [PIC]: PIC - TCP/IP / controller / relays / Bit of fun!
>
>
> > I believe that the appropriate transport protocol is UDP. With its paper
> thin
> > wrapping over the core IP protocol, and its standard and widely deployed
> API
> > interface, it's perfect for a PIC to interact on the Internet.
>
>     Drawback with UDP is that there is no guarantee
>     that a datagram will arrive at all, and if it
>     arrives, a response is not guaranteed.
>
>     You probably need the higher layer apps to
>     implement retry mechanism on top of UDP/IP stack.

> > > Agreed.
> > >
> > > Jeremy Bentham (of TCPIP Lean book fame) did
> > > managed to squeeze a TCP handler onto a PIC16x76
> > > though. A quick look at the code, seems like it's
> > > not too complicated.
> > >
> > > Would be interesting if you have many UDP/IP lean
> > > devices connected to a host which translates
> > > UDP packets to full TCP packet and vice versa.
> > > This way, lean devices can enjoy full internet
> > > connectivity.
> >
> > I think you have a misconception here. UDP is a completely specified
> standard
> > TCP/IP transport protocol. It's only limitation, if it's considered to be
> a
> > limitation, is that many of the "standard" applications protocols do not
> run
> > on it. Specifically SMTP and HTTP.
> >
> > But a UDP connected device generally has the same connectivity via IP as
> > anything else. The sole exception is the previously pointed out firewalls
> > that may prohibit UDP packets.
> >
>
> U are correct to point this out.
>
> What I meant was that the lean devices can be
> accesed via the Internet using standard apps like a
> browser, telnet, ftp, etc. Which in most cases
> runs on TCP protocol.

> > Actually I'd be much happier with Ethernet, but there you
> > have a requirement for either an ISA bus card (endangered species) or lots
> > of surface mount and some magnetics.  I have a couple of stalled projects
> > because I just haven't found a really good solution for this issue - but
> > then I work with a peculiar set of restrictions, so this is not a problem
> > for a lot of people.
>
> I still think that parallel port cards may have some promise. But they too are
> endangered. USB has quite a bit of complexity, especially at high speeds.
>
> If you're not doing straight serial, there are definitely some dilimmas.

> > > Jeremy Bentham (of TCPIP Lean book fame) did
> > > managed to squeeze a TCP handler onto a PIC16x76
> > > though. A quick look at the code, seems like it's
> > > not too complicated.
>
> Full TCP or single-segment TCP?
>
> Wouter van Ooijen
>
> Van Ooijen Technische Informatica: http://www.voti.nl
> Jal compiler for PIC uC's:  http://www.xs4all.nl/~wf/wouter/pic/jal
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>
>
>

>
> > Again the only exception is HTTP. I'll be the first to admit that having an
> > embedded web server is a sexy concept. However I also firmly believe that
> > the overhead of having both a TCP and HTTP stack embedded doesn't generate
> > an exceptionally profitable result. Especially compared to having a single
> > standard web server that can trivially act as a gateway.
>
> I'm not disagreeing here.  HTTP really doesn't buy you much.  Maybe if
> it's a device a human needs to interact with in real time, great, but
> for many applications you don't need or want something with that kind of
> overhead.  For example -- let's say you want to monitor environmental
> conditions at X number of points.  Your remote PICs do their thing and can
> just send a UDP datagram when they see something that requires attention.
> If you're worried about reliability, keep sending every few seconds until
> you get an acknowledging datagram from the monitoring station.
>
> So why not just use an RS485 network or USB or CAN or something?  Because
> with UDP/IP your remotes can be anywhere, attached via Ethernet, serial,
> modem or whatever.  Hang a dialup modem and PPP stack, and you can dial up
> from Timbuktu and complain about the humidity, and the only thing
> different from your other remotes attached via Ethernet or SLIP is the
> lower layers - the physical interface (Ethernet, RS232, satellite or
> whatever) and the data link (SLIP, PPP, whatever).  Makes problem
> isolation a lot easier and code more modular.

>
> > Another issue is the fact that none of the TCP applications interfaces are
> > too particularly suited to having interactions with a bunch of targets. As a
> > home automation buff, I envision a target environment where every light, fan,
> > power socket, thermostat, and appliance are addressible. And while clearly
> > it could be done as dozens of individual web servers, providing a single
> > unified interface is conceptually a better interface. And once I feel compelled
> > to have a gateway machine, the utility of extending TCP behind it loses its
> > momentum veryt quickly.
>
> Again - why Web servers?  A small horde of remote UDP devices could very
> easily respond to a UDP command or query and send datagrams with their
> status or confirmation.  Use private IP addresses 10.x.x.x, 192.16.x.x,
> etc) and you're all set.  Home automation would be an *IDEAL* application
> for UDP/IP.

>
> > HTTP/TCP may be the correct target for a single standalone unit. But once you
> > start building/integrating in groups, UDP may be a better target then.
>
> Yup.
>
> > > I believed a commercial product called Emit was
> > > meant to target this segment, not sure whether
> > > it runs UDP on the lean devices.
> >
> > Again you have a centralized server out on the net somewhere. Once you conceed
> > that the PIC target isn't functioning as a standalone unit, then the need for
> > TCP is greatly diminished.
>
> Maybe.  I've seen several of these gatewayed proto-IP kind of things where
> the PIC talks to a PC which provides a TCP/IP interface to the rest of the
> world.  If you're going to have to have a PC there anyway, why not just
> use a data acq board and get rid of the PIC anyway?  I don't get it...

> > 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
> > http://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.

> My first take on this
> problem would not be to have each tiny device do some type of IP.  I like
> CAN for this application, because it is much more lightweight for the tiny
> devices.  I could envision running a common bus around the cabin that
> contains the two CAN wires, ground, and low voltage power like +7V regulated
> at the source.  Now each tiny device only needs a 5V regulator, CAN
> interface chip, a CAN-enabled micro, and a crystal and caps as overhead.
> You can't beat that with IP.  One central node supplies the power to the CAN
> bus and acts as the CAN to TCP/IP bridge.  This single node can afford a
> more substantial controller to do a decent TCP/IP implementation.

>
> > But I can then take
> > that same stack and reuse it in each and every networking project AAAA now
> > to eternity.
>
> That logic can be applied in either case.  There's a whole world of
> networking out there that isn't TCP/IP.  I did a RS-485 network for a
> customer a few years ago (16C77) and have re-used the basic concept and much
> of the code for two other projects since then.  CAN would have been perfect
> for the original network, but chips weren't readily available then.

>
> > And BTW: you'd end up building a minimal IP/UDP stack for your bridge
> anyway.
> > And a second stack for CAN.
>
> No, it's not just a bridge.  The protocol or data doesn't just get
> translated from TCP to CAN.  This unit actually runs the TCP server.  It
> receives and interprets requests, some of which it may complete on its own,
> and some of which may require communicating with one or more of the tiny
> devices.  Think of them more as I/O devices connected to the central unit.
> I don't envision anything as complicated on the tiny units as what would
> traditionally be called a "protocol stack".

>
> > Questions: How much hardware/memory do you think it costs to implement
> IP/UDP
> > transmit and receive? How much for CAN? I'm just trying to differentiate
> the
> > "substantial controller" that you quote above.
>
> I don't know about UDP, but there is a company in England somewhere that is
> trying to sell TCP/IP and related software for 18 series PICs.  I asked them
> what their software required if I wanted the PIC to present a single server
> at a single IP address.  My software would implement the server, but theirs
> would provide something equivalent to the Berkeley calls you would need to
> do a TCP/IP server.  I also said their software would have to respond to
> PING itself without bothering or notifying the application.  The answer was
> over 5K instructions, and part of their code needed to be called from a
> regular interrupt.  The phonedroid didn't understand what call stack
> locations were, so he couldn't tell me how many they used up.

>
> What I currently have in mind would be a set of C functions that would
> implement Layer 3 (IP), and another set for each L4 protocol...  so you
> could #include UDP, ICMP, TCP, whatever you happen to need without any
> interdependencies.  The biggest fault I see with the existing
> implementations is that the layers are very tightly integrated; there's
> usually PPP or SLIP code shuffled amongst the IP and TCP stuff, and it's
> got HTTP stuff poured over it and oozing throughthe cracks.  I want to
> separate it into the layers like it should be,and do it without burning a
> bazillion words of program space.

>
> The only real problem I see with this approach?  If you go with Ethernet
> using, say, a Crystal CS89xx chip, you can use all of its buffer space and
> vastly reduce the PIC RAM requirements.  For PPP or SLIP or whatever else
> you don't have that luxury.  I can think of a few ways around this:
>
>   1. Have another set of standard functions to read and write bytes to
> buffer space.  These functions would need to be modified to fit your
> environment - either talk to the Crystal chip or use RAM buffers, or
> external EEPROM or whatever.  Messy and a lot of work.

> >   1. Have another set of standard functions to read and write bytes to
> > buffer space.  These functions would need to be modified to fit your
> > environment - either talk to the Crystal chip or use RAM buffers, or
> > external EEPROM or whatever.  Messy and a lot of work.
>
> Why is this messy? It's known as a device driver. And we're going to have to
> have them. By compartmentalizing them you can switch and swap, mix and match,
> drivers with the stack. DOS packet drivers and the Winsock stack became huge
> precisely because a well definied interface between the driver and the stack
> was available.

> > >   1. Have another set of standard functions to read and write bytes to
> > > buffer space.  These functions would need to be modified to fit your
> > > environment - either talk to the Crystal chip or use RAM buffers, or
> > > external EEPROM or whatever.  Messy and a lot of work.
> >
> > Why is this messy? It's known as a device driver. And we're going to have to
> > have them. By compartmentalizing them you can switch and swap, mix and match,
> > drivers with the stack. DOS packet drivers and the Winsock stack became huge
> > precisely because a well definied interface between the driver and the stack
> > was available.
>
> OK, now I see your point, have a function to fetch things from the buffer, or stuff them into it, and those functions would be part of the device driver and have the same interface regardless of what you're taking to.
>

> > > Maybe I'm being too ambitious, but I want to write a code set exactly
> > > once, that I can re-use without modification anywhere, any time, and
> > > preferably on any processor.
> >
> > Agreed to a point. Personally I think it's more important to have a tool
> > independent implementation that works on the vast majority of PIC products
> > and can me applied in multiple language/development environments than it is
> > to have a single language implementation that can be cross platform. Maybe
> > in the end we'll need both.
>
> For me, a single language approach works for exactly one reason - I'll actually DO it.  I don't write assembler code (used to, but not any more).  I suppose the resulting code could be translated into some pretty generic assembler by someone with the time and patience to do so.
>

>
> > The other issue which is a currently running thread is that I exclusively use
> > Linux for my PIC development. gpasm, which is managed by Craig Franklin and
> > Scott Datallo, is an outstanding piece of work. Wouter Van Ooijen's JAL
> > looks quite interesting as a high level language and has a Linux compiler.
> > My own language, NPCI, has been dormant for about 3 years but I do have a
> > Linux compiler for it. Scott is also working on a C compiler, but it's
> > incomplete. Another piece of the puzzle is that my first driver interface is
> > going to be serial using the built-in UART. Fr. Tom's code is the definitive
> > reference for driving the UART. Guess what it's written in?
>
> Yeah, assembler.  It's a great piece of work.  Fortunately I don't need
> it, I can just use pitc() and getc() and printf() no matter whther I'm
> using a hardware UART or bit-banged serial, or both (which is frequently
> the case).

>
> <snip>
> >Drivers are the way to do. Define a clear robust interface between the
> stack
> >and the driver. Then build all drivers to that spec. You will never ever
> >regret it.
>
> That to..
>
> And in an previous posting he wrote:
>
> <snip>
> >It's starting to look like I'll have to deliver a UDP/ICMP/IP stack on a
> >12C509 before anyone will believe that the cost of the stack isn't that
> >significant. Would anyone like to take a crack at defining a usable
> >specification for such a project?
>
> This is something I was plannning persuing this fall anyway,
> and I already had decided using UDP, nice to hear it wasn't a bad choice.

>
> And since Byron asked how about an serial->udp gateway ;-)
> i.e only the payload is passed through the serial interface.
> The protocol used by the serial device should be (could be) completely
> arbitary. This simple 'gateway' receives an packet from an 'master' on the
> UDP
> it handles all the protocol issues and only delivers the payload on the
> serial
> i/f. Upon reception of data on the serial i/f it assembles an packet
> to be sent to the 'last known host' ( or default ) with the serial data as
> the payload.

>
> >Probably between the three of us we can get a serial/SLIP/IP/UDP stack
> >running in short order. Then we can figure out the clean breaks so that
> >we can separate the physical/data link layers from the network/transport
> >layers.
>
> Yes but it could be a bit tricky as we are in the small resources world,
> here the abstraction is very hard, but should be doable.
>
> For now I'll start plowing through the PICDEM.net board and accompanying
> documentation. Hopefully some enlightment will come out of it.
> Got it a while ago but haven't look at it yet.

> Hi,
>
> Byron A Jeff wrote:
>
> >I'm still confused. Which part of the following stack are you referring to:
> >
> >- Application: Clearly application specific
> >- Transport  : UDP all the time
> >- Internet   : IP all the time
> >- Datalink   : SLIP, PPP, Ethernet, you choose
> >- Physical   : serial, ethernet, wireless, whatever
> >
> >As long as it's UDP and IP, everything can vary. That's my opinion.
>
> Yes, agreed bascilly ( pardon my non native english :) ) I meant
> that the application specific protocol is to be encapsulated into
> udp datagrams by this serial<->udp 'gateway'. For example
> let's say you have an exsisting device using serial comms. This
> new gateway would then sit between the 'old' device and the
> transport layer ( i.e. physical, datalink ). Anyway
> doesn't matter, let's see what uses it can have 'when  it's done' :)