Searching \ for '[EE] Embedded Internet enabling methods: Which?' 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/index.htm?key=which
Search entire site for: 'Embedded Internet enabling methods: Which?'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Embedded Internet enabling methods: Which?'
2000\05\29@040746 by TOM THERON

flavicon
face
Hi there all,

I am anticipating a design for an embedded system, probably 8031-derivative
based,  that will include internet connectivity. My quetion is: what is the
route to take? there are several ways to do it, of which I found the next 3
as possibilities:

1. Using emWare embedded software package, embedding TCP/IP etc. in software
2. Using SEIKO TCP/IP stack chip
3. Using Dallas TINI board

I currently vote for 1st option, because it does not add hardware cost like
2. and also does allow freedom in hardware design, unlike TINI. Also it
seems TINI still presents a lot of problems if you look at their usergroup
list of confusions.

What is your possible experience with any of these methods, or anything else
I do not know of? I'd like to get some real objective comparison, if
possibly somebody worked with more than one method.

What do you think about Java and the future of  emmedded internet? - (this
is the focus of  TINI, I believe)


Regards
Tom

"Designing a future"
MMS Electronic Systems
Tel +27-(0)12-6645696
Fax. +27-(0)12-6642682
Mobile. 0833109007

2000\05\29@101553 by Michael Damon Hopkins

flavicon
face
TOM THERON wrote:
>
> Hi there all,
>
> I am anticipating a design for an embedded system, probably 8031-derivative
> based,  that will include internet connectivity. My quetion is: what is the
> route to take? there are several ways to do it, of which I found the next 3
> as possibilities:
>
> 1. Using emWare embedded software package, embedding TCP/IP etc. in software
> 2. Using SEIKO TCP/IP stack chip
> 3. Using Dallas TINI board
>
> I currently vote for 1st option, because it does not add hardware cost like

I just wish there was a free full TCP/IP implementation out there for
the PIC :)  I dread having to write my own.

I've looked at the previously mentioned implementations, not with too
much detail but they seem to have certain problems.. such as you
mentioned.. hardware based or limited features. I want an API library
where I can use standard library calls like in unix to program my
application.
I don't want to only be able to use certain ports, or have to connect
via a ppp/slip link.. Let me know if you find anything like this..

                       Damon Hopkins

2000\05\29@102008 by Alok Dubey

flavicon
face
i thnk as long as u can make a follow a b8zs std and fig out the hware.. u
need not put in the tcp controller .. but it makes life easier definately
alok

{Original Message removed}

2000\05\29@130633 by Dan Michaels

flavicon
face
Damon Hopkins wrote
>TOM THERON wrote:
>>
>> Hi there all,
>>
>> I am anticipating a design for an embedded system, probably 8031-derivative
>> based,  that will include internet connectivity. My quetion is: what is the
>> route to take? there are several ways to do it, of which I found the next 3
>> as possibilities:
>>
>> 1. Using emWare embedded software package, embedding TCP/IP etc. in software
>> 2. Using SEIKO TCP/IP stack chip
>> 3. Using Dallas TINI board
>>
>> I currently vote for 1st option, because it does not add hardware cost like
>
>I just wish there was a free full TCP/IP implementation out there for
>the PIC :)  I dread having to write my own.
.......


Check out the PIC Internet Appliance article in the latest June issue
of Poptronics mag. In involves both PIC 16C877 or 12C671, and the
firmware is emWare. The article says s.w. is free-free-free. I ordered
the kit [$80] and received it on Saturday - a bag of parts with **1**
page of documentation, saying only goto the site and download the s.w.

http://www.edtp.com

Looks like an easy/cheap way to enter the embedded internet game.

best regards,
Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

2000\05\29@131459 by Spehro Pefhany
picon face
At 10:43 AM 5/29/00 -0600, you wrote:
>
>Check out the PIC Internet Appliance article in the latest June issue
>of Poptronics mag. In involves both PIC 16C877 or 12C671, and the
>firmware is emWare. The article says s.w. is free-free-free. I ordered
>the kit [$80] and received it on Saturday - a bag of parts with **1**
>page of documentation, saying only goto the site and download the s.w.
>
>http://www.edtp.com
>
>Looks like an easy/cheap way to enter the embedded internet game.

