Searching \ for '[PIC]: PIC - TCP/IP / controller / relays / Bit of' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=relay
Search entire site for: 'PIC - TCP/IP / controller / relays / Bit of'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: PIC - TCP/IP / controller / relays / Bit of'
2001\09\03@131611 by Richard

picon face
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.

Thanks for your time!

Richard.

New Zealander trapped in London :( haha


__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\09\03@180829 by Andy Shaw

flavicon
face
I guess the really easy way to do this is the Microchip PICDEM.NET board and
associated software see
www.microchip.com/10/tools/picmicro/demo/pdemnet/index.htm
and
http://www.iosoft.co.uk

I've got one of these and have been using it to experiment with TCP/IP and
the PIC...

Andy

{Original Message removed}

2001\09\04@015531 by Byron A Jeff

face picon face
On Mon, Sep 03, 2001 at 10:14:51AM -0700, Richard wrote:
{Quote hidden}

Well I'll throw in the same two cents I always do on the subject:

I believe the the core power of the Internet and the TCP/IP protocol is in
network routability. Once you get the power to transmit packets over multiple
networks, the vast majority of the power of the Internet becomes available.

So when it comes to small uC projects, I personally believe that IP is the
key enabling technology.

Almost everytime this subject comes up, the context of the PIC based webserver
get bandied about. While cute in concept, I believe that it's not the most
effective use of the PIC's resources. Much of the same functionality can be
achieved with simpler protocols.

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.

I do realize that it will require a bit more effort from the client interfacing
to the project. But all that's really required is a bit of interface from
the user to UDP. This can be done in Java, Perl, or PHP fairly easily. Since
the client (or gateway server if you choose to go that route) has much more
resources, and well tested network stacks, it'll save a heap of work trying to
debug the networking on the PIC.

My students and I have been working on and off on a UDP/IP/SLIP stack with
a linux gateway interface. The interface box is simply to allow for SLIP to
be used. Since SLIP is basically a trivial wrapper over IP, it's real easy
to implement and test on the PIC.

The project has been slow/dormant for the last 9 months or so. I'm hoping that
a new batch of students will pick up the flag. The last significant work was
getting PING working. Extending to and UDP/IP stack shouldn't be that
difficult. Eventually testing with a RS485 multidrop network is on the list
of things to do.

As for hardware there are a couple of good ideas floating around out there:

1: parallel port network pods. Many have Linux drivers from which the protocol
can be gleaned.

2: ISA port cards. Same deal.

3: RTL8139 chips. Have a simple 8 bit mode with some limitations. Real cheap.

4: Serial. This is the option I'm pursuing for now.

Anyway I hope this gives you some things to think about.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@031013 by PeterTiang

flavicon
face
> 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.

Rgds,
Peter Tiang

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@082344 by Byron A Jeff

face picon face
On Tue, Sep 04, 2001 at 03:15:55PM +0800, PeterTiang wrote:
> > 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.

Of course. But it doesn't have to be the extremely complex mechanism that TCP
uses for sequencing, syncronization, and acknowledgement.

By building from the bottom up, it is possible to provide only the minimum
reliability required for the application. Building from the top down with TCP
will require a lot more infrastructure in order to meet TCP's minimum
requirement.

Also the frequency  of many of the potential failures are a function of the
underlaying network. Existing UDP protocols such as DNS, TFTP, and NFS are
generally as reliable as the underlaying networks they operate under.

TCP forces you to code for the absolute worst case. With UDP you can simplify
your assumptions based on the fact that the network is generally reliable.

Finally using UDP it is possible to manage the send/ack relationship from the
client side application, thereby further simplifying the stack that is
implemented on the PIC. With TCP it's not possible to create such an unbalanced
model.

So between utilizing the improved reliability of the underlaying network,
a simplifying assumptions, simpler and more reliable PIC based networking
can be realized. But now you the designer can choose the appropriate level.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@084505 by Dale Botkin

flavicon
face
On Tue, 4 Sep 2001, Byron A Jeff wrote:

> I believe the the core power of the Internet and the TCP/IP protocol is in
> network routability. Once you get the power to transmit packets over multiple
> networks, the vast majority of the power of the Internet becomes available.
>
> So when it comes to small uC projects, I personally believe that IP is the
> key enabling technology.

Couldn't agree more.

> Almost everytime this subject comes up, the context of the PIC based webserver
> get bandied about. While cute in concept, I believe that it's not the most
> effective use of the PIC's resources. Much of the same functionality can be
> achieved with simpler protocols.

Again, agreed.  Actually, I can think of uses for an HTTP interface to a
PIC, but I think a lot could be done without it.

> 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.

UDP definitely is a lot simpler to implement.  Once you have IP/UDP sorted
out, you have the use of DNS, SNMP, and other very useful protocols.  The
only real down side is that most firewalls will summarily deny UDP, so
it's commercial applications are a little limited for some products.

> My students and I have been working on and off on a UDP/IP/SLIP stack with
> a linux gateway interface. The interface box is simply to allow for SLIP to
> be used. Since SLIP is basically a trivial wrapper over IP, it's real easy
> to implement and test on the PIC.

Here's where I have a problem with most existing stacks.  SLIP is OK for
something that will be connected to a dedicated box - like directly wired
to a Linux machine's serial port, for example.  But for applications that
will need Internet dialup connectivity, PPP is pretty much a requirement I
would think.  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've also spent a lot of time writing a "bulletproof" modem dialer, one
that will be able to handle redials, busies, no-answers, modem hangs, etc.
It's NOT pretty and takes an awful lot of code space as it is.  One of
these days I need to rip it completely apart and start from scratch.

Dale
---
Hallo, this is Linus Torvalds and I pronounce Linux as Leennuks.
Hallo, this is Bill Gates and I pronounce 'crap' as 'Windows'.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@085253 by uter van ooijen & floortje hanneman

picon face
> On Tue, Sep 04, 2001 at 03:15:55PM +0800, PeterTiang wrote:
> > > 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.

So the fair comparision would be between a UDP with a repeat/acknowledge
mechanism on top of it, versus a one-frame TCP (which is much simpler than
full-blown TCP!). I would put my bets for simplicity, useability etc. on
one-frame TCP, but is there someone who has implemented both and can comment
on the complexity?

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


2001\09\04@085709 by PeterTiang

flavicon
face
> > > 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
{Quote hidden}

TCP
> uses for sequencing, syncronization, and acknowledgement.
>
> By building from the bottom up, it is possible to provide only the minimum
> reliability required for the application. Building from the top down with
TCP
> will require a lot more infrastructure in order to meet TCP's minimum
> requirement.
>
> Also the frequency  of many of the potential failures are a function of
the
> underlaying network. Existing UDP protocols such as DNS, TFTP, and NFS are
> generally as reliable as the underlaying networks they operate under.
>
> TCP forces you to code for the absolute worst case. With UDP you can
simplify
> your assumptions based on the fact that the network is generally reliable.
>
> Finally using UDP it is possible to manage the send/ack relationship from
the
> client side application, thereby further simplifying the stack that is
> implemented on the PIC. With TCP it's not possible to create such an
unbalanced
> model.
>
> So between utilizing the improved reliability of the underlaying network,
> a simplifying assumptions, simpler and more reliable PIC based networking
> can be realized. But now you the designer can choose the appropriate
level.
>
> BAJ
>

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.

Cheers,
Peter Tiang

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@105608 by Jim

flavicon
face
   "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."

Isn't DNS name look-up implememted via UDP?

How often does that fail?

Correct me if I'm wrong, but every time you 'click'
on a hypertext link - isn't there a UDP name query
that takes place to get the actual IP address?

(Unless I'm just totally misunderstanding Stevens ...)

How often does that fail over the 'net?

Jim



{Original Message removed}

2001\09\04@111918 by Ashley Roll

flavicon
face
Hi Jim,

Your right, DNS is implemented using UDP, however an _individual_ UDP packet
is easily lost. Say your router buffer is full for instance, or a collision
on a link further up stream. Happens all the time.

The important thing is that the DNS services on your computer know that they
can't trust the packet to get there and a replay to come back so they have a
timeout..

If they don't receive a reply within a certain time, they try again. If they
keep failing they try a different DNS server.. eventually if they still
don't get a reply they fail the request and you get a nice message saying
that the connection failed :)

Ash.

---
Ashley Roll
Digital Nemesis Pty Ltd
http://www.digitalnemesis.com
Mobile: +61 (0)417 705 718




> {Original Message removed}

2001\09\04@115808 by jamesnewton

face picon face
True, but there is a higher level (Application?) protocol built in to that.
If the UDP request doesn't get there or the response doesn't get back, the
browser will try again using the secondary DNS server. Have you ever noticed
your browser pausing for a sec between the "resolving 'URL'" message and the
"contacting ###.###.###.###" message?

Some system of dealing with errors must be present, it is just a question of
where, and how thoroughly, you want to do it.

---
James Newton, Admin #3 .....jamesnewtonKILLspamspam@spam@piclist.com
1-619-652-0593 VM 1-208-279-8767 FAX
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2001\09\04@122311 by Byron A Jeff

face picon face
On Tue, Sep 04, 2001 at 09:03:31PM +0800, PeterTiang wrote:

[Doing some editing on the thread]
{Quote hidden}

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.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@123253 by PeterTiang

flavicon
face
Hence,

> >     You probably need the higher layer apps to
> >     implement retry mechanism on top of UDP/IP stack.

   DNS name lookup have a retry mechanism,
   which will attempt your primary DNS,
   failing which the secondary DNS, etc.

   In most cases you'll be getting the DNS
   resolved from local cache.

   So it is misleading to think UDP packet
   does'nt get lost because DNS lookup seems
   a reliable mechanism.

Cheers,
Peter Tiang

{Original Message removed}

2001\09\04@123302 by Herbert Graf

flavicon
face
{Quote hidden}

       But this can always be implemented at the client level. TCP is great for
it's relatively guaranteed delivery but alot of it's features are just
unecessary for a PIC based project. TTYL

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@124631 by PeterTiang

flavicon
face
> > 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.

I believed a commercial product called Emit was
meant to target this segment, not sure whether
it runs UDP on the lean devices.

Rgds,
Peter Tiang

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@140152 by uter van ooijen & floortje hanneman

picon face
> > 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


2001\09\04@151029 by Olin Lathrop

face picon face
> 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.

If you're going to do this, and I think it makes sense, then you're not
stuck using IP at all.  It's probably a lot cleaner and easier to have the
"little" devices talk to a host via USB or something, then have the host do
the full blown TCP, HTTP, and whatever.  Personally, I don't seem much point
in TCP/IP on a PIC, but USB and CAN definitely.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, EraseMEolinspam_OUTspamTakeThisOuTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@155835 by Byron A Jeff

face picon face
On Tue, Sep 04, 2001 at 12:56:49PM -0400, Olin Lathrop wrote:
> > 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.
>
> If you're going to do this, and I think it makes sense, then you're not
> stuck using IP at all.  It's probably a lot cleaner and easier to have the
> "little" devices talk to a host via USB or something, then have the host do
> the full blown TCP, HTTP, and whatever.  Personally, I don't seem much point
> in TCP/IP on a PIC, but USB and CAN definitely.

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.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@172826 by Byron A Jeff

face picon face
On Wed, Sep 05, 2001 at 12:42:18AM +0800, PeterTiang wrote:
{Quote hidden}

They all do. But personally I think it's overrated to focus on the standard
tools when nonstandard ones are easily written. That's why in my first missive
I specifically pointed out three cross platform, network capable frameworks
that could handle interfacing. And if you're willing to have one server
anywhere on the internet, it can trivially serve as a UDP to anything gateway.

With the exception of HTTP, the protocols are only really good for testing.
Once you want to do something in the production domain, no matter the scale,
of production, you'll end up writing a custom client application anyway.

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.

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.

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.

Now I agree that you're going to have to build at least a trivial applications
protocol on top of UDP. SNMP/RMON looks particularly exciting considering the
type of environment we expect networked pics to operate in: control/info
gathering with sporadic interactions.

Just some more thought on it...

>
> 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.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@173703 by Byron A Jeff

face picon face
On Tue, Sep 04, 2001 at 07:43:33AM -0500, Dale Botkin wrote:
> On Tue, 4 Sep 2001, Byron A Jeff wrote:
>
[ Agreement on IP and TCP complexity ... ]

> > 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.
>
> UDP definitely is a lot simpler to implement.  Once you have IP/UDP sorted
> out, you have the use of DNS, SNMP, and other very useful protocols.  The
> only real down side is that most firewalls will summarily deny UDP, so
> it's commercial applications are a little limited for some products.

That sucks...

>
> > My students and I have been working on and off on a UDP/IP/SLIP stack with
> > a linux gateway interface. The interface box is simply to allow for SLIP to
> > be used. Since SLIP is basically a trivial wrapper over IP, it's real easy
> > to implement and test on the PIC.
>
> Here's where I have a problem with most existing stacks.  SLIP is OK for
> something that will be connected to a dedicated box - like directly wired
> to a Linux machine's serial port, for example.

Which happened to be my target. Running completely in a vacuum wasn't a
requirement.

>  But for applications that
> will need Internet dialup connectivity, PPP is pretty much a requirement I
> would think.

Absolutely.

> 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.

>
> I've also spent a lot of time writing a "bulletproof" modem dialer, one
> that will be able to handle redials, busies, no-answers, modem hangs, etc.
> It's NOT pretty and takes an awful lot of code space as it is.  One of
> these days I need to rip it completely apart and start from scratch.

How about a cell phone packet interface? More costly but maybe doable???

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@173713 by Andy Shaw

flavicon
face
Folks I notice that iosoft (http://www.iosoft.co.uk) have now added an updated
version of the PICDEM.NET software that supports UDP as well as TCP. They
have some info on the site about using this to transport video frames from a
simple frame grabber. Looks interesting!

Andy

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@212120 by Kevin J. Maciunas

flavicon
picon face
On 04 Sep 2001 12:56:49 -0400, Olin Lathrop wrote:
> > 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.
>
> If you're going to do this, and I think it makes sense, then you're not
> stuck using IP at all.  It's probably a lot cleaner and easier to have the
> "little" devices talk to a host via USB or something, then have the host do
> the full blown TCP, HTTP, and whatever.  Personally, I don't seem much point
> in TCP/IP on a PIC, but USB and CAN definitely.
>
>

There is a third way - make use of something which already does this.
The "Siteplayer" device (http://www.siteplayer.com) implements TCP/IP,
HTTP and has an ethernet on board.  The intended use is to provide a web
SERVER on the siteplayer device which talks to your embedded application
via a simple serial protocol.

I hasten to add, I've not yet got around to playing with one, etc etc.
I have no association with the company, blah blah blah...

Implementing TCP on a PIC16F877, is not a wonderful experience.  I've
done this, and the code for the complete TCP/IP (actually it ran SLIP,
so there was RS-232 stuff in there too) and HTTP service took most of
the available memory.  The company I did this for was pretty pleased,
but the implementation was pretty horrid.  What I essentially
implemented was functionally equivalent to the siteplayer device and
about one tenth as fast, and many times the $US29.95 (right now) or so
the siteplayer thing costs.  I would, personally, NEVER do it again.

My $0.02
/Kevin
--
Kevin J. Maciunas           Net: kevinspamspam_OUTcs.adelaide.edu.au
Dept. of Computer Science   Ph : +61 8 8303 5845
University of Adelaide      Fax: +61 8 8303 4366
Adelaide 5005               http://www.cs.adelaide.edu.au/~kevin
SOUTH AUSTRALIA

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@220757 by Dale Botkin

flavicon
face
On Tue, 4 Sep 2001, Byron A Jeff wrote:

> With the exception of HTTP, the protocols are only really good for testing.
> Once you want to do something in the production domain, no matter the scale,
> of production, you'll end up writing a custom client application anyway.

How do you figure?  With UDP you can implement a very simple protocol.
Once you have a "send UDP packet" subroutine or function, you use it just
like anything else.

> 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.

Now take it a step further.  Say you want to monitor X number of remote
stations, but you loathe writing PC code, or don't have the time, or just
don't wanna.  Or maybe it needs to talk to an AS/400 or a UNIX machine you
know nothing about.  OK, fine, send your data as SNMP traps -- just a UDP
datagram formatted the proper way -- and now you can use whatever SNMP
monitoring software you want, like HP OpenView or CMU-SNMP or Tivoli or
whatever.  Now you're leveraging existing software to make your product
far more useful.

> 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...

Dale
--
Hallo, this is Linus Torvalds and I pronounce Linux as Leennuks.
Hallo, this is Bill Gates and I pronounce 'crap' as 'Windows'.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\04@220804 by Dale Botkin

flavicon
face
On Tue, 4 Sep 2001, Byron A Jeff wrote:

> > UDP definitely is a lot simpler to implement.  Once you have IP/UDP sorted
> > out, you have the use of DNS, SNMP, and other very useful protocols.  The
> > only real down side is that most firewalls will summarily deny UDP, so
> > it's commercial applications are a little limited for some products.
>
> That sucks...

Depends on the application.  If it's primarily an enterprise kind of
thing, like monitoring and control, it's usually all on one side fo the
firewall OR the InfoSec folks can build a rule set to permit the traffic
you need.

{Quote hidden}

Yeah.  Parallel port interconnection isn't something I'd use, since
parallel ports are an endangered species anyway, and you're limited to
short distances or custom cables.

Dale
--
Hallo, this is Linus Torvalds and I pronounce Linux as Leennuks.
Hallo, this is Bill Gates and I pronounce 'crap' as 'Windows'.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\05@065420 by PeterTiang

flavicon
face
Looking at the TCP/IP Lean PIC code,
I believe it's single-segment TCP.

Rgds,
Peter Tiang


----- Original Message -----
From: "wouter van ooijen & floortje hanneman" <@spam@wfKILLspamspamXS4ALL.NL>
To: <KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Wednesday, September 05, 2001 1:35 AM
Subject: Re: [PIC]: PIC - TCP/IP / controller / relays / Bit of fun!


{Quote hidden}

--
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


2001\09\05@082511 by Byron A Jeff

face picon face
On Tue, Sep 04, 2001 at 08:54:33PM -0500, Dale Botkin wrote:
> On Tue, 4 Sep 2001, Byron A Jeff wrote:
>
> > > 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.
>
> Yeah.  Parallel port interconnection isn't something I'd use, since
> parallel ports are an endangered species anyway, and you're limited to
> short distances or custom cables.

Clarification: parallel port ethernet cards. Plug them into a parallel port
interface, get Ethernet out the back. I bought a couple to experiment with,
but they've been sitting in my junkbox for about a year now...

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


2001\09\05@082519 by Byron A Jeff

face picon face
On Tue, Sep 04, 2001 at 08:49:57PM -0500, Dale Botkin wrote:
> On Tue, 4 Sep 2001, Byron A Jeff wrote:
>
> > With the exception of HTTP, the protocols are only really good for testing.
> > Once you want to do something in the production domain, no matter the scale,
> > of production, you'll end up writing a custom client application anyway.
>
> How do you figure?  With UDP you can implement a very simple protocol.
> Once you have a "send UDP packet" subroutine or function, you use it just
> like anything else.

Dale, I think I took out too much context. The statement preceeding mine was

- 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.

So the protocols I was referring to were the specific TCP based application
protocols connected to the applications above.

so s/the protocols/these TCP application protocols/

{Quote hidden}

BINGO! That's why it's a winner with just a UDP/IP stack.

>
> Now take it a step further.  Say you want to monitor X number of remote
> stations, but you loathe writing PC code, or don't have the time, or just
> don't wanna.  Or maybe it needs to talk to an AS/400 or a UNIX machine you
> know nothing about.  OK, fine, send your data as SNMP traps -- just a UDP
> datagram formatted the proper way -- and now you can use whatever SNMP
> monitoring software you want, like HP OpenView or CMU-SNMP or Tivoli or
> whatever.  Now you're leveraging existing software to make your product
> far more useful.

That's the hook I've been looking for! I knew there was a way to utilize SNMP
for this activity. I need to take a closer look...

{Quote hidden}

Dale. Dale? DALE!!! ;-)

We are agreeing! That's exactly the point I was making.

{Quote hidden}

Reliability, Autonomy, Reduced power consumption. Take your pick. Let's put it
in the context of a real problem:

Suppose you want to automate some of the functions of a remote cabin. The
usual intrusion, flood, and cold alarms, along with controls for the lights,
heater,etc. A very typical X10 type setup. But many, like myself, are not
truly comfortable with X10's open loop design and their sometimey controls.
And as PIC enthusiasts, the challenge is interesting. As a final hitch, we're
functioning on limited solar power. For the sake of argument say that two
way satellite Internet is available.

Now a PC really doesn't have to be on the premesis. A Linksys style mini
router would be more than sufficient to interface the house to the network.
We also have a minimum of two access methods: An offsite server, or a direct
client program. Without the PC onsite, the overall system uptime should be
higher. But truth be told I'd probably run a 486 Linux box that boots into a
ramdisk instead of the Linksys, simply because I have the hardware laying
around.


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


2001\09\05@090705 by Olin Lathrop

face picon face
> 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.

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.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinTakeThisOuTspamembedinc.com, http://www.embedinc.com

--
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


2001\09\05@102404 by Dale Botkin

flavicon
face
On Wed, 5 Sep 2001, Byron A Jeff wrote:

> > Yeah.  Parallel port interconnection isn't something I'd use, since
> > parallel ports are an endangered species anyway, and you're limited to
> > short distances or custom cables.
>
> Clarification: parallel port ethernet cards. Plug them into a parallel port
> interface, get Ethernet out the back. I bought a couple to experiment with,
> but they've been sitting in my junkbox for about a year now...

Oh!  I'd forgotten about those completely.  Are they still made?  I don't
recall ever seeing anything documented on them, though I suppose the Linux
driver source code would tell one all one needs to know.

Dale
--
Hallo, this is Linus Torvalds and I pronounce Linux as Leennuks.
Hallo, this is Bill Gates and I pronounce 'crap' as 'Windows'.

--
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


2001\09\05@120744 by Olin Lathrop

face picon face
> Suppose you want to automate some of the functions of a remote cabin. The
> usual intrusion, flood, and cold alarms, along with controls for the
lights,
> heater,etc. A very typical X10 type setup. But many, like myself, are not
> truly comfortable with X10's open loop design and their sometimey
controls.
> And as PIC enthusiasts, the challenge is interesting. As a final hitch,
we're
> functioning on limited solar power. For the sake of argument say that two
> way satellite Internet is available.

Good, now we have a reasonable problem statement.  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.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spamBeGoneolinspamBeGonespamembedinc.com, http://www.embedinc.com

--
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


2001\09\05@124138 by Byron A Jeff

face picon face
On Wed, Sep 05, 2001 at 09:18:44AM -0500, Dale Botkin wrote:
> On Wed, 5 Sep 2001, Byron A Jeff wrote:
>
> > > Yeah.  Parallel port interconnection isn't something I'd use, since
> > > parallel ports are an endangered species anyway, and you're limited to
> > > short distances or custom cables.
> >
> > Clarification: parallel port ethernet cards. Plug them into a parallel port
> > interface, get Ethernet out the back. I bought a couple to experiment with,
> > but they've been sitting in my junkbox for about a year now...
>
> Oh!  I'd forgotten about those completely.  Are they still made?

Not sure. You can still find them at auctions here and there.

> I don't
> recall ever seeing anything documented on them, though I suppose the Linux
> driver source code would tell one all one needs to know.

Exactly.

But after checking out the Crystal Semiconductor 8900A there may be little need
to follow up on it. The chip runs about $12 apiece. After adding a 20Mhz
crystal and some magnetics, you have a ethernet card that can be accessed
by a PIC in 8 bit mode using only 14-16 pins. And I think with just a little
bit of thought and an extra chip (specifically an 74HCT573) it may be possible
to get the interface down to 10 bits.

The only problem is that it's a 100 pin TQFP package. But after reading a
couple of articles on the part, it still looks like a winner. Check out
these two resources:

http://www.embeddedethernet.com

This is a site that has a standalone board for the CS8900A. Apparently three
boards can be ordered from EasyPCB for $60.

http://www.chipcenter.com/circuitcellar/october00/pdf-1000/c1000fepdf.pdf

This Fred Eady article describes an ethernet development board. It uses a
16F877 for the engine and a CS8900A for the ethernet interface. Fred has a
multiarticle series describing the construction and development of this board.

From the looks of it a really small board can be put together by a hobby user
in the $40-$50 range. I'd be real interested in hearing if anyone knows of a
TQFP adapter to throughhole that could be obtained at a reasonable price.

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


2001\09\05@130912 by Byron A Jeff

face picon face
On Wed, Sep 05, 2001 at 08:54:51AM -0400, Olin Lathrop wrote:
{Quote hidden}

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


2001\09\05@133019 by Byron A Jeff

face picon face
On Wed, Sep 05, 2001 at 10:35:44AM -0400, Olin Lathrop wrote:
> > Suppose you want to automate some of the functions of a remote cabin. The
> > usual intrusion, flood, and cold alarms, along with controls for the
> lights,
> > heater,etc. A very typical X10 type setup. But many, like myself, are not
> > truly comfortable with X10's open loop design and their sometimey
> controls.
> > And as PIC enthusiasts, the challenge is interesting. As a final hitch,
> we're
> > functioning on limited solar power. For the sake of argument say that two
> > way satellite Internet is available.
>
> Good, now we have a reasonable problem statement.

Glad to help...

{Quote hidden}

Olin,

Everytime I hear you say TCP/IP I get the impression that you're talking
about a physical interface. Is that the case.

Here's my first crack:

Similar setup using multidrop RS-485 and the onboard UART. Using a low power
transceiver up to 128 devices can attach to the same line. Use SLIP as a
datalink.

I too would implement a RS-485 to ethernet bridge that doesn't even need to
be smart enough to filter packets because the router it connects to will take
care of that.

My firmware costs will be higher. It'll need to have a minimal collision
resolution scheme that CAN implements in hardware. It would also have to have
a minimal IP/UDP transceiver stack. Finally as an applications stack I think
I'm now enamored with Dale's SNMP alerts.

But my bridge will be trivial. It just byte stuffs ethernet IP packets to
convert to SLIP, and strips SLIP packets to convert to ethernet. If I wanted
real sophistication I'd do port mapping so that each port of the single IP
on the ethernet side would map to a different IP address on the RS485 network
side. That way each device would get its own IP in the internal net, but would
map to a port on a single IP going out. Primitive Net Address Translation.

It would be more software development. I don't deny that. But I can then take
that same stack and reuse it in each and every networking project from now
to eternity. Swap in a CS8900A based ethernet module and it can run on any
standard network. PPP and a modem, it'll dialup and communicate. PPPOE or DHCP
and it can function with any standard cable or DSL box.

The possibilities are endless.

And BTW: you'd end up building a minimal IP/UDP stack for your bridge anyway.
And a second stack for CAN.

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.

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


2001\09\06@120740 by Olin Lathrop

face picon face
> Everytime I hear you say TCP/IP I get the impression that you're talking
> about a physical interface. Is that the case.

Actually my main issue is with the considerably higher firmware complexity
required to implement TCP/IP versus some private protocol that is explicitly
intended to be easy.

> My firmware costs will be higher.
> ...
> But my bridge will be trivial.

Exactly.  I see this as backwards.  I would rather have the one be complex
and the many be simple.

> It would be more software development. I don't deny that.

I'm not as concerned about development as the minimum requirements placed on
the tiny units.  With TCP/IP, many of the small micros are just not big
enough for the job, but just about any of them could support a RS-485
network with a dumb protocol, or talk to a CAN chip.

> 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.

The RS-485 protocol layer in the 16C77 I mentioned earlier takes a small
fraction of that.  CAN is even simpler.  The hardware does all the ACK/NACK,
error control, and interpreting the bit stream as packets.  It can then also
filter the address in the packet so that the firmware only gets bothered
about packets that it needs to deal with.  CAN was specifically designed for
lightweight nodes on an inexpensive local network.  The original purpose was
to reduce the cost of wiring in automobiles.  For example, it's cheaper to
run power and CAN all around the car with a little silicon at each node than
to run separate wires to each thing being controlled.  In other words, the
point behind CAN is that the transistors at the a rear blinker are cheaper
than the copper power wire to it.  TCP would be ***WAY*** overkill for this.
Fortunately, a lot of little local control applications can benefit from the
large volumes of the automobile market.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, TakeThisOuTolinEraseMEspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\09\06@170404 by Byron A Jeff

face picon face
On Thu, Sep 06, 2001 at 09:52:41AM -0400, Olin Lathrop wrote:
> > Everytime I hear you say TCP/IP I get the impression that you're talking
> > about a physical interface. Is that the case.
>
> Actually my main issue is with the considerably higher firmware complexity
> required to implement TCP/IP versus some private protocol that is explicitly
> intended to be easy.

I may agree with TCP, which is what I've been arguing from the beginning of
the thread. However UDP and IP's complexity are several orders of magnitude
lower.

Here is the IP header, shamelessly borrowed from RFC 791:


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Version|  IHL  |Type of Service|          Total Length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Identification        |Flags|      Fragment Offset    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Time to Live |    Protocol   |         Header Checksum       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Source Address                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Destination Address                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Options                    |    Padding    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Example Internet Datagram Header

The version, IHL (header length), Type, Time to Live, Protocol, flags, Fragment
offset and source addresses are all fixed. The ID field is a simple 16 bit
counter. The checksum is the 1's complement of the sum of the packet.
Options are of course optional.

Now on to UDP:

                 0      7 8     15 16    23 24    31
                +--------+--------+--------+--------+
                |     Source      |   Destination   |
                |      Port       |      Port       |
                +--------+--------+--------+--------+
                |                 |                 |
                |     Length      |    Checksum     |
                +--------+--------+--------+--------+
                |
                |          data octets ...
                +---------------- ...

There is not an obligation to compute the checksum for UDP. It can be sent as
a zero field. Same for the source port.

So to send a datagram All that must be set is the Destination IP and port,
the length in the IP and UDP header, increment the IP ID field,
and the IP checksum computed.

So unless you are using a packet format with no address, no checksum, and
no length information, I cannot see the "considerably higher" firmware
complexity you allude to above.


>
> > My firmware costs will be higher.
> > ...
> > But my bridge will be trivial.
>
> Exactly.  I see this as backwards.  I would rather have the one be complex
> and the many be simple.

But I really think that it's worth the investment because the payoff is so
huge.

>
> > It would be more software development. I don't deny that.
>
> I'm not as concerned about development as the minimum requirements placed on
> the tiny units.  With TCP/IP, many of the small micros are just not big
> enough for the job, but just about any of them could support a RS-485
> network with a dumb protocol, or talk to a CAN chip.

After doing the analysis above I'm positive that UDP/IP packets can be pushed
from a 12C508. The headers have at maximum 18 bytes of dynamic overhead and
that's if the source and destination IP addresses and ports are all
configurable. With a fixed source IP, destination port, ID field, and computing
the length in place, that overhead is reduced to 8 bytes (4 for the dynamic
destination IP, 2 for the length and two for the checksum).

The only limitation is the data. And you'd with a 4 byte window of the same
limitation with any other protocol. So it's a wash.


{Quote hidden}

But you cannot connect those devices directly to a TCP/IP network without
a gateway. It's apparent that you do not see the value add of that.
Personally knowing that the far end of a network connection can be both
remote and completely tested with a bunch a well known, debugged software,
is a value that just cannot be overstated enough.

The world is fast becoming a place where a computing devices that isn't
internet connected is a useless computing device. And I strongly feel that
duplicating networking effort is a waste of valuable resources.

I really don't buy the "protocol is too heavyweight to run on small
hardware" argument. Up to 70 percent of the header can be hardcoded with
no loss of functionality.

{Quote hidden}

It's going to be a protocol stack no matter how you slice it. You will have
a hardware device driver to communicate with the hardware, you will have
a data link protocol that describes the format of the data on the line,
you will have some type of addressing scheme to differentiate on node from
another, and you will have some application specific data embedded in
your packets. Unless the protocol is point to point, you're stuck with
these elements. TCP/IP adds two additional layers: IP which expands
addressing so that it's routable, and UDP so that in theory multiple
applications ports can be addresses. But with the small concession of
a single application port, the entire UDP header can be hardcoded out of
existence.

And the point I'll keep pounding is that by speaking UDP/IP it makes you device
just like every other device on the net. And without the need on intervening
hardware. Your model cannot run without a server. There's no possibility of
a standalone configuration. Plus you have to implement two incompatible
protocols. You cannot leverage the tons of tools, software, and expertise
that already exists.

{Quote hidden}

Ouch! Now I see why you are banging away at the complexity of the stack.
The last time my students were working on this project, they had implemented
a PING/SLIP stack with a hardcoded ping packet. They started with Fr. Tom's
UART code (and outstanding piece of work!) and coded a jump table to get
and transmit the bytes. It all comes in under 256 bytes and it pinged just
fine. So I'm finding 5k hard to swallow.

BTW I'm writing this as much as a design document to myself as a response
to you. Since it'll be archived, when I get around to actually building
these things I'll already have my thoughts in a semi-coherent form.

If we limit ourselves to serial hardware in the beginning then the only
protocols we must support are UDP, IP, and ping. For simplicy I'll use
SLIP as the data link.

Transmit: Much of the headers are hard coded. Implement the header as a
jump table. For the dynamic elements use a goto instead of the retlw. The
goto goes to code that pulls the appropriate dynamic value from RAM and
transfers into W. The application will have to fill the dynamic values (length,
destination IP, pointer to data) then call. SLIP byte stuffing will be done
after the jump table value is obtained. The pointer to the data is stuffed
into FSR and a FSR/INDF loop is used to transmit. Can be interrupt driven
but then will require a flag to inform the application when another packet
can be transmitted.

Receiver: Probably start out syncronous so that the application has to request
a packet. May rethink later. Biggest design decision is to invest temp ram
in receiving the header or coming up with a clever scheme where only the
dynamic elements are stored. Something along the lines of a bit table
with a double jump table, the first gets the byte position of the next
received character, the second picks the bit out of the position byte.
So it would only take 4 bytes of table to represent the keep/throw away
status of the bytes of the header. In either case the kept data is stored
sequentially in a buffer which is returned to the app when received. Normal
SLIP END/ESC translation is done upon receipt.

I would gag if this were more than 512 bytes of code and 28 bytes of header
RAM. The data packet size of course will be constrained by the amount of RAM
available on the target.

>
> The RS-485 protocol layer in the 16C77 I mentioned earlier takes a small
> fraction of that.  CAN is even simpler.  The hardware does all the ACK/NACK,
> error control, and interpreting the bit stream as packets.

But that's orthogonal to any network/transport layers. As I said before I'd
be perfectly happy to run UDP/IP on top of CAN. I could of course say
exactly the same thing about ethernet in terms of packes and error control.

>  It can then also
> filter the address in the packet so that the firmware only gets bothered
> about packets that it needs to deal with.

That can be done with 9 bit serial and ethernet. Those are all data link
issues that sits below the IP and UDP payers. And IP/UDP packets can be
delivered over each and every one of them.

> CAN was specifically designed for
> lightweight nodes on an inexpensive local network.  The original purpose was
> to reduce the cost of wiring in automobiles.  For example, it's cheaper to
> run power and CAN all around the car with a little silicon at each node than
> to run separate wires to each thing being controlled.  In other words, the
> point behind CAN is that the transistors at the a rear blinker are cheaper
> than the copper power wire to it.  TCP would be ***WAY*** overkill for this.
> Fortunately, a lot of little local control applications can benefit from the
> large volumes of the automobile market.

But it's apples and gorillas for the discussion we're having. Personally
I can care less about the data link and physical media. The only argument
I've made is that your get ubiquity by delivering UDP/IP/ICMP packets to
the target. You're focus is how nodes are connected. Mine is the data
that delivered to the nodes via the interface. And I believe that the
firmware complexity for a UDP/IP/ICMP stack is several orders of magnitude
less than you think it is.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\09\07@085812 by 8859-1?Q?=C5ke_Hedman?=

flavicon
face
This discussion is really interesting!

I have been dreaming about intelligent nodes to do simple functionality in
my homer and/or office. The PIC and the AVR processors made it all possible.
TCP/IP would have been nice for nodes but complexity and extra circuit costs
raised the price for the nodes. A low node price is probably the most
important factor possibly after ease of installation.

My first attemt was to use a 485 and build a simple yet capable system with
them (http://eda.sourceforge.net/mumin/) One important thing for me was that
a node should indentify itself when it is installed in the network. Also it
should be able to draw some power from the wires. This is solved in
M.U.M.I.N. To keep it really simple all nodes are seen as a device with a
set of registers and the protocol is built around this. This is the same
abstraction level that is used for IC-circuits.

Today I can still see some use for M.U.M.I.N. nodes but low speed USB nodes
with the same IC abstraction model is more often the best choice. Also
Dallas 1-wire is a good choice for relays/switches and other very low priced
pieces. The 1-wire net fullfill all of my original desig goals. One bad
thing is that there is pretty hard to implement 1-wite in software. Anyone
tried it?

So for a smart House/Office solution one end up with several layers. TCP/IP
for room or complex control situations. 1-wire, USB, something like
M.U.M.I.M., LIN (http://www.lin-subbus.org/) for the Last Inch solutions.

The CAN people must have come to the same solution as they developed LIN as
there cheap control net for simple things in cars and other rigid
environments. This may be the path to take. It is perfect for the PIC and
the AVR controlers.

If the control situation can bear the cost use TCP/IP. Its rock stable and
nice to work with. If price is a concerne don't....

/Ake

==============================================
Åke Hedman, CC-Systems AB, Box 83, 822 22 ALFTA,Sweden Phone: 46 271 19380 Direct: 46 271 19209 Celluar: 46 70 2314980
Company home: http://www.cc-systems.com
Personal home: http://www.eurosource.se/akhe
Projects: http://eda.sf.net  http://mumin.sf.net

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\09\07@122200 by Byron A Jeff

face picon face
On Fri, Sep 07, 2001 at 02:46:44PM +0200, Åke Hedman wrote:
> This discussion is really interesting!

Glad you are enjoying it.

>
> I have been dreaming about intelligent nodes to do simple functionality in
> my homer and/or office. The PIC and the AVR processors made it all possible.
> TCP/IP would have been nice for nodes but complexity and extra circuit costs
> raised the price for the nodes. A low node price is probably the most
> important factor possibly after ease of installation.

No disagreement there about keeping costs down. But I'm finding in this thread
that there is a need to shed light on the perception of TCP/IP. The circuit
cost isn't relevant in the discussion because any mechanism that can be used
to deliver data to a node can be used to deliver UDP/ICMP/IP packets. The
only overhead is the size of the header. And as I discussed in my last message
it's quite possible to limit the amount of the header that requires RAM to
a few bytes with some inteliigent programming.
The only concession I'm willing to waver on is the size of the packet on the
wire. But there are several standards of header compression that can be
utilized. Sectrion 5.5 of the following draft paper discusses the possibiliity of UDP/IP compression:

http://www.globecom.net/ietf/draft/draft-thorne-vbi-00.html

But I'm not real concerned about this issue. In fact it then forces the
concept of a gateway that translates the output to full UDP/IP packets.


>
> My first attemt was to use a 485 and build a simple yet capable system with
> them (http://eda.sourceforge.net/mumin/) One important thing for me was that
> a node should indentify itself when it is installed in the network. Also it
> should be able to draw some power from the wires. This is solved in
> M.U.M.I.N. To keep it really simple all nodes are seen as a device with a
> set of registers and the protocol is built around this. This is the same
> abstraction level that is used for IC-circuits.

But what is the significant advantage that you get over delivering UDP/IP
packets, which BTW can carry the payload of an application specific protocol?
If you please leave the physical/data link layer out of the discussion because
any physical media that can deliver packets can be used for UDP/IP.

The tremendous advantage you get by transferring UDP/IP packets are three-fold:

1) Ubiquitious connectivity: Instead of your nodes only being able to talk to
one another, they can communicate to any TCP/IP enabled computer anywhere on
the network.

2) Huge infrastructure base: All of the stacks/software of existing TCP/IP
enabled machines can be used to develop applications and do testing. All the
packet sniffers, libraries, and software that comes standard (or easily
downloaded) on machines can be used in development and testing. Also it
virtually eliminates problems on one end of the link, so that if problems
arise, you can be almost certain it's coming from your project, and not from
the machines on the network your project connects to.

3) Knowledge reusability: You don't have to learn another protocol. You only
need one network/transport protocol to keep track of.

And this list doesn't include all of the standard hardware, because I'm trying
to leave hardware out of the discussion....

>
> Today I can still see some use for M.U.M.I.N. nodes but low speed USB nodes
> with the same IC abstraction model is more often the best choice. Also
> Dallas 1-wire is a good choice for relays/switches and other very low priced
> pieces. The 1-wire net fullfill all of my original desig goals. One bad
> thing is that there is pretty hard to implement 1-wite in software. Anyone
> tried it?

Nope. It's way down on my list of things to do....

>
> So for a smart House/Office solution one end up with several layers. TCP/IP
> for room or complex control situations. 1-wire, USB, something like
> M.U.M.I.M., LIN (http://www.lin-subbus.org/) for the Last Inch solutions.

And that's the problem I see. Multiple hardware layers, multiple different
protocol layers, the requirement of gateways between each hardware interface.
Having to develop protocol stacks for each protocol. No end to end connectivity
without having to add a protocol gateway.

That's complexity to me. Not adding a bit more software in the targets so that
they can utilize the same protocol that everyone else is already speaking.

Ideally I'd like to get my system to 1 protocol stack and at maximum one
hardware gateway. UDP/IP from end to end for the protocol stack and prossibly
a single hardware gateway that converts from serial (EIA-485) to ethernet.
And honestly if I could get a complete ethernet interface down to the $8 range
or so per node, I'd seriously start considering ethernet all the way to the
target.

>
> The CAN people must have come to the same solution as they developed LIN as
> there cheap control net for simple things in cars and other rigid
> environments. This may be the path to take. It is perfect for the PIC and
> the AVR controlers.

As a packet delivery solution? Sure. But the debate are the network, transport,
and possibly the application protocols sitting on top of the hardware....

>
> If the control situation can bear the cost use TCP/IP. Its rock stable and
> nice to work with. If price is a concerne don't....

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?

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\09\07@124801 by Dale Botkin

flavicon
face
On Fri, 7 Sep 2001, Byron A Jeff wrote:

> 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?

I'm most of the way there.  My original target was a 16F84, which has a
little less RAM than the '509.  I was going for TCP/IP with ICMP and HTTP
originally, but later figured out all I needed was UDP, and maybe some
very limited ICMP.  Maybe we should get together and compare notes...  It
may be a while before I can do anything serious with it, though, as we're
moving to a new house and I'm trying to put a couple of other (paying)
projects to bed.  Maybe a nice winter project?

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.
 2. Define a minimum standard hardware environment with some sort of
external memory, used regardless of the situation.  This is a crappy
solution, in my opinion, and defeats a lot of the intent of writing a
general purpose code base for cheapskates and lazy people (like me).
 3. Use #defines and #ifs to build one set of functions that will handle
buffers no matter what you're doing.  You then #define the hardware
environment (maybe CS8900, EEPROM or INTERNAL) and let the compiler
generate the code to meet whatever the situation requires.  This is the
most appealing -- a lot of work up front, but saves tons of work in the
end.

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.

Dale
--
Hallo, this is Linus Torvalds and I pronounce Linux as Leennuks.
Hallo, this is Bill Gates and I pronounce 'crap' as 'Windows'.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body


2001\09\07@133041 by Byron A Jeff

face picon face
On Fri, Sep 07, 2001 at 11:47:31AM -0500, Dale Botkin wrote:
> On Fri, 7 Sep 2001, Byron A Jeff wrote:
>
> > 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?
>
> I'm most of the way there.  My original target was a 16F84, which has a
> little less RAM than the '509.  I was going for TCP/IP with ICMP and HTTP
> originally, but later figured out all I needed was UDP, and maybe some
> very limited ICMP.  Maybe we should get together and compare notes...  It
> may be a while before I can do anything serious with it, though, as we're
> moving to a new house and I'm trying to put a couple of other (paying)
> projects to bed.  Maybe a nice winter project?

Maybe...

{Quote hidden}

Personally I'd like to see straight assembly. ASM can be integrated into
higher level languages, can run standalone, and doesn't lock users into a
particular environment. For example I'm planning on resurrecting my NPCI
programming language in the near future. Wouter's JAL could definitly benefit.
Then there's the Basic crowd. The only common denominator is ASM. Think
ASM library with whichever high level interface required...

{Quote hidden}

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.

Remember this is IP. There's no obligation to accept any packet. You can just
drop it on the floor with no repercussions. Normally as a courtesy you can
send back a IMCP message indicating that the packet was dropped and why. We
can implement MTU path discovery and let the other end know that we do not
accept packets larger than say 64 bytes. And nearly every IP stack on the
planet will comply.

>   2. Define a minimum standard hardware environment with some sort of
> external memory, used regardless of the situation.  This is a crappy
> solution, in my opinion, and defeats a lot of the intent of writing a
> general purpose code base for cheapskates and lazy people (like me).

Nope. Adding components to the node just doesn't work.


>   3. Use #defines and #ifs to build one set of functions that will handle
> buffers no matter what you're doing.  You then #define the hardware
> environment (maybe CS8900, EEPROM or INTERNAL) and let the compiler
> generate the code to meet whatever the situation requires.  This is the
> most appealing -- a lot of work up front, but saves tons of work in the
> end.

Nope. This forces integration of the driver with the stack. Also as specified
it's language dependent. And what do you do if you need to build a gateway
and you need multiple interfaces.

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.

>
> 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.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body


2001\09\07@162245 by dale

flavicon
face
> On Fri, 7 Sep 2001, Byron A Jeff wrote:
>
> Personally I'd like to see straight assembly. ASM can be integrated into
> higher level languages, can run standalone, and doesn't lock users into a
> particular environment. For example I'm planning on resurrecting my NPCI
> programming language in the near future. Wouter's JAL could definitly benefit.
> Then there's the Basic crowd. The only common denominator is ASM. Think
> ASM library with whichever high level interface required...

I know the argument, and I can't say I disagree...  but I simply don't do assembler any more.  If I complete this, it will be for me -- if others get some use out of it, fine, but my position is basically if you want it in assembler you're going to have to write it yourself.  8-)  I simply don't have the time or desire to re-learn assembly to the point I could write something of this level of complexity without it looking like a joke.

{Quote hidden}

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.

> 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.

Gotcha.  I was just not thinking about the driver as containing some crucial bits of the code, which they obviously should.

> > 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.

Hmmm.  I can drop assembly code into my C programs, too bad you can't drop C code fragments into your assembler!  8-)

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\09\08@085425 by Peter L. Peres

picon face
I think that I'd try to put the heavy brainy side of TCP/IP maybe combined
with a small WWW and WAP server on a SBC running Linux with ether and/or
PPP capability and four serial ports and I'd implement TTL level serial
networks using MODBUS or something like that to the actual devices. Maybe
even I2C. Such a SBC starts at $150 or so and probably less in some qty.

The embedded web server would allow bidirectional control (read status and
interact) even using a cellular phone with WAP from pretty much anywhere,
and could implement enough security to keep any hackers at bay (even some
govt. agencies probably).

Peter

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu


2001\09\08@161650 by Byron A Jeff

face picon face
On Fri, Sep 07, 2001 at 03:21:31PM +0000, Dale Botkin wrote:
> > On Fri, 7 Sep 2001, Byron A Jeff wrote:
> >
> > Personally I'd like to see straight assembly. ASM can be integrated into
> > higher level languages, can run standalone, and doesn't lock users into a
> > particular environment. For example I'm planning on resurrecting my NPCI
> > programming language in the near future. Wouter's JAL could definitly benefit.
> > Then there's the Basic crowd. The only common denominator is ASM. Think
> > ASM library with whichever high level interface required...
>
> I know the argument, and I can't say I disagree...  but I simply don't do assembler any more.  If I complete this, it will be for me -- if others get some use out of it, fine, but my position is basically if you want it in assembler you're going to have to write it yourself.  8-)  I simply don't have the time or desire to re-learn assembly to the point I could write something of this level of complexity without it looking like a joke.
>

I understand.

{Quote hidden}

Exactly. That way you can switch devices or have multiple devices and they
can use the same upper part of the stack.

> > 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.
>
> Gotcha.  I was just not thinking about the driver as containing some crucial bits of the code, which they obviously should.

>

Right.

{Quote hidden}

Well actually the compiler can translate it info assembly. The problem is that
you get the call interface overhead that C demands for its functions. Not a
killer, just a bit cumbersome for those of us that may not necessarily want
to code in C.

> Hmmm.  I can drop assembly code into my C programs, too bad you can't drop C code fragments into your assembler!  8-)
>

The difference is that nearly every C compiler comes with an assembler, and not
vice-versa.

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?

BAJ

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamspamspamBeGonemitvma.mit.edu


2001\09\09@112148 by Dale Botkin

flavicon
face
On Sat, 8 Sep 2001, Byron A Jeff wrote:

> > 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. >
>
> Well actually the compiler can translate it info assembly. The problem is that
> you get the call interface overhead that C demands for its functions. Not a
> killer, just a bit cumbersome for those of us that may not necessarily want
> to code in C.

There's really not much overhead, at least not with my particular
compiler.  At least it's consistent...  a RAM location or locations are
used to pass parameters back and forth, W is never used for that purpose
as far as I can recall.  The .lst file is not real good for following the
assembly code, but using that along with the disassembled .hex file would
probably work.

> > Hmmm.  I can drop assembly code into my C programs, too bad you can't drop C code fragments into your assembler!  8-)
> >
>
> The difference is that nearly every C compiler comes with an assembler, and not
> vice-versa.

Yah, I was joking...

> 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).  I'd love to use Linux for development, but the simple fact is
the tools I use under Windows are far better than anything currently
available for Linux, and the systems I use for development need to run
Windows -- they're shared with other users and other applications.  CCS
and Hitech both have Linux C compilers out - and the CCS version is even
reasonably priced.

But I'm not here to argue the virtues of C vs ASM, we choose our tools for
the job and according to our own needs.  I think I'll do some
experimentation with writing C code with the express intent of making it
produce easily-interfaced ASM pieces.  Shouldn't be too hard, and the
bonus is you might even be able to squeeze a little more optimization out
of it.

Dale
--
Hallo, this is Linus Torvalds and I pronounce Linux as Leennuks.
Hallo, this is Bill Gates and I pronounce 'crap' as 'Windows'.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\09@183408 by Byron A Jeff

face picon face
On Sun, Sep 09, 2001 at 10:20:21AM -0500, Dale Botkin wrote:
> On Sat, 8 Sep 2001, Byron A Jeff wrote:
>
> > > 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. >
> >
> > Well actually the compiler can translate it info assembly. The problem is that
> > you get the call interface overhead that C demands for its functions. Not a
> > killer, just a bit cumbersome for those of us that may not necessarily want
> > to code in C.
>
> There's really not much overhead, at least not with my particular
> compiler.  At least it's consistent...  a RAM location or locations are
> used to pass parameters back and forth, W is never used for that purpose
> as far as I can recall.  The .lst file is not real good for following the
> assembly code, but using that along with the disassembled .hex file would
> probably work.

So that sounds like a plan.

{Quote hidden}

iI'm not arguing about the merits of assembly vs. HLL. I'd prefer to develop
in HLL to. Perfer it so much that I designed my own language and wrote my own
compiler. I was just arguing that assembly is the least common demoninator
among all languages and development systems and therefore would have the
highest chance for integration into various environments.

And releasing the assembly output of the compiler is quite suffiencent for
the task.

>  I'd love to use Linux for development, but the simple fact is
> the tools I use under Windows are far better than anything currently
> available for Linux, and the systems I use for development need to run
> Windows -- they're shared with other users and other applications.  CCS
> and Hitech both have Linux C compilers out - and the CCS version is even
> reasonably priced.

Well that's good to know. Personally I have other issues with C as a
microcontroller development language, but that's another story.

BTW this wasn't advocacy for switching to Linux either. I was simply stating
that it's my envionment and that developing on it was a requirement for me...

>
> But I'm not here to argue the virtues of C vs ASM, we choose our tools for
> the job and according to our own needs.

Very much agreed.

>  I think I'll do some
> experimentation with writing C code with the express intent of making it
> produce easily-interfaced ASM pieces.  Shouldn't be too hard, and the
> bonus is you might even be able to squeeze a little more optimization out
> of it.

Excellent!

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\11@063033 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,
Byron A Jeff wrote:

>Personally I'd like to see straight assembly. ASM can be integrated into
>higher level languages, can run standalone, and doesn't lock users into a
>particular environment. For example I'm planning on resurrecting my NPCI
>programming language in the near future. Wouter's JAL could definitly
benefit.
>Then there's the Basic crowd. The only common denominator is ASM. Think
>ASM library with whichever high level interface required...

I second that :)

<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.


I'm willing to contribute with ASM coding,


/Tony






Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
"No! Try not. Do, or do not. There is no try.", Yoda
E-mail: RemoveMEtony.kubekKILLspamspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\09\11@085338 by Byron A Jeff

face picon face
On Tue, Sep 11, 2001 at 09:49:32AM +0200, Kübek Tony wrote:
> Hi,
> Byron A Jeff wrote:
>
> >Personally I'd like to see straight assembly. ASM can be integrated into
> >higher level languages, can run standalone, and doesn't lock users into a
> >particular environment. For example I'm planning on resurrecting my NPCI
> >programming language in the near future. Wouter's JAL could definitly
> benefit.
> >Then there's the Basic crowd. The only common denominator is ASM. Think
> >ASM library with whichever high level interface required...
>
> I second that :)

