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:

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)

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

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

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.

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

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.

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.

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

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

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.

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

> 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

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

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

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

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