Except it isn't really embedded internet, because it requires a
"real" computer to act as a gateway between the LAN and the 'net.

If that works for the application, great, but it's apples and oranges..

Bset regards,


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

2000\05\29@141010 by Damon Hopkins

flavicon
face
Spehro Pefhany wrote:
> Except it isn't really embedded internet, because it requires a
> "real" computer to act as a gateway between the LAN and the 'net.
>
> If that works for the application, great, but it's apples and oranges..
>
> Bset regards,
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Spehro Pefhany --"it's the network..."            "The Journey is the reward"
> .....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
> Embedded software/hardware/analog  Info for designers:  http://www.speff.com
> Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

see I agree.. if you have to have a computer hooked up to the network
then whats the point of the microcontroller.. I'm trying to do things
without a PC not trying to add stuff to a PC :)

                       Damon Hopkins

2000\05\29@141631 by Dan Michaels

flavicon
face
Spehro Pefhany wrote:
>At 10:43 AM 5/29/00 -0600, you wrote:
>>
>>Check out the PIC Internet Appliance article in the latest June issue
>>of Poptronics mag. In involves both PIC 16C877 or 12C671, and the
>>firmware is emWare. The article says s.w. is free-free-free. I ordered
>>the kit [$80] and received it on Saturday - a bag of parts with **1**
>>page of documentation, saying only goto the site and download the s.w.
>>
>>http://www.edtp.com
>>
>>Looks like an easy/cheap way to enter the embedded internet game.
>
>Except it isn't really embedded internet, because it requires a
>"real" computer to act as a gateway between the LAN and the 'net.
>

Good point. Apparently, you can do the other, but you have to
license that s.w. from emWare. The present path looks like a cheap
way to get started in this area.

2000\05\29@162420 by Mark Walsh

flavicon
face
> I am anticipating a design for an embedded system, probably
> 8031-derivative
> based,  that will include internet connectivity. My quetion is:
> what is the
> route to take? there are several ways to do it, of which I found
> the next 3
> as possibilities:
>
> 1. Using emWare embedded software package, embedding TCP/IP etc.
> in software
> 2. Using SEIKO TCP/IP stack chip
> 3. Using Dallas TINI board
>

Since you are familiar with the 8031 may already have tools and code that
can be re-used, you might want to look at the iKit2000 from All-American.
It is a development system with proto-board and software that supports the
new Triscend CSoC (configurable system on chip) 8051 based controller along
with the Seiko S-7600 chip.  I believe the cost is around US$700.  I have an
earlier Triscend development system (without the Seiko chip) and have been
very happy with the time its saved us developing new applications.

http://www.ikit2000.com

Mark Walsh

2000\05\29@163915 by Dan Michaels

flavicon
face
While rooting around the  http://www.linuxdevices.com/
site, I ran across a link to open-source "embedded" webserver:

   New version of available-source embedded webserver -- Bellevue, WA --
   (press release) -- GoAhead Software announced the release of GoAhead
   WebServer 2.1, the latest version of GoAhead's available-source, royalty
   free, standards-based embedded webserver software. WebServer 2.1
   supports embedded Linux applications. According to ...

http://www.goahead.com

Their view, however, appears to mean "embedded" = 32-bit uP running
Linux, Win98, WinCE, etc.

But it is open-source, royalty-free, and written in C. Could probably
be transported to PIC C. Bottom line, as always, is how much can you
stuff into a lowly PIC.

- Dan Michaels
==============

2000\05\30@030357 by William Chops Westfield

face picon face
   I just wish there was a free full TCP/IP implementation out there for
   the PIC :)  I dread having to write my own.

   I've looked at the previously mentioned implementations, not with too
   much detail but they seem to have certain problems.. such as you
   mentioned.. hardware based or limited features. I want an API library
   where I can use standard library calls like in unix to program my
   application.
   I don't want to only be able to use certain ports, or have to connect
   via a ppp/slip link.. Let me know if you find anything like this..