Glad you agree. I think that Dale's suggestion of writing in a high level
language and then cleaning up the assembly generated is workable.

{Quote hidden}

I just don't think that a microcontroller can afford the complexity of
managing TCP. I think it's easier to build up an appropriate protocol from
a base line, instead of having to take a full fledged TCP protocol and start
tearing it down.
{Quote hidden}

If you get a chance go back and take a look at the multiple discussions on this subject. I personally think it raises the complexity to have to deal
with multiple protocols. There should be no serial to UDP gateway, UDP gets
passed through all the way to the target.

BAJ
>
>
> I'm willing to contribute with ASM coding,

Great. Again if you get a chance go and take a look at the partial design
that I posted on how this thing can be built.

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.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\09\12@060904 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,

Byron A Jeff wrote:
<snip>
>If you get a chance go back and take a look at the multiple discussions on
>this subject. I personally think it raises the complexity to have to deal
>with multiple protocols. There should be no serial to UDP gateway, UDP gets
>passed through all the way to the target.

Well I think I was not clear about the exact intentions for this 'device'.
With 'protocol' I meant the formatting of the datagram. Not the serial i/f
protocol.

>Great. Again if you get a chance go and take a look at the partial design
>that I posted on how this thing can be built.

I've re-read some postings but I'm not sure which one you are referring to.

