Searching \ for '[PIC]: How about an open-source emWare like produc' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'How about an open-source emWare like produc'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: How about an open-source emWare like produc'
2000\06\15@094526 by Bob Ammerman

picon face
If we are going to do this we have some questions we need to ask and answer:

Q: Just what is emWare anyway?

- From what I can gather, it is two major code components:

-- emMicro - code that runs on the microcontroller
-- emGateway - code that runs on a Windows PC and 'extends the internet' to
the microcontroller

Q: What would we need to create?

-- We would have to define a simplified protocol into which we can convert
normal TCP, UDP and maybe even HTTP transactions. This protocol would be
used between the PC gateway and the embedded device. Are there any standards
out there that would apply? This protocol should be completely independent
of the underlying physical medium (or protocol stacks).

-- We would have to define an interface that would allow 'drivers' to be
written for various physical interfaces to the embedded devices. To avoid
binding to the Windows world, I suggest this just be a simple DLL/Shared
library specification, or even a C++ class definition that specific drivers
can derive from.

-- We would have to design and implement the PC gateway program to convert
from TCP, UDP and maybe even HTTP to the simplified protocol. This program
would load up whatever drivers it needed to communicate with attached
devices. This program should be portable across Windows and Unix (especially
Linux) worlds. It should be driven by some sort of a configuration file that
defines the mapping between  requests received via IP into invocations of
the correct clients via the simplified protocol.

-- We would have to design and implement 'reference'  drivers for at least a
couple physical interfaces. Perhaps RS232 and a 'dummy' interface that
executes as a simulated embedded device.

-- We would have to design and implement at least one 'reference' client.
Perhaps a PIC [see, we can justify the [PIC]: in the subject line :-)]
connected via RS232.

Q: What type of interfaces between the PC and the microcontroller do we
need?

- Here are some possibilities:

-- RS232
-- RS485
-- Ethernet
-- Parallel port interfaces
-- Direct PCI/ISA bus connections
-- USB
-- etc.

Q: What else do we need to think about?

- You tell me :-)


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

2000\06\15@095758 by Andrew Kunz

flavicon
face
>Q: What type of interfaces between the PC and the microcontroller do we
>need?
>
>- Here are some possibilities:
>
>-- RS232
>-- RS485
>-- Ethernet
>-- Parallel port interfaces
>-- Direct PCI/ISA bus connections
>-- USB
>-- etc.

There are UPD implementations with hardware/software for the Ethernet with a
PIC/8051/Mot already.   Microchip has SLIP/PPP demo code.  Why not skip the PC
side (or maybe make it just serve as a regular gateway) and go "direct" to the
net?

Another (simpler) possibility is just to have an HTTP server which takes certain
meta commands out of the HTML and uses them to look up info which it inserts in
place (like a macro).  This is hte method used in the US Software stuff I've
been using lately.  Very handy.  This meta format could be easily extended to
access a PIC device, especially if the format supported something like:

    <!--PIC_META
         <COMMAND=open("com1",9600);>
         <COMMAND=write("com1","get");>
         <RETURN=read("com1",timeout=50);>
    -->


Andy

2000\06\15@101639 by D Lloyd

flavicon
face
part 0 1722 bytes content-type:application/octet-stream;








Please respond to pic microcontroller discussion list <spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU>

To:   .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
cc:    (bcc: Dan Lloyd/GBPTD/ABB)
Subject:  Re: [PIC]: How about an open-source emWare like product?

Security Level:?         Internal



{Quote hidden}

There are UPD implementations with hardware/software for the Ethernet with a
PIC/8051/Mot already.   Microchip has SLIP/PPP demo code.  Why not skip the PC
side (or maybe make it just serve as a regular gateway) and go "direct" to the
net?

>> I'd vouch for this one......Only out of selfishness because I would like to
see how it is done. I find the Microchip app note for the SLIP/PPP connection a
little "undocumented" - it would be nice to know what precisely can be omitted
from the full strength protocol and where half of the magic numbers come from.
(Maybe David Copperfield writes half of the source to be found on the web?)
Incidentally, can anyone help in this area? Just because I like to be a hermit,
I would like to construct an embedded web server, implemented in software (no
Seiko parts etc), that maybe takes the output from a webcam, processes it, then
puts it into a deliciously served-up webpage.....