IMO (not very humble - I've got a fair amount of experience in this area),
this isn't possible.  To start with, the protocols pretty much assume an
environment with "separate" operating system and applications, which will
get you to pretty large code (for the "OS" side, which has to have
"everything") pretty quick.  Implementing Internet connectivity on a small
microcontroller means cheating.  How badly you cheat, and where, and whether
you'll be able to get away with it on a large scale, is dependent on how
much space you're willing to sacrifice to the network code (and it IS
primarilly a space issue, rather than a speed issue.)

Possible approaches with "minimal" cheating:

1) Code-generator type scheme, where your code is carefully analyzed,
  and a "custom Network OS" is generated that implements ONLY those parts
  of the stack that you actually use.

2) an interpretter (basic-stamp-like, I guess) with a very large external
  memory... (here, performance might start to be an issue, of course.  An
  interpretted OS with applications written in assembly.  Weird.)

As a reference or starting point, you might consider NCSA telnet, an "open
source" (but predating that term) application/OS/Internet stack that runs on
DOS.  a 1990 ("pre-bloat but post-64k-frugal") implementation has a
"minitel.exe" program without too much extra stuff (like tektronix terminal
emulators) and is about 93kbytes (for the exe file.)  Other possibilities
include "ka9q" - a similar project targetted (restricted?) to ham radio
applications.

BillW

2000\05\30@055310 by Bob Ammerman

picon face
I have implemented TCP/IP (well actually UDP/IP) from the hardware up on
X86. A moderate complete implementation (in "C") uses about:

Code (16-bit x86): 16KBytes
Data: about 12K minimum

This stack implements ARP, IP, ICMP and UDP, but _not_ TCP, PPP or SLIP (it
runs on ethernet).

Seems a bit large for a PIC.

btw: please don't ask for a copy - I wrote this for hire and can not
distibute it  :-(

Bob Ammerman
RAm Systems
(high function, high performance, low level software)

{Original Message removed}

2000\05\30@055313 by TOM THERON

flavicon
face
----- Original Message -----
From: William Chops Westfield
To: PICLISTspamKILLspamMITVMA.MIT.EDU
Sent: Tuesday, May 30, 2000 9:03 AM
Subject: Re: [EE] Embedded Internet enabling methods: Which?

IMO (not very humble - I've got a fair amount of experience in this area),
this isn't possible.  To start with, the protocols pretty much assume an
environment with "separate" operating system and applications, which will
get you to pretty large code (for the "OS" side, which has to have
"everything") pretty quick.  Implementing Internet connectivity on a small
microcontroller means cheating.  How badly you cheat, and where, and whether
you'll be able to get away with it on a large scale, is dependent on how
much space you're willing to sacrifice to the network code (and it IS
primarilly a space issue, rather than a speed issue.)

Possible approaches with "minimal" cheating:

1) Code-generator type scheme, where your code is carefully analyzed,
  and a "custom Network OS" is generated that implements ONLY those parts
  of the stack that you actually use.

2) an interpretter (basic-stamp-like, I guess) with a very large external
  memory... (here, performance might start to be an issue, of course.  An
  interpretted OS with applications written in assembly.  Weird.)

As a reference or starting point, you might consider NCSA telnet, an "open
source" (but predating that term) application/OS/Internet stack that runs on
DOS.  a 1990 ("pre-bloat but post-64k-frugal") implementation has a
"minitel.exe" program without too much extra stuff (like tektronix terminal
emulators) and is about 93kbytes (for the exe file.)  Other possibilities
include "ka9q" - a similar project targetted (restricted?) to ham radio
applications.

BillW

I am primarily looking at a 8051 based system, thus DOS would not serve the
purpose, although if nothing else I can possibly move to an 80188 platform.
But it might be something to look at as part of the learning curve.

Tom Theron

2000\05\30@055315 by TOM THERON

flavicon
face
>Except it isn't really embedded internet, because it requires a
>"real" computer to act as a gateway between the LAN and the 'net.
>If that works for the application, great, but it's apples and oranges..

I agree with you, Spehro,  I had a closer look at their web site. All they
had done was to implement a proprietary protocol to a PC and from there
captured the data into the internet environment. For "local" type of
projects, proprietary is OK, but as soon as we speak about international
markets, I shy away.

Lets see what others have to say.

Bset regards,


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
Spehro Pefhany --"it's the network..."            "The Journey is the
reward"
.....speffKILLspamspam.....interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=

2000\05\30@102405 by TOM THERON

flavicon
face
I definitely don't intend it for PIC , I'll need at least an 8051 with lots
of external memory, or 80188, or 80386EX or...
Tom
{Original Message removed}

2000\05\30@103036 by Byron A Jeff

face picon face
{Quote hidden}

You're right on the mark here Bill. The bottom line is that microcontrollers
aren't really designed for that level of networking. And aside from the
"coolness" factor and compatibility with existing protocols, designing
a full TCP/IP implementation for a microcontroller doesn't buy you very much.

All of your typical heavyweight net applications take advantage of the fact
that the underlaying OS implements the full TCP stack. But TCP as a protocol
puts really heavy demands on the OS. Buffering, retransmissions, flow and
congestion control, and the like cost in code size, data memory required, and
computational complexity.

As I've said before in this forum that UDP/IP is the savior for ucontrollers
requiring internetwork capability because the loss of reliable, sequential
flow controlled delivery completely simplifies the stack implementation. The
only minor cost is having to write an application at the client end to
interact with PIC. But the client doesn't have to be a gateway, it can be
located anywhere on the internet.

The bottom line is that applications are way too varied and ucontroller
way to limited to afford sticking a "standard" OS on them. OTOH a UDP/IP
library could have some utility. Let's see how it stacks up against the
original issues:

"... API library ... standard calls:" This isn't a bad idea. A library with
open, send, receive, and close calls for UDP could be useful.

"certain ports:" The API could easily be designed to handle multiple/varied
ports. And a library implementation would have to. It's just easier to
hardcode a port number...

"[only] ppp/slip link:" This is a matter of the hardware. Ethernet is
easily achievabile with chips like the CS8900. Other's have looked at
RealTek chips and NE2000 interfaces. But the hardware implementations for
PPP/SLIP are much more cost/space effective. A standalone serial link can
be built using a single 8 pin DS1275 or a MAX232 whereas the ethernet
implementations requires a bunch of pins.

Just some thoughts.

BAJ

2000\05\30@103242 by Byron A Jeff

face picon face
>
> I definitely don't intend it for PIC , I'll need at least an 8051 with lots
> of external memory, or 80188, or 80386EX or...

Then why not just go with a PC104 type form factor and use a standard PC OS?

BAJ

2000\05\30@121424 by Jilles Oldenbeuving

flavicon
face
I don't get it whit this Internet stuff. Abviously a complete web-browser
will not be viable with
a PIC processor. But as everyone will have seen, (app.notes, circuit
cellular, etc.) one could
implement just SLIP and UDP to send packets to a server wich will receive
these packets
(even appending data to a ping command could be used).

Also, implementing an SLIP/UDP/SMTP protocol implementation will allow your
application
to send it's data by email to you.... wich i think would be very nice!

I don't think for this an x86 processor will be needed... ofcourse if you
want to implement
more web-functionality, more *memory* will be needed. But as mentioned
before, not more MIPS,
becouse i think that one isn't going to connect it's application via an
T1-line to the internet, so
speed should not be an issue.....

Tom, No offence intended to the ones that think an x86 is needed, becouse
you perhaps have
a different idea of the general 'internet application' than i do...



Regards,

Jilles Oldenbeuving
EraseMEjillesspam_OUTspamTakeThisOuTrendo.dekooi.nl
-----Oorspronkelijk bericht-----
Van: TOM THERON <mmsesysspamspam_OUTICON.CO.ZA>
Aan: @spam@PICLISTKILLspamspamMITVMA.MIT.EDU <KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU>
Datum: dinsdag 30 mei 2000 16:27
Onderwerp: Re: [EE] Embedded Internet enabling methods: Which?


>I definitely don't intend it for PIC , I'll need at least an 8051 with lots
>of external memory, or 80188, or 80386EX or...
>Tom
>{Original Message removed}

2000\05\30@134810 by Dale Botkin