>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.


/Tony



Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
"No! Try not. Do, or do not. There is no try.", Yoda
E-mail: tony.kubekSTOPspamspamspam_OUTflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservSTOPspamspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body


2001\09\13@103052 by Byron A Jeff

face picon face
On Wed, Sep 12, 2001 at 11:59:26AM +0200, Kübek Tony wrote:
> Hi,
>
> Byron A Jeff wrote:
> <snip>
> >If you get a chance go back and take a look at the multiple discussions on
> >this subject. I personally think it raises the complexity to have to deal
> >with multiple protocols. There should be no serial to UDP gateway, UDP gets
> >passed through all the way to the target.
>
> Well I think I was not clear about the exact intentions for this 'device'.
> With 'protocol' I meant the formatting of the datagram. Not the serial i/f
> protocol.

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.



>
> >Great. Again if you get a chance go and take a look at the partial design
> >that I posted on how this thing can be built.
>
> I've re-read some postings but I'm not sure which one you are referring to.

Take a look at this one here:

http://www.infosite.com/~jkeyzer/piclist/2001/Sep/0448.html

remember that the login and password are the name of this list in lowercase.

{Quote hidden}

It seems to use some from of TCP as a transport. I'm targeting smaller at UDP
of course.

BAJ

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2001\09\14@041604 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
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' :)