Thanks in advance,

Dan






Content-type: application/octet-stream;
       name="pic23571.pcx"
Content-Disposition: attachment; filename="pic23571.pcx"

Attachment converted: creation:pic23571.pcx (????/----) (000165EF)

2000\06\15@102702 by Bob Ammerman

picon face
See my comments marked <**> below.

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

{Original Message removed}

2000\06\15@103503 by Andrew Kunz

flavicon
face
><**> Yes, unfortunately these implementations are not RFC compliant, and
>actually implement only  restricted subset of the corresponding protocols.
>Putting a full blown implementation into a microcontroller isn't practical.

Is emware RFC compliant?

Does it matter if you have a fully compliant set?  Very few systems _need_ full
compliance.  A UPD/IP interface, especially, is rather small and should be
adequate for most situations.  So you can use it as an HTTP server, but you can
do a limited SNMP with it easily enough.  Or (more likely) you can do a custom
command set just like exists on the traditional RS-232 line, and send them over
UDP/IP.

Andy

2000\06\15@105720 by Bob Ammerman

picon face
See <**> below

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


{Original Message removed}

2000\06\15@110757 by Andrew Kunz

flavicon
face
><**> I assume you meant to say: '_can't_ use it as an HTTP server, but...'

These are Fingers 1.0 and have a known erasure problem.  They also have a macro
"feature" which triggers spontaneously as well when certain keystrokes are
generated, and the packet transmission mechanism sometimes allows characters to
be transposed. <G>

IOW, you are correct.

><**> Compliant UDP/IP isn't all that small. It should be able to handle
>fragmented packets, for example, though most (all) tiny implementations
>don't. As long as you're lucky enough to be working thru a path that doesn't
>fragment you'll be ok, but as soon as any link in the chain fragments you're
>dead.

And since you have limited memory in a PIC, you can start by asserting that
fragments are OK because there isn't a network on the Internet which is passing
packets under 512 bytes, usually 1.5K per.

><**> One of the primary advantages of emWare is that is extended
>higher-level standardized protocols (like HTTP) down to the microcontroller
>level.

But it requires use of a PC to get that.  If I wanted to stick a PC there, I
wouldn't have made the attached device need emware; it would be on an ISA or
PC/104 card, or dedicated serial link.  Kinda defeats the purpose.

><**> SNMP is a good hack to use UDP to 'poll' a device for useful
>information. How do I get that SNMP data to appear in my browser window?

That's it, you can't (SNMP is UPD only, HTTP is TCP only).  Have no fear,
though, because OpenView (SNMP client) will put the data up in the format you
want.

Or you just provide the customer with a small app for his PC that does the UPD
communication to your board.  This saves MIB generation too, not an
insignificant thing (I'm doing a MIB right now and it's gotta be the thing I
most hate in 20+ years of programming).

Andy

2000\06\15@112655 by Bob Ammerman

picon face
See <**> notes below.

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

{Original Message removed}

2000\06\15@114354 by Dale Botkin
flavicon
face
On Thu, 15 Jun 2000, Bob Ammerman wrote:

> <**> I expect the emGateway is as RFC compliant as the Windows TCP/IP stack
> it rests upon :-)

That bad, eh?  <grin>

> <**> Compliant UDP/IP isn't all that small. It should be able to handle
> fragmented packets, for example, though most (all) tiny implementations
> don't. As long as you're lucky enough to be working thru a path that doesn't
> fragment you'll be ok, but as soon as any link in the chain fragments you're
> dead.

Very true, fragmented packets can be problematic.  Fragmentation is done
at the IP level, so it affects UDP, ICMP, and TCP.  The way I planned to
handle it would be to keep communication from the outside world to the PIC
down to small packets so they don't fragment.  Packets from the PIC back
to the outside world can be pretty much as long as we want to make them,
and let the rest of the world deal with it.

I'm building my stuff for a range of applications within certain defined
parameters that will allow the stack functionality to be trimmed down
somewhat.  Since the PIC isn't an application platform like a PC, I don't
think a 100% compliant, totally general-purpose stack is really needed.
Just my take on the situation.