flavicon
face
On Tue, 30 May 2000, Jilles Oldenbeuving wrote:

> I don't get it whit this Internet stuff. Abviously a complete web-browser
> will not be viable with
> a PIC processor. But as everyone will have seen, (app.notes, circuit
> cellular, etc.) one could
> implement just SLIP and UDP to send packets to a server wich will receive
> these packets
> (even appending data to a ping command could be used).
>
> Also, implementing an SLIP/UDP/SMTP protocol implementation will allow your
> application
> to send it's data by email to you.... wich i think would be very nice!

PPP, IP and UDP are not terribly difficult to implement, and are quite
useful.  However, you can't run SMTP or http over UDP, they require TCP.
TCP is more involved if you do it completely.

> I don't think for this an x86 processor will be needed... ofcourse if you
> want to implement
> more web-functionality, more *memory* will be needed. But as mentioned
> before, not more MIPS,
> becouse i think that one isn't going to connect it's application via an
> T1-line to the internet, so
> speed should not be an issue.....

Agreed.  To do fully compliant TCP, you'd need a LOT more memory.  If I
weren't so fond of PICs now I'd be tempted to go back to an 8051 and ang a
big EPROM to do TCP.  Instead, I plan to cheat like hell, use very small
packets and make it *work* like TCP, even if it's not RFC compliant.

It would all be much, much easier with an X86 DOS or Linux platform, maybe
one of those neat little PC104 systems or something.  But none of them
even remotely approach the cost per unit of using a PIC, and the actual
TCP requirements in my project are so rudimentary it would be very
difficult to justfy the extra expense, power, and size.  That's "very
difficult" as in "totally impossible".  Besides - where's the challenge in
making a DOS or Linux box speak TCP?

Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
               -- Isaac Asimov

2000\05\30@140445 by Jilles Oldenbeuving

flavicon
face
>
>PPP, IP and UDP are not terribly difficult to implement, and are quite
>useful.  However, you can't run SMTP or http over UDP, they require TCP.
>TCP is more involved if you do it completely.


Ooops.... overlooked that one... But you get the point....


{Quote hidden}

That's the spirit! Just do only those things that are required. That AN724
might
be of interest as an starting point... The nice thing about the app note is
that they use a modem, wich drives up the cost but it can be directly
connected
to a telephone network and doesn't  need a host. Also use only those things
that
are absolutly needed... so filling in all the fields of an IP-packet doesn't
have
to be necessary.... one has to expiriment with it to see what's required and
what
not... and i'd program it in assembler, not in C. This with the program
memory
space in mind... (not to start a C vs Assembler threat (thread?) on
this)....

>Dale
>---
>The most exciting phrase to hear in science, the one that heralds new
>discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
>                -- Isaac Asimov
Isaac Asimov isn't that the writer of those science fiction books?
(heck, now i can't find them anymore.....)  I found those books a good joy
on trips etc.!!!

2000\05\30@151547 by Dale Botkin

flavicon
face
On Tue, 30 May 2000, Jilles Oldenbeuving wrote:

> >It would all be much, much easier with an X86 DOS or Linux platform, maybe
> >one of those neat little PC104 systems or something.  But none of them
> >even remotely approach the cost per unit of using a PIC, and the actual
> >TCP requirements in my project are so rudimentary it would be very
> >difficult to justfy the extra expense, power, and size.  That's "very
> >difficult" as in "totally impossible".  Besides - where's the challenge in
> >making a DOS or Linux box speak TCP?
>
>
> That's the spirit! Just do only those things that are required. That AN724
> might
> be of interest as an starting point... The nice thing about the app note is
> that they use a modem, wich drives up the cost but it can be directly

I am starting from there.  I'm sticking with C because it's a lot easier
for me to mentally manage a larger program in C than in assembler.  I've
found that the C compiler produces code that is sometimes worse than mine,
sometimes better, but usually overall it's better.  I've learned a lot
about using assembly by reading the C listings after it compiles, in fact.

I plan to dump the modem (and the dialer code, etc) and connect directly
to a PPP server via RS232 serial, so that saves some code space too.

> >Dale
> >---
> >The most exciting phrase to hear in science, the one that heralds new
> >discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
> >                -- Isaac Asimov
> Isaac Asimov isn't that the writer of those science fiction books?
> (heck, now i can't find them anymore.....)  I found those books a good joy
> on trips etc.!!!
>

The same.  I used to read his work a lot -- long ago -- but the quote, I
think, is one of the best I've heard.

Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
               -- Isaac Asimov

2000\05\31@030138 by TOM THERON

flavicon
face
PC104  form factor does not fit the requirement: space, peripherals and cost
.

.----- Original Message -----
From: Byron A Jeff
To: RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU
Sent: Tuesday, May 30, 2000 4:31 PM
Subject: Re: [EE] Embedded Internet enabling methods: Which?


>
> I definitely don't intend it for PIC , I'll need at least an 8051 with
lots
> of external memory, or 80188, or 80386EX or...

Then why not just go with a PC104 type form factor and use a standard PC OS?

BAJ

2000\05\31@124013 by Byron A Jeff

face picon face
>
> PC104  form factor does not fit the requirement: space, peripherals and cost

OK. I went back to your original message. It didn't have any specific
requirements in terms of internet connectivity. What are the physical and
internet protocol that you require?

Also I'm not real familiar with the 80386EX. Can you explain how it
compares in cost and form factor to PC104? Also does the 80386EX have the
80386 MMU? If that's the case you could possibly run an embedded copy of
Linux on it with very little problem, completely solving your internet
connectivity problem.

Lastly 8051's don't have any better ability to access "lots" of external
memory than the PIC does. The 17CXX series can access 128K of ram directly
whereas the 8051 family only can access 32K directly IIRC. Beyond that you
get into back switching and then all bets are off, right? So what's the
definition of "lots" of memory?

Then of course is the speed issue. At the top end you have 8051 derivitives
with 24 Mhz clocks and 3 clock cycle instructions giving up to 8 MIPS.
17CXX parts have a top speed of 33 Mhz with 4 clock cycle instructions giving
up to 8.33 MIPS with most non jump instructions running in a single cycle.
Just wondering why you'd switch from an 8051 family part to a 80386 but
dismiss the PIC as a possibilty.

The bottom line is that if you're going the mostly software route then
the capabilities and performance of the part is critical. A cursory comparison
has PICS matching capability and outpacing performance of 8051s at each
stage.

BTW Neither will effectively support a completely implemented TCP/IP stack.

You've never stated if UDP/SLIP, UDP/PPP, or UDP/IP/Ethernet would satisfy
the application's needs? A full UDP stack is doable on a uController while
a full TCP stack will require some help.

I'm interested because I had a couple of my students doing a UDP/SLIP
implementation on a 16F87X part. They succeeded in pinging before the end
of the semester. UDP still to come.

BAJ


{Quote hidden}

2000\05\31@125709 by Andrew Kunz

flavicon
face
WWW.ZFLINUX.COM

Check it out.

Andy

2000\05\31@153414 by William Chops Westfield

face picon face
   Also I'm not real familiar with the 80386EX. Can you explain how it
   compares in cost and form factor to PC104?

The 80386EX is a processor chip, not particularly related to PC104.  It's
sort of the 186 (highly integrated) version of a 386, I think.


   You've never stated if UDP/SLIP, UDP/PPP, or UDP/IP/Ethernet would satisfy
   the application's needs? A full UDP stack is doable on a uController while
   a full TCP stack will require some help.

Heh.  PPP is so bloated that a microcontroller would be hard-pressed to
sypport a "full PPP."  (fortunately, this is rarely required.)

BillW


'[EE] Embedded Internet enabling methods: Which?'
2000\06\03@032633 by picxpert
picon face
With emWare, you need to hook it up to a PC running emGateway. This PC
connects to the 'net.

-Randy Glenn
TakeThisOuTPICxpertANTISPAMEraseMEspamspam_OUTtechie.com (remove ANTISPAM)
http://i.am/PICxpert

"My Finder has died of fits, chokin',
My Finder has quite ceased to be.
OS X's new Finder looks broken,
Please bring back my Finder to me!" - A concerned Mac user

{Original Message removed}

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