From richard at imagecraft.com Thu Nov 13 00:09:08 2008 From: richard at imagecraft.com (Richard Man) Date: Thu Nov 13 01:12:09 2008 Subject: [Icc-mot] Polling for the Future... TCP/IP stack Message-ID: <200811130912.mAD9C7sE083395@mail.imagecraft.com> Now that eMOS for AVR (http://www.imagecraft.com/pub/emos_avr.pdf) is in beta, time to polish off the crystal balls some more. I have a consultant looking at CANLIB for AVR already. I'd think that a robust, fast, small, full-feature TCP/IP stack is high on the list of things we should do. Problem there is there are 4 qualifiers there, and as they usually say, you have 2 out of 3, or 3 out of 4. So what features would you want in a TCP/IP stack? A compiler tie-in is that someone suggested that we provide some sort of API so that a program can take a web page HTML with embedded references to C variables, e.g. ...// html stuff ... .... @foo:bar ... where bar is a local variable in foo, and the API would expand the value at runtime. I am not sure what kind of variable reference we can allow yet, but you get the idea. Yay or nay? Comments and suggestions always welcome. // richard blog: On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From peter at sensair.com Thu Nov 13 01:01:11 2008 From: peter at sensair.com (Peter Lissenburg) Date: Thu Nov 13 02:05:56 2008 Subject: [Icc-mot] Polling for the Future... TCP/IP stack In-Reply-To: <200811130912.mAD9C7sE083395@mail.imagecraft.com> References: <200811130912.mAD9C7sE083395@mail.imagecraft.com> Message-ID: <491BECD7.2020609@sensair.com> Hi Richard, doing similar for a customer now, and having tried other options, that seems to be the simplest and most flexible. The data can be in flash, or on a external memory device such as a USB stick, SD card etc. The assemblage of protocols, or at least parts of, I have running for this customer, are; ip, tcp udp http dhcp smtp and really need, but not got, netbios name server, although there may be a better option. These seem to give the bulk of capabilities that small embedded systems need to be useful and net/user friendly. Just 2cents.... Pete Richard Man wrote: > Now that eMOS for AVR (http://www.imagecraft.com/pub/emos_avr.pdf) is in > beta, time to polish off the crystal balls some more. I have a > consultant looking at CANLIB for AVR already. I'd think that a robust, > fast, small, full-feature TCP/IP stack is high on the list of things we > should do. Problem there is there are 4 qualifiers there, and as they > usually say, you have 2 out of 3, or 3 out of 4. So what features would > you want in a TCP/IP stack? > > A compiler tie-in is that someone suggested that we provide some sort of > API so that a program can take a web page HTML with embedded references > to C variables, e.g. > > ...// html stuff ... > .... @foo:bar ... > > > where bar is a local variable in foo, and the API would expand the value > at runtime. I am not sure what kind of variable reference we can allow > yet, but you get the idea. Yay or nay? > > Comments and suggestions always welcome. > > // richard blog: > > On-line orders, support, > and listservers available on web site. > [ For technical support on ImageCraft products, please include all > previous replies in your msgs. ] > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.9.2/1784 - Release Date: 11/12/2008 7:01 PM > From dean.bell at flightec.com Thu Nov 13 08:48:33 2008 From: dean.bell at flightec.com (Dean Bell) Date: Thu Nov 13 09:53:09 2008 Subject: [Icc-mot] Polling for the Future... TCP/IP stack In-Reply-To: <200811130912.mAD9C7sE083395@mail.imagecraft.com> Message-ID: Hi Richard PPP is a must have for me. compiler tie-in, would that be for the AVR only or MOT, ARM ... as well? Dean. -----Original Message----- From: icc-mot-bounces@imagecraft.com [mailto:icc-mot-bounces@imagecraft.com]On Behalf Of Richard Man Sent: Thursday, 13 November 2008 9:09 p.m. To: icc-announce@imagecraft.com; icc-avr@imagecraft.com; icc-mot@imagecraft.com; icc-430@imagecraft.com; icc-arm@imagecraft.com Subject: [Icc-mot] Polling for the Future... TCP/IP stack Now that eMOS for AVR (http://www.imagecraft.com/pub/emos_avr.pdf) is in beta, time to polish off the crystal balls some more. I have a consultant looking at CANLIB for AVR already. I'd think that a robust, fast, small, full-feature TCP/IP stack is high on the list of things we should do. Problem there is there are 4 qualifiers there, and as they usually say, you have 2 out of 3, or 3 out of 4. So what features would you want in a TCP/IP stack? A compiler tie-in is that someone suggested that we provide some sort of API so that a program can take a web page HTML with embedded references to C variables, e.g. ...// html stuff ... .... @foo:bar ... where bar is a local variable in foo, and the API would expand the value at runtime. I am not sure what kind of variable reference we can allow yet, but you get the idea. Yay or nay? Comments and suggestions always welcome. // richard blog: On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] _______________________________________________ Icc-mot mailing list Icc-mot@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-mot From barryc at rjlsystems.com Mon Nov 17 07:40:51 2008 From: barryc at rjlsystems.com (Barry Callahan) Date: Mon Nov 17 08:46:10 2008 Subject: [Icc-mot] Polling for the Future... TCP/IP stack In-Reply-To: <200811130912.mAD9C7sE083395@mail.imagecraft.com> References: <200811130912.mAD9C7sE083395@mail.imagecraft.com> Message-ID: <49219083.60105@rjlsystems.com> I'd think that making the stack modular so that support for different protocols/applications can be added (or not) at compile/link time would go a long way toward balancing "robust and full-featured" with "small and fast"... That way, if you need SNMP, NTP, SMTP, HTTP, and NMB/SMB/CIFS you can include them, and leave out Telnet, FTP, and gopher. Or whatever. Some comments specific to the template-based HTML API... I like the idea of having a standardized templating API, but I'm not so sure about the proposed implementation. Rather than tossing all of the values into variables somewhere, and having the template driver go fetch them, I'd be tempted to use a callback system. In theory, you could have a separate callback for each page you'd fill in with info, if you so chose. You'd just have to make sure that before you went to serve a document, you registered that document's callback with the template engine. Perhaps the callback would have the form unsigned int template_callback(char* token, char* buffer, unsigned int maxlen); maxlen could be used to ensure that you don't accidentally overflow the buffer. return value would be the length of the text which should replace the token. pass NULL to buffer to just find the string length (to make sure your buffer is long enough) If buffer is non-null and the result string is longer than maxlen, copy the first maxlen chars of the string to buffer, and return the length of the full string. On 11/13/2008 3:09 AM, Richard Man wrote: > Now that eMOS for AVR (http://www.imagecraft.com/pub/emos_avr.pdf) is > in beta, time to polish off the crystal balls some more. I have a > consultant looking at CANLIB for AVR already. I'd think that a robust, > fast, small, full-feature TCP/IP stack is high on the list of things > we should do. Problem there is there are 4 qualifiers there, and as > they usually say, you have 2 out of 3, or 3 out of 4. So what features > would you want in a TCP/IP stack? > > A compiler tie-in is that someone suggested that we provide some sort > of API so that a program can take a web page HTML with embedded > references to C variables, e.g. > > ...// html stuff ... > .... @foo:bar ... > > > where bar is a local variable in foo, and the API would expand the > value at runtime. I am not sure what kind of variable reference we can > allow yet, but you get the idea. Yay or nay? > > Comments and suggestions always welcome. > > // richard blog: > > On-line orders, support, > and listservers available on web site. > [ For technical support on ImageCraft products, please include all > previous replies in your msgs. ] > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot