At 06:14 AM 6/15/00 -0400, you wrote:
>What do you PIClisters think of setting up some sort of open-source project
>to build an emWare like enivoronment?
Excellent idea!!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> What do you PIClisters think of setting up some sort of open-source project
> to build an emWare like enivoronment?
I'd go along with the "direct to Net" group on this one. While it's
painfully true that it is not practical to put the entire RFC-compliant
stack in a PIC, I think we could get an acceptable subset working in a
relatively small codespace.
TCP is complex, and I'm working now to determine exactly what *has* to be
done as opposed to what we'd like to see. ICMP is a slam-dunk, UDP isn't
difficult at all, IP is dead simple, and SLIP is child's play. I've even
got two different methods of the device determining its own IP address.
One takes more space and is "cleaner" but depends on a particular sequence
of events from the other end of the SLIP connection. The other is slimy,
low-down and dirty, but takes nearly no code and will work just fine. My
point is that SLIP is a whole lot more compact than PPP and can work just
as well.
I've been thinking about this for several months, and working on it
non-stop in my off work hours for a couple of weeks now. I'm just kind of
torn between making it open-source and getting lots of help and input, and
the fact that this is a hobby project that could potentially make me a
fair amount of money, considering my target market for the end result. It
sure would be interesting to see how much better it could be made with
several more pairs of eyes and several more brains working on it.
Of course, I'm working in C, which could be problematic... I've noticed
that there's not a heck od a lot of portability between PIC C compilers.
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
part 0 3161 bytes content-type:application/octet-stream;
You've done a lot of work, then, it sounds.
I am starting to go into the GPL/open source end myself. I'm doing it to
enhance the community, and because I realized (after seeing very little $$) that
I would never get rich doing this <G>. I'm also hoping the quality will get
bumped way up.
As for working in C, you can probably do 99% of what you need to do in standard
C code. Time-critical stuff should be in assembly (to prevent optimization
problems), and compiler-specific stuff can be done with include files. (see
"defs.c" attached). I use this all the time to test stuff on a PC, then drop it
into the PIC and I can fully expect it will work "first time." (NOTE: DEFS.H
is messy code!)
Subject: Re: [PIC] How about an open-source emWare like
product?
On Thu, 15 Jun 2000, Bob Ammerman wrote:
> What do you PIClisters think of setting up some sort of open-source project
> to build an emWare like enivoronment?
I'd go along with the "direct to Net" group on this one. While it's
painfully true that it is not practical to put the entire RFC-compliant
stack in a PIC, I think we could get an acceptable subset working in a
relatively small codespace.
TCP is complex, and I'm working now to determine exactly what *has* to be
done as opposed to what we'd like to see. ICMP is a slam-dunk, UDP isn't
difficult at all, IP is dead simple, and SLIP is child's play. I've even
got two different methods of the device determining its own IP address.
One takes more space and is "cleaner" but depends on a particular sequence
of events from the other end of the SLIP connection. The other is slimy,
low-down and dirty, but takes nearly no code and will work just fine. My
point is that SLIP is a whole lot more compact than PPP and can work just
as well.
I've been thinking about this for several months, and working on it
non-stop in my off work hours for a couple of weeks now. I'm just kind of
torn between making it open-source and getting lots of help and input, and
the fact that this is a hobby project that could potentially make me a
fair amount of money, considering my target market for the end result. It
sure would be interesting to see how much better it could be made with
several more pairs of eyes and several more brains working on it.
Of course, I'm working in C, which could be problematic... I've noticed
that there's not a heck od a lot of portability between PIC C compilers.
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
Dale Botkin wrote:
> I've been thinking about this for several months, and working on it
> non-stop in my off work hours for a couple of weeks now. I'm just kind of
> torn between making it open-source and getting lots of help and input, and
> the fact that this is a hobby project that could potentially make me a
> fair amount of money, considering my target market for the end result. It
> sure would be interesting to see how much better it could be made with
> several more pairs of eyes and several more brains working on it.
>
> Of course, I'm working in C, which could be problematic... I've noticed
> that there's not a heck od a lot of portability between PIC C compilers.
>
> 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 understand your point but the fact is that just a tcp/ip stack doesn't
make the end product
i mean to make a "REAL" embedded webser you'd still need to implement
the server application as well as the file systems etc etc.
connectivity by itself doesn't make the end product (unless you plan to
just sell the code for $5000 like others seem to do) :)
Bob Ammerman wrote:
>
> What do you PIClisters think of setting up some sort of open-source project
> to build an emWare like enivoronment?
>
> Bob Ammerman
> RAm Systems
> (high performance, high function, low-level software)
Me too..
I propose that we try a module approach
have some sort of base code to implement conectivity
then maybe some type of module format where by
if i needed a pic to connect via ethernet implementing http and udp and
snmp
I could get my hardware driver code in the pic (already in progress for
the CS8900a crystal logic chip)
add the base networking code and then pic my protocols
we need a homepage now :)
I'll buy it and host I can probably host it.. any suggestions for a
domain name
what about OpenPic.com
we could have multiple projects like this (eventually)
>I understand your point but the fact is that just a tcp/ip stack doesn't
>make the end product
>i mean to make a "REAL" embedded webser you'd still need to implement
>the server application as well as the file systems etc etc.
>connectivity by itself doesn't make the end product (unless you plan to
>just sell the code for $5000 like others seem to do) :)
But without the connectivity the "REAL" product CANNOT be made. As long as you
can get messages out of the PIC's little sandbox (especially if it doesn't need
to go through any other boxes) then you can do whatever you need.
I guess my point about the whole subject is that, if you are going to need a PC
to provide the interface to the world, why not use an RS-232 or similar setup
with a custom (application-specifc, application-optimized) protocol. The PC can
take that out to the real world then.
If you don't want a PC in the way, then go with something small/simple (the CS
chip, for example) and implement minimal connectivity using a standard (UPD/IP)
and put the interpretation software on the client's machine (custom net app
(easy in VB) or OpenView if you put SNMP into the PIC).
Subject: Re: [PIC] How about an open-source emWare like
product?
Bob Ammerman wrote:
>
> What do you PIClisters think of setting up some sort of open-source project
> to build an emWare like enivoronment?
>
> Bob Ammerman
> RAm Systems
> (high performance, high function, low-level software)
Me too..
I propose that we try a module approach
have some sort of base code to implement conectivity
then maybe some type of module format where by
if i needed a pic to connect via ethernet implementing http and udp and
snmp
I could get my hardware driver code in the pic (already in progress for
the CS8900a crystal logic chip)
add the base networking code and then pic my protocols
we need a homepage now :)
I'll buy it and host I can probably host it.. any suggestions for a
domain name
what about OpenPic.com
we could have multiple projects like this (eventually)
I have used the SMC91C9X chips for embedded ethernet. These have 5K of
onboard RAM with built in page-based memory management. You can access this
RAM RANDOMLY from the host. With a little care, the ethernic can now also
serve as buffer space in which you can process the packets instead of just a
pipe that feeds the data to the host (ala the CS8900, the way I read it).
Bob Ammerman
RAm Systems
(high function, high performance, low-level software)
> <**> I think there are probably applications for both 'direct to Net' and
> 'gateway supported' connectivity.
I agree completely.
> <**> One of the biggest problems with the minimal implementations is that
> they tend to not have proper error recovery. This is because they don't have
> the space (RAM) to store enough state, nor the space (ROM) for all the error
> handling code. This means that they seem to work when everything is clean
> and happy around them, but break down quickly once things start going wrong.
Again we are in harmony... <grin> That's why I am concentrating on things
that don't depend on end-to-end error handling. SNMP wueries are easily
repeated, Web browsers will (I think) re-send requests... While I would
LOVE to see a telnet server on my PIC, I don't think it's gonna happen.
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 have used the SMC91C9X chips for embedded ethernet. These have 5K of
>onboard RAM with built in page-based memory management. You can access this
>RAM RANDOMLY from the host. With a little care, the ethernic can now also
>serve as buffer space in which you can process the packets instead of just a
>pipe that feeds the data to the host (ala the CS8900, the way I read it).
> I understand your point but the fact is that just a tcp/ip stack doesn't
> make the end product
True, which is why I'm trying to make it small enough to leave room for
the application. I have the file system part worked out already, as well
as some other functions. I've reluctantly switched from 16F84 to 16C73 to
accomodate the code, and I don't want to have it so large it requires an
'877 before you have anything useful.
> i mean to make a "REAL" embedded webser you'd still need to implement
> the server application as well as the file systems etc etc.
> connectivity by itself doesn't make the end product (unless you plan to
> just sell the code for $5000 like others seem to do) :)
The server application can be very tiny if you don't expect it to do
CGI and such. You can have background tasks updating the content of
"files" stored in EEPROM, which the HTTP server dishes out on request. No
need for the server to do the work on demand.
Another idea I'm using is not trying to parse a whole message from the
client, but just "peeking" at the bytes we're interested in. If I see a
packet on port 80, I assume it's a GET request, so I look at the bytes
starting with #6 for the file being requested. A little slimy, but again,
I'm not going for a totally general-purpose server application, I have
Linux boxes for that.
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
> It sounds to me like we are up to about three PICS per project now
>
> 1) to do the IP interface to the internet
> 2) to do the TCP/UDP whatever other higher level protocol you want
> 3) to do the end application.
>
> This should all fit on a pretty small board - PCMCIA size if it is all surface
> mount?
*THREE* PICs? Heavens no! I'm going for 2K or less on *ONE* PIC. I've
seen HTTP done on an 'F84 already (Richard Beales?). Neat, but I needed
ICMP and UDP also, and a little more of a general-purpose set of code.
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
>*THREE* PICs? Heavens no! I'm going for 2K or less on *ONE* PIC. I've
>seen HTTP done on an 'F84 already (Richard Beales?). Neat, but I needed
>ICMP and UDP also, and a little more of a general-purpose set of code.
Well I was going for a general purpose fully compliant total error recovery.....
> >*THREE* PICs? Heavens no! I'm going for 2K or less on *ONE* PIC. I've
> >seen HTTP done on an 'F84 already (Richard Beales?). Neat, but I needed
> >ICMP and UDP also, and a little more of a general-purpose set of code.
>
> Well I was going for a general purpose fully compliant total error recovery.....
Ah. Three at least, then, you're right.
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
Andrew Kunz wrote:
>
> I suggest http://www.VNode.com as a host.
>
> openpic.com gets my vote!
>
> The CS8900 is an excellent chip.
>
> Andy
Personally I'd rather host it at my brothers worksite as I have root on
his box and I can thus install whatever software i want/need we would
have virtually no restrictions as he has about 13 gigs of space free I'd
have access to his dns server as well as anyother thing i might need.
his machine is running freebsd and is NEVER down. also they have a t# as
well as a T1 (backup) for connectivity.
Subject: Re: [PIC] How about an open-source emWare like
product?
Andrew Kunz wrote:
>
> I suggest http://www.VNode.com as a host.
>
> openpic.com gets my vote!
>
> The CS8900 is an excellent chip.
>
> Andy
Personally I'd rather host it at my brothers worksite as I have root on
his box and I can thus install whatever software i want/need we would
have virtually no restrictions as he has about 13 gigs of space free I'd
have access to his dns server as well as anyother thing i might need.
his machine is running freebsd and is NEVER down. also they have a t# as
well as a T1 (backup) for connectivity.
I've gotta learn more about TCP/IP! Anyways, I'm thinking of having a
PIC send and receive UDP. A PC would be running an application that
interprets the UDPs it receives and stores the results (telemetry data)
in files (perhaps on RAM disk?). A browser evaluates local HTML files and
does client side includes of the filed UDP data to drop this data into
user defined pages. One tricky part is the client side include... It
seems that browsers could easily support an <IMG> tag with a file
extension of TXT or HTML to do a client side include (just like they
include images). Failing that, the application that's turning incoming
UDPs into files could turn them into GIFs representing the incoming data.
On the data-to-the-pic side, I guess I'd have to do some sort of CGI-GET
request to the PIC...
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
dl.http://www.juno.com/get/tagj.
Why not only implement UDP and a ping service on the PIC (or whatelse there
is needed). Appending
data/commands at the end of the ping. Than get some computer
on the net that accepts those pings and converts them to whatever you want
to do, e.g. send an email to
a particular adress or something. That needs to be standardized and someone
on the list could open that
service to other piclisters... Also emailing to that server would result
eventually into a ping to a pic, etc. etc...
What about using (perhaps in modified form) a protocol such as
MODBUS RTU (maybe with relaxed timing specs, and different packet
definitions), with CRC's for the communication between the PIC and
the gateway? That can be implemented on RS-485 or other physical
layer. Keep the part in the PIC to *well* under 1K and very little
RAM (and a UART). Keep the buffering in the gateway.
Echelon had a quite well thought out system, could something be
"borrowed" from that? Particularly the variable types and units
definitions for physical parameters?
Just some random thoughts, I am not deeply into this right now,
except for MODBUS.
Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward" RemoveMEspeffTakeThisOuTinterlog.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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
If someone writes the windows service (replacing the default windows ping
response) for ping to... pong and pong to ping service, I would be happy to
host it at piclist.com.
We would have to require a membership to prevent PICs from SPAMing <GRIN>,
but that could be free or at least TANSTAAFL.
The point is that via UDP or other TCP/IP based protocol, the PIC and the
gateway don't have to be next to each other. Your PIC is at the customer
site connected to a modem (in which case you must also do PPP in the PIC) or
SLIP port and your gateway is... anywhere. The gateway translates an
incoming data request from a client browser, email server, etc... into the
non-RFC data format that you hide in the ping and sends it to the PIC,
and/or translates the response or ping from the PIC into a good, solid RFC'd
format and replies to the browser or sends an email or whatever.
Imagine a box that you built for your customer that is connected to a SLIP
port or has a modem and shares a fax, etc... line. Every middle of the
night, it contacts your gateway server and uses it to send a status / data
dump email etc... then downloads a firmware update / control commands / data
analysis etc... and continues about its way. If the line is dedicated, and
the modem is set to autoanswer, or if you are on a SLIP port, you can query
the PIC from any browser in the world or send an email that changes the PWM
rate of pin 5 or ... you get the idea.
Why not only implement UDP and a ping service on the PIC (or whatelse there
is needed). Appending data/commands at the end of the ping.
I thought you were at least peripherly interested in "conformance." Adding
"user data" to ping packets (or ICMP in general) isn't allowed and wouldn't
count as conforming to much of anything. Additionally, ICMP is frequently
supressed by all sorts of firewalls.
I don't think y'all are "getting it" with respect to emWare and similar
products. Providing internet connectivity is only PART of such a
product. A larger part (IMHO) is providing a supported web application
library. emWare presumably (I have not looked at it in much detail)
allows an embedded designer to incorporate web-managed/available data
into their project WITHOUT them having to learn a bunch about internet
networking in general. An open-source product might be useful for some
people, but is probably about as much use to emWare customers as a java
compiler is to basic stamp target audience.
For a stripped-down TCP/IP implementation on a microcontroller, I wouldn't
worry very much about "conformance" in a larger sense, as long as you are
"well behaved" within the scope of what you actually do. Implementing
fragment reassembly is pretty pointless if your applications can limit
packet sizes to those which are very unlikely to be fragmented, for
instance. ICMP support is a slightly thornier issue, but I think you
could do without it...
The point is that via UDP or other TCP/IP based protocol, the PIC and
the gateway don't have to be next to each other. Your PIC is at the
customer site connected to a modem (in which case you must also do PPP
in the PIC) or SLIP port and your gateway is... anywhere.
From a theoretical view, the same could be true of an emWare gateway, of
course. If emWare catches on, there isn't any reason why you couldn't
have a network of emWare ISPs, or even emWare support in "standard" ISPs.
On Thu, 15 Jun 2000, William Chops Westfield wrote:
> Why not only implement UDP and a ping service on the PIC (or whatelse there
> is needed). Appending data/commands at the end of the ping.
>
> I thought you were at least peripherly interested in "conformance." Adding
> "user data" to ping packets (or ICMP in general) isn't allowed and wouldn't
> count as conforming to much of anything. Additionally, ICMP is frequently
> supressed by all sorts of firewalls.
ICMP would be a poor choice, but UDP isn't much more complex and would
work fine.
> I don't think y'all are "getting it" with respect to emWare and similar
> products. Providing internet connectivity is only PART of such a
> product. A larger part (IMHO) is providing a supported web application
> library.
Man, I swore I'd never say, "horses for courses", but here we are. I'm
not saying emWare doesn't have a place, but I would say wit certainty that
there are places that it won't be a good solution at all, and I think an
embedded mini-stack would work better.
> networking in general. An open-source product might be useful for some
> people, but is probably about as much use to emWare customers as a java
> compiler is to basic stamp target audience.
And that's a Good Thing(tm), it means emWare sales reps won't be
cluttering up the lines at the soup kitchens and unemployment offices...
> For a stripped-down TCP/IP implementation on a microcontroller, I wouldn't
> worry very much about "conformance" in a larger sense, as long as you are
> "well behaved" within the scope of what you actually do. Implementing
> fragment reassembly is pretty pointless if your applications can limit
> packet sizes to those which are very unlikely to be fragmented, for
> instance. ICMP support is a slightly thornier issue, but I think you
> could do without it...
I agree wholeheartedly. If "conformance" were an issue, it would be tough
to justify HSRP and EIGRP... <grin>. I'm curious though -- why do you
see ICMP as a thorny issue? It looks dead simple from where I'm at. That
is, sending ICMP packets of any type anywhere, and receiving/responding to
ICMP ECHO. If you want to use ICMP for the whole mess, unreachables,
source quench, etc, then yes, it's a big can o' worms. But the same could
be said about IP fragmentation and such. Implement whaty you need to for
your application or to get along in the real world, and at least handle
the rest gracefully -- if you get a fragged packet, don't crash and burn,
etc.
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
The main point I wanted to make is taht the whole project should be
MODULAR
something like the following might be implemented
#define USE_ETHERNET
#define USE_CS8900A
#define USE_DHCP_CLIENT
#define USE_ICMP
#define USE_ICMP_UNREACHABLE
#define USE_UDP
#define USE_IP
#define USE_IP_FRAGMENTS
this might define the inclusion of code that will give support for:
ethernet physical layer connection via a cs8900a chipset
using dhcpd to get an ip address
icmp with source unreachable support
basic udp
basic IP with fragment support
everything else is dropped
or you could set the thing up to say
#define USE_PPP
#define USE_MODEM_CHIP_OF_SOME_TYPE
#define FULL_TCPIP_SUPPORT
#define NO_USE_UDP
and include EVERYTHING in all the RFC's via a PPP interface that has
been implemented for a certain modem chipset except don't include any
UDP code
then if some people only want to use certain parts then they can
the point is that _EVERYTHING_ SHOULD be coded but not expected to fit
on one chip
at this point I might point out that we would have to set certain
standards such as to what hardware is supported
i.e. if you are going to support fragmented packets then you need to
have a specified type of memory device hooked up via a supported access
method. or wanted to use an ethernet connection then the device drivers
for that shipset would need to be coded and implemented
what I'm talking about it FULL compliance with the RFC's basically you
could implement what you needed or will fit into the pic you want.
Damon Hopkins
BTW I talked w/ my brother and he said it would be great if we wanted to
host it on his machine
If there are no other opinions/suggestions for a domain name then I plan
on registering openpic.com probably on monday. I can also set up a cvs
server or majordomo or anything else we might need.
<BLOCKQUOTE>
...the first ICMP packet starts off with an 8 which stands for 'Echo
Request'. This means we're asking the destination server to Echo the packet
back to us when it receives it. In this way we can both time the packet and
check the reliability of the link. This first byte is known as the Type
Field.
The next byte is a zero and stands for the Code.
After that come two bytes for the Checksum and right after that come another
two bytes for the IDentification number. The ID has to be unique, so most
UNIX boxes set the ID's to the number of the current process.
The next two bytes constitute the Sequence Number.
Finally, we can add any optional data if we so desire. The data added will
be echoed back to us so that we can check the reliability of the line.
</BLOCKQUOTE>
The only limitation is that the optional data be less than 64k as more than
that may cause problems on older implementations of the PING service.
Also, by definition, a ping is about the simplest protocol in the internet.
And it is always implemented so even if you hit the wrong IP address, you
get something back, and can tell if your connection is good (and you have
the wrong IP address).
Seems to me that ping with "user data" would be ideal for embedded internet
PICs. No need for TCP/IP in the PIC. Just PPP (if you need dialup) and ICMP.
interlog.com Info for manufacturers: http://www.trexon.com