>Take a look at this one here:
>
>http://www.infosite.com/~jkeyzer/piclist/2001/Sep/0448.html
>
>remember that the login and password are the name of this list in
lowercase.

Check!
( use this site for all my readings )

>It seems to use some from of TCP as a transport. I'm targeting smaller at
UDP
>of course.

Yes, but it has the h/w for ethernet access and that make's it convenient
to test ( for me ). Also the supplied limited TCP 'stack' is coded in c.
And I prefer asm as I stated previosly. Anyway a starting point.

BTW Any idea of 'minimum' h/w requirements ? should the udp stack
be designed to work on 12xxx, 16Fxx, 17xx or even 18xx ? Apart
from limited ram on the smaller chips there are features that could
be very handy in the more advanced pis'c ( such as table functions,
fsr auto increment/decrement etc ). Particulary these could affect code
size/complexity. Personally I feel that an 'baseline' would be 16F87x
something
that has fair amount of ram and features( not saying it's impossible
on 'lesser' pic's only somewhat trickier ). But I'm open for suggestions.


/Tony







Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
"No! Try not. Do, or do not. There is no try.", Yoda
E-mail: EraseMEtony.kubekspamEraseMEflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\14@120448 by Byron A Jeff

face picon face
On Fri, Sep 14, 2001 at 09:56:03AM +0200, Kübek Tony wrote:
{Quote hidden}

Understood. I think that's a step in the right direction.

>
> >It seems to use some from of TCP as a transport. I'm targeting smaller at
> UDP
> >of course.
>
> Yes, but it has the h/w for ethernet access and that make's it convenient
> to test ( for me ).

Agreed.

> Also the supplied limited TCP 'stack' is coded in c.

Is that source freely available? Or is it only in the book?

> And I prefer asm as I stated previosly. Anyway a starting point.
>
> BTW Any idea of 'minimum' h/w requirements ? should the udp stack
> be designed to work on 12xxx, 16Fxx, 17xx or even 18xx ?

All of the above. The only limitation is the amount of RAM available to
buffer and process packets. From my design post I was thinking is may be a
good idea to only retain the relavent parts of the header packets so that
they won't suck up so much RAM.

> Apart
> from limited ram on the smaller chips there are features that could
> be very handy in the more advanced pis'c ( such as table functions,
> fsr auto increment/decrement etc ). Particulary these could affect code
> size/complexity. Personally I feel that an 'baseline' would be 16F87x
> something

