Hi Dale!

I didn't ever think about using IP over serial, but it's a nice idea,
but like you said it kills any easy interface with other systems.
I guess it's better to use something like CAN instead.

I did take a brief look at the Microchip's app note a few weeks ago and
now taking a look at the siteplayer site I start wondering what kind of
hardware I really need to use Ethernet with a PIC? A chip, eg. Realtek
8019? and some kind of filter? and of course a RJ-45 port..
Do I have things somehow clear or am I completely wrong? :)

/Andreas

-----Original Message-----
From: pic microcontroller discussion list
[mailto:PICLIST@MITVMA.MIT.EDU] On Behalf Of Dale Botkin
Sent: den 5 juni 2003 18:25
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]: Home Automation with PICs

On Thu, 5 Jun 2003, Andreas Nyholm wrote:

> I've been thinking of something similar, but using the IP protocol. I
> think that would be a good solution for the future, easy to connect
> other devices to the same server. The biggest problem I found so far
is
> the price, the solutions I found is about $15-20. Or does anyone have
an
> idea how to build a microcontroller that communicates over IP for less
> than $10?

Yep - a PIC16F877 or 18Fxxx with code for IP.  I would suggest UDP for
simplicity, though if you need TCP there are some tricks you can use to
save a lot of code space and complexity.  The tougher/more expensive
part
is Ethernet, if you're going to use that.  You could of course use IP
over
serial or some 2-wire interface or whatever, but that pretty much kills
any easy interface with other systems.  There are solutions for that,
depending on how much effort you want to put into it and how repeateble
it
needs to be.  For example, there have been people who used old ISA bus
Ethernet cards, which works but of course would not be a good way to go
for anything commercial, if that matters to you.

Microchip's got an app note and there are other sources for parts or all
of TPC, UDP, IP, HTTP, SMTP and some other protocols.  IP is not too
tough, the RFCs are all there and it's pretty easy to understand.  In a
lot of cases, you can safely ignore or at least work around some things
that would otherwise present significant challenges.  For example: if
you
know that ALL of your HTTP TCP connections will only consist of one
packet
each way, then your sequence number and packet ordering job just got a
LOT
simpler, didn't it?  There's a lot more.

I played with a really cool little device a while back, an Ethernet web
server on a tiny module (http://www.siteplayer.com/).  While I didn't
end
up using it for what I had planned, I did learn a lot about what could
be
done to cut down on the size of the stack.  They did a lot of stuff I
could have sworn would never work, but in reality do work as long as the
thing doesn't need to be a fully 100% RFC compliant device, which many
don't.  Stuff like:

ARP?  What ARP?  Just send responses back to the MAC address the request
came from, with the same IP address.

Default gateway?  Sorry, no.  See ARP.

DHCP?  Nah.  Just watch for ANY packet with my MAC address (or just
watch
for an ICMP ECHO with my MAC address), take my IP address from that.
Have to trust all your local devices, of course.

Packet reordering?  Nope, not if you can assume all requests coming in
will be in one packet.

If I'm a web server, I can ignore the port number and just treat ANY
incoming TCP packet as an HTTP request...  for that matter, if I'm
serving
tghe same thing every time, like a status web page, I can ignore the
whole
request and just send the stuff.  If the packet wasn't really an HTTP
request, well, tough luck.

The list goes on.  The stack can be pretty compact, if you need to have
it
so.

Dale
--
It's a thankless job, but I've got a lot of Karma to burn off.
Get a PicoKeyer: http://www.hamgadgets.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu