Post by thread:[PIC]: How about an open-source emWare like produc

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)

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

part 0 1722 bytes content-type:application/octet-stream; Please respond to pic microcontroller discussion list <spam_OUTPICLISTTakeThisOuTMITVMA.MIT.EDU> To: .....PICLISTKILLspam@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}>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? >> 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)

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

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

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

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) jamesnewtonKILLspampiclist.com 1-619-652-0593 PIC/PICList FAQ: http://www.piclist.com or .org {Original Message removed}

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)

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 <.....RAMMERMANKILLspam.....PRODIGY.NET> on 06/16/2000 01:57:04 PM Please respond to pic microcontroller discussion list <EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU> To: PICLISTspam_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)

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}> Date: Thu, 15 Jun 2000 14:56:23 -0700 > From: James Newton <@spam@jamesnewtonKILLspampiclist.com> > To: KILLspamPICLISTKILLspamMITVMA.MIT.EDU > Subject: Re: [PIC]: How about an open-source emWare like product? > > 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) > RemoveMEjamesnewtonTakeThisOuTpiclist.com 1-619-652-0593 > PIC/PICList FAQ: http://www.piclist.com or .org > > {Original Message removed}