Post by thread:[EE] Embedded Internet enabling methods: Which?

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

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

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

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

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" > .....speffKILLspam@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

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. http://www.ikit2000.com Mark Walsh

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

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

----- Original Message ----- From: William Chops Westfield To: PICLISTKILLspamMITVMA.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

>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" .....speffKILLspam.....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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =

{Quote hidden}> > 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. Just some thoughts. BAJ

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_OUTTakeThisOuTrendo.dekooi.nl -----Oorspronkelijk bericht----- Van: TOM THERON <mmsesysspam_OUTICON.CO.ZA> Aan: @spam@PICLISTKILLspamMITVMA.MIT.EDU <KILLspamPICLISTKILLspamMITVMA.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}

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

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

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

> > 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}> . > > .----- Original Message ----- > From: Byron A Jeff > To: spamBeGonePICLISTspamBeGoneMITVMA.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 >