That would probably be good. It can by transported in both directions without
too much difficulty.

> that has fair amount of ram and features( not saying it's impossible
> on 'lesser' pic's only somewhat trickier ). But I'm open for suggestions.

Nothing to add here. I plan to get my students' code, which starts with
Fr. Thomas' PICUART code, and make it available. Only implements ping, but
lays out a crude roadmap of where we want to go.

BAJ

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\09\17@105047 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,
first I appologize for the somewhat delayed mail cycle :)
I'm quite busy at the moment ( both on and off work ) and
only reads the list on the keyzer site infrequently.
And as a side note, I'm stunned by the loss of James
on the list. He was the one who got me on the list in the
first place, hope he'll be back.

Anyway to the subject,

Byron A Jeff wrote:
<snip>
>Is that source freely available? Or is it only in the book?

What I understand it's only through the book ( which is
included in the picdem.net kit ) or purchase 'online' from
the iosoft website at: http://www.iosoft.co.uk
Apparently there's an update available which also includes udp.

>All of the above. The only limitation is the amount of RAM available to
>buffer and process packets. From my design post I was thinking is may be a
>good idea to only retain the relavent parts of the header packets so that
>they won't suck up so much RAM.

Agreed. I'll start out with an 16F876 which I have at hand ( and I can use
the ICD ).

<snip>
>Nothing to add here. I plan to get my students' code, which starts with
>Fr. Thomas' PICUART code, and make it available. Only implements ping, but
>lays out a crude roadmap of where we want to go.


Keep me posted :)

I think the next posting should be with a new subject line as we
are drifting towards an specific task.

My plans are to use the linker and make re-locatable code. First start
with the h/w interface for the ethernet access on the picdem.net board,
the proceed into the protocol layer.


I'll post an update within a few weeks ( perhaps sooner )
with my progress. Unfortunately I have litte spare time
in the coming weeks but it seems to ease up after that.

/Tony




Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
"No! Try not. Do, or do not. There is no try.", Yoda
E-mail: @spam@tony.kubek@spam@spamspam_OUTflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...