> <**> SNMP is a good hack to use UDP to 'poll' a device for useful
> information. How do I get that SNMP data to appear in my browser window?

You don't, but it's great for things that need to be monitored by a script
and not a browser.  Using an SNMP tool such as snmpget to pull data from
a device answering SNMP GET requests approaches trivial (especially on a
UNIX platform, but also on the PC).  For example, imagine a PIC monitoring
water levels and reporting via SNMP.  You can use MRTG (which runs on
almost anything) and build nice graphs for your browser.

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\06\15@120352 by Andrew Kunz

flavicon
face
> Or you just provide the customer with a small app for his PC that does the
>UPD
>
><**> Uh, isn't this small app then kind of like emGateway?

No, what I'm talking about is a net-aware program that replaces the browser on
the client PC, not a gateway or a "emware" that converts the communications into
HTML.

Andy

2000\06\15@180255 by jamesnewton

face picon face
So, you are saying that rather than UDP from the PIC to a PC somewhere, then
HTTP from the PC to any browser, you would replace the UDP -> HTTP
translator with a UDP data unpacking program that directly displays the data
on the PC....

....ok, but that is only good if you can have a copy of that program on
every PC that needs access to the data, right? If you want to IO with any
Browser on the internet, you still need the "emware".

There is HTTP server code for a PIC at
http://www.piclist.com/petrovwwwpic

Features:

   Soft UART baud rate                 up to 38400
   HTTP port                           1..255
   Maximum TCP window size             128 (up to 255)
   Program ROM use                     about 400x14
   RAM use                             32x8
   Internal storage for www-pages      1K
   External storage for www-pages      up to 8M

Missing:

   PPP
   UDP
   ICMP packet processing
   Version for AVR90S2313

---
James Newton (PICList Admin #3)
jamesnewtonspamKILLspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2000\06\16@135916 by Bob Ammerman

picon face
Oh well, it looks like this thread has more or less devolved into an 'I can
build tha TCP/IP stack in N bytes' situation. My original question seems to
have been lost in the (very interesting and informative) noise.

It seems that there is little interest in building an open-source emWare
like product, which would provide a 'write-once' implementation of many of
the components required to allow simple microcontroller based products to
communicate in an I/in(ter,tra)net.

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

2000\06\16@140336 by Andrew Kunz

flavicon
face
Bob,

I came to the exact opposite conclusion.  We have somebody setting up a domain
for open-source PIC software, and the first project on the table is your
proposition.

Andy








Bob Ammerman <.....RAMMERMANKILLspamspam.....PRODIGY.NET> on 06/16/2000 01:57:04 PM

Please respond to pic microcontroller discussion list <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>








To:      PICLISTspamspam_OUTMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: [PIC]: How about an open-source emWare like
         product?








Oh well, it looks like this thread has more or less devolved into an 'I can
build tha TCP/IP stack in N bytes' situation. My original question seems to
have been lost in the (very interesting and informative) noise.

It seems that there is little interest in building an open-source emWare
like product, which would provide a 'write-once' implementation of many of
the components required to allow simple microcontroller based products to
communicate in an I/in(ter,tra)net.

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

2000\06\16@163614 by rleggitt

picon face
If you're going to use a proxy host then you don't really need ppp/ip/etc.
at all. The default radius service for a dialup account is 'ppp', but you
can easily specify 'tcp/clear' instead.

In this case, you (the client device) chat past the terminal server login
prompts as usual, the terminal server authenticates via radius, radius
says "connect to host x.x.x.x port x", and you end up with a clean 8-bit
async connection directly to your host. Assuming v.42 modems you also get
end-to-end error correction, so what little protocol you DO need can be
less complicated than xmodem. About the only thing you need to be careful
of is transmission latency. In addition to vastly simplifying the
firmware, there are some very real security advantages.

Been there, done that, it works great -- Rich

On Thu, 15 Jun 2000, James Newton wrote:

{Quote hidden}

> {Original Message removed}

2000\06\16@221244 by Bob Ammerman

picon face
Open source yes: but the focus seems to be on a stck [stack without all the
pieces :-)] on the chip itself.

{Original Message removed}

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