From dvorakvik at seznam.cz Tue Sep 2 22:26:19 2003 From: dvorakvik at seznam.cz (Viktor Dvorak) Date: Tue, 2 Sep 2003 22:26:19 +0200 Subject: [En-Nut-Discussion] ImageCraft library libnutcrtf.a Message-ID: <000c01c37190$782ab540$0200a8c0@viktor> Hi, building the libnutcrtf.a in/for ImageCraft iccavr is simple. Use the content of makefile_gcc for seeing the difference between libnutcrt.a and libnutcrtfa.a and make your own library(s). Librarian name is ilibw.exe. Compile the sourcecode.c using iccavr and make your library usind ilibw -a mylibrary.a myobject.o. Viktor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030902/de47e368/attachment.html From bbuenaobra at nip.upd.edu.ph Fri Sep 5 20:12:09 2003 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Fri, 5 Sep 2003 11:12:09 -0700 Subject: [En-Nut-Discussion] Querying Ethernut from HTTP References: <20030903100001.30732.73438.Mailman@p15095813.pureserver.info> Message-ID: <009601c373d9$396f5180$5065a8c0@instru.nip.upd.edu.ph> Hello: Just got my kit two days to go and raring to have it wired in the lab. I can ping the address at 192.168.101.82 but cant http://192.168.101.82/index.htm . How is it done? Berns B. ************************************ Bernardino J. Buenaobra University Research Associate National Institute of Physics University of the Philippines Diliman, Quezon City 1101 Philippines Email: bbuenaobra at nip.upd.edu.ph Tel/Voice: +632-434-4232 Fax/Data: +632-928-0296 Mobile: 0916-2550-056 URL: www.nip.upd.edu.ph/ipl ************************************ ----- Original Message ----- From: To: Sent: Wednesday, September 03, 2003 3:00 AM Subject: En-Nut-Discussion digest, Vol 1 #277 - 1 msg > Send En-Nut-Discussion mailing list submissions to > en-nut-discussion at egnite.de > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.egnite.de/mailman/listinfo/en-nut-discussion > or, via email, send a message with subject or body 'help' to > en-nut-discussion-request at egnite.de > > You can reach the person managing the list at > en-nut-discussion-admin at egnite.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of En-Nut-Discussion digest..." > > > Today's Topics: > > 1. ImageCraft library libnutcrtf.a (Viktor Dvorak) > > --__--__-- > > Message: 1 > From: "Viktor Dvorak" > To: > Date: Tue, 2 Sep 2003 22:26:19 +0200 > Subject: [En-Nut-Discussion] ImageCraft library libnutcrtf.a > Reply-To: en-nut-discussion at egnite.de > > Toto je zprava ve formatu MIME obsahujmcm vmce hastm. > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > Content-Type: text/plain; > charset="iso-8859-2" > Content-Transfer-Encoding: quoted-printable > > Hi,=20 > > building the libnutcrtf.a in/for ImageCraft iccavr is simple. Use = > the content of makefile_gcc for seeing the difference between = > libnutcrt.a and libnutcrtfa.a and make your own library(s). Librarian = > name is ilibw.exe. Compile the sourcecode.c using iccavr and make your = > library usind ilibw -a mylibrary.a myobject.o. > > Viktor > > > > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > Content-Type: text/html; > charset="iso-8859-2" > Content-Transfer-Encoding: quoted-printable > > > > http-equiv=3DContent-Type> > > > > >
Hi,
>
 
>
    building the = > libnutcrtf.a=20 > in/for ImageCraft iccavr is simple. Use the content of makefile_gcc for = > seeing=20 > the difference between libnutcrt.a and libnutcrtfa.a and make your = > own=20 > library(s). Librarian name is ilibw.exe. Compile the sourcecode.c using = > iccavr=20 > and make your library usind ilibw -a mylibrary.a = > myobject.o.
>
 
>
    = > Viktor
>
 
>
 
> > ------=_NextPart_000_0009_01C371A1.3B5F98E0-- > > > > --__--__-- > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > > End of En-Nut-Discussion Digest > From Douglas.Pearless at pearless.co.nz Fri Sep 5 06:15:44 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Fri, 05 Sep 2003 16:15:44 +1200 Subject: [En-Nut-Discussion] Querying Ethernut from HTTP In-Reply-To: <009601c373d9$396f5180$5065a8c0@instru.nip.upd.edu.ph> Message-ID: try 192.168.168.101:82 (:82 means port 82, unless you are usign another port!) Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Berns J. Buenaobra Sent: Saturday, 6 September 2003 6:12 a.m. To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] Querying Ethernut from HTTP Hello: Just got my kit two days to go and raring to have it wired in the lab. I can ping the address at 192.168.101.82 but cant http://192.168.101.82/index.htm . How is it done? Berns B. ************************************ Bernardino J. Buenaobra University Research Associate National Institute of Physics University of the Philippines Diliman, Quezon City 1101 Philippines Email: bbuenaobra at nip.upd.edu.ph Tel/Voice: +632-434-4232 Fax/Data: +632-928-0296 Mobile: 0916-2550-056 URL: www.nip.upd.edu.ph/ipl ************************************ ----- Original Message ----- From: To: Sent: Wednesday, September 03, 2003 3:00 AM Subject: En-Nut-Discussion digest, Vol 1 #277 - 1 msg > Send En-Nut-Discussion mailing list submissions to > en-nut-discussion at egnite.de > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.egnite.de/mailman/listinfo/en-nut-discussion > or, via email, send a message with subject or body 'help' to > en-nut-discussion-request at egnite.de > > You can reach the person managing the list at > en-nut-discussion-admin at egnite.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of En-Nut-Discussion digest..." > > > Today's Topics: > > 1. ImageCraft library libnutcrtf.a (Viktor Dvorak) > > --__--__-- > > Message: 1 > From: "Viktor Dvorak" > To: > Date: Tue, 2 Sep 2003 22:26:19 +0200 > Subject: [En-Nut-Discussion] ImageCraft library libnutcrtf.a > Reply-To: en-nut-discussion at egnite.de > > Toto je zprava ve formatu MIME obsahujmcm vmce hastm. > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > Content-Type: text/plain; > charset="iso-8859-2" > Content-Transfer-Encoding: quoted-printable > > Hi,=20 > > building the libnutcrtf.a in/for ImageCraft iccavr is simple. Use = > the content of makefile_gcc for seeing the difference between = > libnutcrt.a and libnutcrtfa.a and make your own library(s). Librarian = > name is ilibw.exe. Compile the sourcecode.c using iccavr and make your = > library usind ilibw -a mylibrary.a myobject.o. > > Viktor > > > > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > Content-Type: text/html; > charset="iso-8859-2" > Content-Transfer-Encoding: quoted-printable > > > > http-equiv=3DContent-Type> > > > > >
Hi,
>
 
>
    building the = > libnutcrtf.a=20 > in/for ImageCraft iccavr is simple. Use the content of makefile_gcc for = > seeing=20 > the difference between libnutcrt.a and libnutcrtfa.a and make your = > own=20 > library(s). Librarian name is ilibw.exe. Compile the sourcecode.c using = > iccavr=20 > and make your library usind ilibw -a mylibrary.a = > myobject.o.
>
 
>
    = > Viktor
>
 
>
 
> > ------=_NextPart_000_0009_01C371A1.3B5F98E0-- > > > > --__--__-- > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > > End of En-Nut-Discussion Digest > _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.514 / Virus Database: 312 - Release Date: 28/08/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.514 / Virus Database: 312 - Release Date: 28/08/2003 From bbuenaobra at nip.upd.edu.ph Fri Sep 5 23:35:12 2003 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Fri, 5 Sep 2003 14:35:12 -0700 Subject: [En-Nut-Discussion] Re: Querying Ethernut from HTTP Message-ID: <00c601c373f5$96b175a0$5065a8c0@instru.nip.upd.edu.ph> Hello: We figured that the PROXY server has to be disabled for this to work. Thanks. Berns B. ************************************ Bernardino J. Buenaobra University Research Associate National Institute of Physics University of the Philippines Diliman, Quezon City 1101 Philippines Email: bbuenaobra at nip.upd.edu.ph Tel/Voice: +632-434-4232 Fax/Data: +632-928-0296 Mobile: 0916-2550-056 URL: www.nip.upd.edu.ph/ipl ************************************ ----- Original Message ----- From: "Berns J. Buenaobra" To: Sent: Friday, September 05, 2003 11:12 AM Subject: Querying Ethernut from HTTP > Hello: > > Just got my kit two days to go and raring to have it wired in the lab. I can > ping the address at 192.168.101.82 but cant http://192.168.101.82/index.htm > . How is it done? > > Berns B. > > > > > ************************************ > Bernardino J. Buenaobra > University Research Associate > National Institute of Physics > University of the Philippines > Diliman, Quezon City 1101 > Philippines > > Email: bbuenaobra at nip.upd.edu.ph > Tel/Voice: +632-434-4232 > Fax/Data: +632-928-0296 > Mobile: 0916-2550-056 > URL: www.nip.upd.edu.ph/ipl > ************************************ > > ----- Original Message ----- > From: > To: > Sent: Wednesday, September 03, 2003 3:00 AM > Subject: En-Nut-Discussion digest, Vol 1 #277 - 1 msg > > > > Send En-Nut-Discussion mailing list submissions to > > en-nut-discussion at egnite.de > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > or, via email, send a message with subject or body 'help' to > > en-nut-discussion-request at egnite.de > > > > You can reach the person managing the list at > > en-nut-discussion-admin at egnite.de > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of En-Nut-Discussion digest..." > > > > > > Today's Topics: > > > > 1. ImageCraft library libnutcrtf.a (Viktor Dvorak) > > > > --__--__-- > > > > Message: 1 > > From: "Viktor Dvorak" > > To: > > Date: Tue, 2 Sep 2003 22:26:19 +0200 > > Subject: [En-Nut-Discussion] ImageCraft library libnutcrtf.a > > Reply-To: en-nut-discussion at egnite.de > > > > Toto je zprava ve formatu MIME obsahujmcm vmce hastm. > > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > > Content-Type: text/plain; > > charset="iso-8859-2" > > Content-Transfer-Encoding: quoted-printable > > > > Hi,=20 > > > > building the libnutcrtf.a in/for ImageCraft iccavr is simple. Use = > > the content of makefile_gcc for seeing the difference between = > > libnutcrt.a and libnutcrtfa.a and make your own library(s). Librarian = > > name is ilibw.exe. Compile the sourcecode.c using iccavr and make your = > > library usind ilibw -a mylibrary.a myobject.o. > > > > Viktor > > > > > > > > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > > Content-Type: text/html; > > charset="iso-8859-2" > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > http-equiv=3DContent-Type> > > > > > > > > > >
Hi,
> >
 
> >
    building the = > > libnutcrtf.a=20 > > in/for ImageCraft iccavr is simple. Use the content of makefile_gcc for = > > seeing=20 > > the difference between libnutcrt.a and libnutcrtfa.a and make your = > > own=20 > > library(s). Librarian name is ilibw.exe. Compile the sourcecode.c using = > > iccavr=20 > > and make your library usind ilibw -a mylibrary.a = > > myobject.o.
> >
 
> >
    = > > Viktor
> >
 
> >
 
> > > > ------=_NextPart_000_0009_01C371A1.3B5F98E0-- > > > > > > > > --__--__-- > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > > > > > End of En-Nut-Discussion Digest > > > From janne.jarvinen at pp8.inet.fi Fri Sep 5 08:53:27 2003 From: janne.jarvinen at pp8.inet.fi (janne.jarvinen at pp8.inet.fi) Date: Fri, 5 Sep 2003 9:53:27 +0300 Subject: [En-Nut-Discussion] Porting Enut to STK300 Message-ID: <20030905065327.CBKO5025.fep05.tmt.tele.fi@fep05> Hi Is there any document or anything about howto port critical parts of Nut/OS to other hardware ? I gave a try to compile example applications for atmega103, but neither "threads" or "simple" did work on stk300 hardware. I am kind of confused which parts belongs to OS and which are for Ethernut board to work... Janne From harald.kipp at egnite.de Fri Sep 5 11:33:49 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 05 Sep 2003 11:33:49 +0200 Subject: [En-Nut-Discussion] Porting Enut to STK300 In-Reply-To: <20030905065327.CBKO5025.fep05.tmt.tele.fi@fep05> Message-ID: <5.1.1.6.0.20030905112823.02dd6008@egnite.de> Hi Janne, there is no hardware dependency other than the CPU and the required 32kHz clock crystal with the samples you tested. They should work on the STK300. As far as I can remember, the STK300 comes with the second crystal, right? Are you sure you compiled and linked ATmega103 code? Did you call ./configure (Linux) or nutconf.exe (Win32)? Harald From janne.jarvinen at pp8.inet.fi Fri Sep 5 14:19:34 2003 From: janne.jarvinen at pp8.inet.fi (janne.jarvinen at pp8.inet.fi) Date: Fri, 5 Sep 2003 15:19:34 +0300 Subject: Vas: Re: [En-Nut-Discussion] Porting Enut to STK300 Message-ID: <20030905121934.CLSR5025.fep05.tmt.tele.fi@fep05> Yes, I have run it in atmega103 mode. What about other services it offers like LCD and UART interfaces ? I tried to configure LCD stuff in medianut configuration file but it didn?t solve anything. > > L?hett?j?: Harald Kipp > P?iv?: 05.09.2003 12:33 > Vastaanottaja: en-nut-discussion at egnite.de > Otsikko: Re: [En-Nut-Discussion] Porting Enut to STK300 > > Hi Janne, > > there is no hardware dependency other than the CPU and > the required 32kHz clock crystal with the samples you > tested. They should work on the STK300. As far as I can > remember, the STK300 comes with the second crystal, right? > > Are you sure you compiled and linked ATmega103 code? Did > you call ./configure (Linux) or nutconf.exe (Win32)? > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > From harald.kipp at egnite.de Fri Sep 5 15:21:48 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 05 Sep 2003 15:21:48 +0200 Subject: Vas: Re: [En-Nut-Discussion] Porting Enut to STK300 In-Reply-To: <20030905121934.CLSR5025.fep05.tmt.tele.fi@fep05> Message-ID: <5.1.1.6.0.20030905152038.02cc4480@egnite.de> > >I tried to configure LCD stuff in medianut configuration file but it >didn?t solve anything. Make sure to call make clean followed by make install in the topmost nut directory if you change any system header. Harald From laran at ikp.liu.se Sat Sep 6 13:16:47 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Sat, 6 Sep 2003 13:16:47 +0200 Subject: [En-Nut-Discussion] Problem with gateway when using DHCP Message-ID: <6D71E1FB451D984081153EC11D7A3DDB91AA6C@mail.ikp.liu.se> I'll try with Ethereal first thing on monday morning. As soon as I have figured Ethereal out I'll get back with the results :) /Lars -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: den 30 augusti 2003 11:51 To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] Problem with gateway when using DHCP Would it be possible to install Ethereal? However, you need to attach both, the PC running Ethereal and the Ethernut board, to a HUB, not an Ethernet switch. Btw. which Nut/OS version do you use? Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From faxel at zoellich.de Sat Sep 6 19:24:44 2003 From: faxel at zoellich.de (=?iso-8859-1?q?Z=F6llich=20Axel?=) Date: Sat, 6 Sep 2003 19:24:44 +0200 Subject: [En-Nut-Discussion] httpd response Message-ID: <200309061924.44449.faxel@zoellich.de> Greetings, I'm using an ethernut board with ATMEGA103. The ethernut-version is 3.3.0. Linux enviroment with avr-gcc. The example apps basemon and httpd both send an response to requests to cgi-bin/... But if I request some file located in the html or sample dir I get an 404 error. The make run builds the urom.c file, compiles it to urom.o and as far as I understand it links it to the .hex file. Any help would be appreciated. Thanks, Axel From unreal at home.nl Mon Sep 8 17:39:55 2003 From: unreal at home.nl (Michel) Date: Mon, 8 Sep 2003 17:39:55 +0200 (CEST) Subject: [En-Nut-Discussion] Ethernet interface not properly booting In-Reply-To: <200309061924.44449.faxel@zoellich.de> References: <200309061924.44449.faxel@zoellich.de> Message-ID: <37135.193.67.187.139.1063035595.squirrel@cp233264-a.dbsch1.nb.home.nl> Hi, I've been working with ethernut for a couple of months now and I'm impressed with it's capabilities and ease of working with it. But now I seem to have some problems with the ethernet interface not booting properly: When I use the reset button (or reboot from within WinAVR) the ethernet device does not get a connection with my switch (a Linksys wireless AP with builtin 4 port 100Mbit switch). When I unplug the 9V and plug it back in the ethernet adapter has no problems getting a link with my switch. And after that I can do some debugging, get UART output, setup an internet connection, etc. So for some reason the ethernet device is not properly reset except at power on. This is very strange because my setup didn't change and it always used to reinitialise without problems. I already tried to give some extra resets but that didn't work. Apparently because I have the 1.3F board where the reset line for ethernet is not connected to any processor I/O. I checked all the cables and found no problems. Does anyone else have this problem? How can I detect in software if ethernet was started ok and then take some action? Greetings, Michel From ethernut at ma.stendahls.net Mon Sep 8 00:17:49 2003 From: ethernut at ma.stendahls.net (Mikael Adolfsson) Date: Mon, 8 Sep 2003 00:17:49 +0200 (CEST) Subject: [En-Nut-Discussion] HTTP QueryString parser Message-ID: Hi, I've made some modifications to the pro/httpd to make it able to parse the QueryString into a decoded table, so you can access form parameters more easily. Feel free to use it, or put it into the Nut/OS source, if you find it usefull. Please note that this code is not tested on the ethernut board. It's only tested on my homebuilt hardware, but should work fine on ethernut as well. In the attached .zip-file, you'll find both the modified source-files and their coresponding patch-files. The added functions are: char *NutHttpURLEncode (char *str); void NutHttpURLDecode (char *str); char *NutHttpGetParameter (REQUEST *req, char *name); int NutHttpGetParameterCount (REQUEST *req); char *NutHttpGetParameterName (REQUEST *req, int index); char *NutHttpGetParameterValue (REQUEST *req, int index); Btw, I have a (very unfinished) smtp-module as well if someone is interested. I've found it usefull to let the board notify me by email on special events etc. At the moment this module can only send simple mails. Mikael -------------- next part -------------- A non-text attachment was scrubbed... Name: httpd_param_patch.zip Type: application/zip Size: 9292 bytes Desc: Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030908/f1d3a4c7/attachment.zip From ngbmoreau at yahoo.com.au Wed Sep 10 00:30:40 2003 From: ngbmoreau at yahoo.com.au (NGB) Date: Wed, 10 Sep 2003 08:30:40 +1000 Subject: [En-Nut-Discussion] Strange problem Message-ID: <1063146640.3f5e5490a6b24@tiger> Hi I recntly upgraded to 3.3 of the library and I'm seeing strange things running the example programs. For starters the board takes for ever to start up !! (this is a customn board, but have worked flwalessly in the past) Once it's up the http server works, but displaying the threads produces an endless list of dummy threads (the first 4 are ok) Considering how the code is written while(tdp) { ... tdp = tdp->td_next; I am suspecting next is never NULL could this be due to the BSS no been cleared on startup ? In case it helps, I am linking the source with these libs: LIBS = $(LIBDIR)/nutinit.o -lnutnet -lnutpro -lnutfs -lnutos -lnutdev -lnutnet -lnutcrt Thanks Nick ------------------------------------------------- From laran at ikp.liu.se Wed Sep 10 18:10:01 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Wed, 10 Sep 2003 18:10:01 +0200 Subject: [En-Nut-Discussion] HTTP QueryString parser Message-ID: <6D71E1FB451D984081153EC11D7A3DDB178738@mail.ikp.liu.se> Hi, I have tried some of your functions and with mixed success. When I do the following operation the processor sometimes hang and most of the time the output strings ook very strange. char *cpn; char *cpv; u_char i; u_char count; count=NutHttpGetParameterCount(req); for (i =0 ; i < count; i++) { cpn=NutHttpGetParameterName(req, i); cpv=NutHttpGetParameterValue(req, i); printf("%s:%s\n\r",cpn,cpv); } please advise, Regards, /Lars -----Original Message----- From: Mikael Adolfsson [mailto:ethernut at ma.stendahls.net] Sent: den 8 september 2003 00:18 To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] HTTP QueryString parser Hi, I've made some modifications to the pro/httpd to make it able to parse the QueryString into a decoded table, so you can access form parameters more easily. Feel free to use it, or put it into the Nut/OS source, if you find it usefull. Please note that this code is not tested on the ethernut board. It's only tested on my homebuilt hardware, but should work fine on ethernut as well. In the attached .zip-file, you'll find both the modified source-files and their coresponding patch-files. The added functions are: char *NutHttpURLEncode (char *str); void NutHttpURLDecode (char *str); char *NutHttpGetParameter (REQUEST *req, char *name); int NutHttpGetParameterCount (REQUEST *req); char *NutHttpGetParameterName (REQUEST *req, int index); char *NutHttpGetParameterValue (REQUEST *req, int index); Btw, I have a (very unfinished) smtp-module as well if someone is interested. I've found it usefull to let the board notify me by email on special events etc. At the moment this module can only send simple mails. Mikael From harald.kipp at egnite.de Wed Sep 10 18:21:27 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 10 Sep 2003 18:21:27 +0200 Subject: [En-Nut-Discussion] Strange problem In-Reply-To: <1063146640.3f5e5490a6b24@tiger> Message-ID: <5.1.1.6.0.20030910181732.01b44c60@egnite.de> Hi Nick, Because you are using a Makefile, I assume GCC, not Imagecraft. May be you need to update your Makefile. Note, that version 3.3 doesn't include main(). GCC handles main() in a strange way, updating the stack pointer again. Have a look to the Makefiles in the app samples. Harald From harald.kipp at egnite.de Wed Sep 10 18:36:16 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 10 Sep 2003 18:36:16 +0200 Subject: [En-Nut-Discussion] Ethernet interface not properly booting In-Reply-To: <37135.193.67.187.139.1063035595.squirrel@cp233264-a.dbsch1 .nb.home.nl> References: <200309061924.44449.faxel@zoellich.de> <200309061924.44449.faxel@zoellich.de> Message-ID: <5.1.1.6.0.20030910182335.01a9ac70@egnite.de> Michel, The opposite case is well known. Power on will fail, if the DS1811 is broken, because the Realtek needs a hardware reset signal. May be the reset switch weared out, producing a bad signal. We replaced the previous Omron through hole reset switch with the Schurter SMD part. Hopefully that wasn't a bad decision. Just today I talked to another user on the phone, who experienced a similar problem. But it fortunately disappeared as sudden as it appeared. He critisized, that there's no RC delay mounted at the reset switch to avoid switching noise and I replied, that there were no problems with it so far...grumble... Anyone else around here with reset switch problems and Rev. 1.3F? Harald From lakab at telia.com Wed Sep 10 20:01:29 2003 From: lakab at telia.com (Lars Andersson) Date: Wed, 10 Sep 2003 20:01:29 +0200 Subject: [En-Nut-Discussion] Ethernet interface not properly booting In-Reply-To: <5.1.1.6.0.20030910182335.01a9ac70@egnite.de> Message-ID: <000001c377c5$8f4ee1c0$0d01a8c0@p3> Maybe you should look at DS1813 to replace DS1811? It debounces the reset push button. I do not have the schematic of version F but I belive it will work on your board w/o modification. Lars H. Andersson (Lots of Lars Anderssons on this group so I put a middle initial in) -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of Harald Kipp Sent: Wednesday, 10 September, 2003 18:36 To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] Ethernet interface not properly booting Michel, The opposite case is well known. Power on will fail, if the DS1811 is broken, because the Realtek needs a hardware reset signal. May be the reset switch weared out, producing a bad signal. We replaced the previous Omron through hole reset switch with the Schurter SMD part. Hopefully that wasn't a bad decision. Just today I talked to another user on the phone, who experienced a similar problem. But it fortunately disappeared as sudden as it appeared. He critisized, that there's no RC delay mounted at the reset switch to avoid switching noise and I replied, that there were no problems with it so far...grumble... Anyone else around here with reset switch problems and Rev. 1.3F? Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From harald.kipp at egnite.de Wed Sep 10 20:15:41 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 10 Sep 2003 20:15:41 +0200 Subject: [En-Nut-Discussion] Ethernet interface not properly booting In-Reply-To: <000001c377c5$8f4ee1c0$0d01a8c0@p3> References: <5.1.1.6.0.20030910182335.01a9ac70@egnite.de> Message-ID: <5.1.1.6.0.20030910200815.01a9adb8@egnite.de> Yes, the DS1813 would have been the better choice. Thanks for the hint. Harald From harald.kipp at egnite.de Wed Sep 10 20:15:35 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 10 Sep 2003 20:15:35 +0200 Subject: [En-Nut-Discussion] httpd response In-Reply-To: <200309061924.44449.faxel@zoellich.de> Message-ID: <5.1.1.6.0.20030910201232.01a0bec0@egnite.de> It has been reported recently, that the CVS version of crurom might be broken. I haven't checked it so far. Here's the part of the email (thanks to Jelle): ----------- The changes to uromfs.c are not correctly working with crurom.exe. Crurom.exe doesn't make a "PSTR filename" in the c file it generates: static ROMENTRY file1entry = { 0, "keyboard.bin", 2002, (prog_char *)file1data }; while I guess it should be: static ROMENTRY file1entry = { 0, PSTR("keyboard.bin"), 2002, (prog_char *)file1data }; (So I'm still running with the old urom for the moment) (The "tricky" part is that the compiler doesn't generate any kind of warning for this error) ----------- From ethernut at ma.stendahls.net Wed Sep 10 21:42:50 2003 From: ethernut at ma.stendahls.net (Mikael Adolfsson) Date: Wed, 10 Sep 2003 21:42:50 +0200 (CEST) Subject: [En-Nut-Discussion] HTTP QueryString parser In-Reply-To: <6D71E1FB451D984081153EC11D7A3DDB178738@mail.ikp.liu.se> Message-ID: Hi, Your code is a correct way of using it. Here are a few things to check: Do you get various results on the same querystring? Does the NutHttpGetParameter(req, name)-method work? Can you see if the mpu hangs before it enters your cgi, or if it hangs on one of the NutHttpGet*-methods? (The querystring is parsed, when NutHttpProcessRequest() finds out that the request contains a questionmark) What version of Nut/OS do you use? The patch I submitted was based on the current Nut/OS 3.3-file, taken from the cvs 7/9. Did you use my httpd.c-file or did you patch your own httpd.c? I first wrote this code for Nut/OS 2.2(?), and I have to admit that I just applied my changes to the 3.3-file. The httpd.c-file is only tested with my modified version of Nut/OS 3.3. As I mentioned before, this code is not tested on the ethernut board; only on my hardare. I will test it further as soon as I get one. / Mikael On Wed, 10 Sep 2003, Lars Andersson wrote: > Hi, > > I have tried some of your functions and with mixed success. > > When I do the following operation the processor sometimes hang and most > of the time the output strings look very strange. > > char *cpn; > char *cpv; > u_char i; > u_char count; > > count=NutHttpGetParameterCount(req); > for (i =0 ; i < count; i++) > { > cpn=NutHttpGetParameterName(req, i); > cpv=NutHttpGetParameterValue(req, i); > printf("%s:%s\n\r",cpn,cpv); > } > > please advise, > > Regards, > /Lars From laran at ikp.liu.se Wed Sep 10 22:33:33 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Wed, 10 Sep 2003 22:33:33 +0200 Subject: [En-Nut-Discussion] HTTP QueryString parser Message-ID: <6D71E1FB451D984081153EC11D7A3DDB178739@mail.ikp.liu.se> Hi Mikael, Sorry for not being specific on the version and HW. I am using Nut/OS 3.3 on a rev-d board. I have found out that the "NutHttpGetParameterCount" function works fine and returns the correct number of parameters. It seams that the mpu makes weird things inside the loop. The output is different for the same query string. I have used the httpd.c and httpd.h files and not patched anything. Do you have any clue on how much memory this process requires compared to the original code. Could it be that I have not dedicated enough memory when starting the thread dong the processing? I'll try this code in a simpler application than I am working on right now and see what happens. Regards, /Lars A Andersson -----Original Message----- From: Mikael Adolfsson [mailto:ethernut at ma.stendahls.net] Sent: den 10 september 2003 21:43 To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] HTTP QueryString parser Hi, Your code is a correct way of using it. Here are a few things to check: Do you get various results on the same querystring? Does the NutHttpGetParameter(req, name)-method work? Can you see if the mpu hangs before it enters your cgi, or if it hangs on one of the NutHttpGet*-methods? (The querystring is parsed, when NutHttpProcessRequest() finds out that the request contains a questionmark) What version of Nut/OS do you use? The patch I submitted was based on the current Nut/OS 3.3-file, taken from the cvs 7/9. Did you use my httpd.c-file or did you patch your own httpd.c? I first wrote this code for Nut/OS 2.2(?), and I have to admit that I just applied my changes to the 3.3-file. The httpd.c-file is only tested with my modified version of Nut/OS 3.3. As I mentioned before, this code is not tested on the ethernut board; only on my hardare. I will test it further as soon as I get one. / Mikael On Wed, 10 Sep 2003, Lars Andersson wrote: > Hi, > > I have tried some of your functions and with mixed success. > > When I do the following operation the processor sometimes hang and most > of the time the output strings look very strange. > > char *cpn; > char *cpv; > u_char i; > u_char count; > > count=NutHttpGetParameterCount(req); > for (i =0 ; i < count; i++) > { > cpn=NutHttpGetParameterName(req, i); > cpv=NutHttpGetParameterValue(req, i); > printf("%s:%s\n\r",cpn,cpv); > } > > please advise, > > Regards, > /Lars _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From ethernut at ma.stendahls.net Wed Sep 10 23:19:14 2003 From: ethernut at ma.stendahls.net (Mikael Adolfsson) Date: Wed, 10 Sep 2003 23:19:14 +0200 (CEST) Subject: [En-Nut-Discussion] HTTP QueryString parser In-Reply-To: <6D71E1FB451D984081153EC11D7A3DDB178739@mail.ikp.liu.se> Message-ID: Hi, hmm, interesting. Since you get the right number of parameters, it sounds like there isn't enough memory left on the stack. Also, if there aren't enough memory on the heap, the parser will stop, and NutHttpGetParameterCount will allways return 0. I'm not sure how much memory is required on the stack, but at least it uses very little memory on the heap. Try allocating more stack. When the query string is parsed, the req->req_query property is overwritten with the parsed data, since the decoded content is allways less or equal the size of req_query (and I guess most users don't need the req_query after that). The only extra allocated memory in the heap are two times the number of parameters in the query string. I just noted also that I'm using register hints on the local variables. Maybe there's a compiler issue here. What compiler/version do you use? I'm using avr-gcc 3.3(20030421). Btw, how long is your querystring in total? Request method+requested file+parameters+version may not be longer than 256 chars. / Mikael On Wed, 10 Sep 2003, Lars Andersson wrote: > Hi Mikael, > > Sorry for not being specific on the version and HW. I am using Nut/OS > 3.3 on a rev-d board. > > I have found out that the "NutHttpGetParameterCount" function works fine > and returns the correct number of parameters. It seams that the mpu > makes weird things inside the loop. The output is different for the same > query string. > > I have used the httpd.c and httpd.h files and not patched anything. > > Do you have any clue on how much memory this process requires compared > to the original code. Could it be that I have not dedicated enough > memory when starting the thread dong the processing? > > I'll try this code in a simpler application than I am working on right > now and see what happens. From ngbmoreau at yahoo.com.au Thu Sep 11 01:53:39 2003 From: ngbmoreau at yahoo.com.au (NGB) Date: Thu, 11 Sep 2003 09:53:39 +1000 Subject: [En-Nut-Discussion] Strange problem In-Reply-To: <5.1.1.6.0.20030910181732.01b44c60@egnite.de> References: <5.1.1.6.0.20030910181732.01b44c60@egnite.de> Message-ID: <1063238019.3f5fb98362b94@tiger> Hi Found the problem, a buffer overflow in another routine was corrupting the thread list !! Thanks Nicolas Quoting Harald Kipp : > Hi Nick, > > Because you are using a Makefile, I assume GCC, not Imagecraft. > May be you need to update your Makefile. Note, that version 3.3 > doesn't include main(). GCC handles main() in a strange way, > updating the stack pointer again. Have a look to the Makefiles > in the app samples. > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > ------------------------------------------------- From leedavies at comtech.uk.com Thu Sep 11 15:51:51 2003 From: leedavies at comtech.uk.com (Lee Davies) Date: Thu, 11 Sep 2003 14:51:51 +0100 Subject: [En-Nut-Discussion] ARM support ??? Message-ID: <002901c3786b$dac54120$4500a8c0@comtech.uk.com> Hello Everyone, I read in earlier thread that an ARM port of the NUT was underway. Have I got the facts right, if so does anybody have any details on when this version will be available and which ARM processor is it using ? Regards, Lee From laran at ikp.liu.se Fri Sep 12 09:59:39 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Fri, 12 Sep 2003 09:59:39 +0200 Subject: [En-Nut-Discussion] HTTP QueryString parser Message-ID: <6D71E1FB451D984081153EC11D7A3DDB17873B@mail.ikp.liu.se> Mikael, I use the same compiler version as you. The query string is also less than 256 chars. I tried to implement similar code to what I explained earlier into the httpd example that comes with the NUT/OS distribution. At first it seemed to work fine, but after a while I noticed that the system was very unstable. It seems that the connection is never closed. Could there be some memory leak? /Lars A Andersson -----Original Message----- From: Mikael Adolfsson [mailto:ethernut at ma.stendahls.net] Sent: den 10 september 2003 23:19 To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] HTTP QueryString parser Hi, hmm, interesting. Since you get the right number of parameters, it sounds like there isn't enough memory left on the stack. Also, if there aren't enough memory on the heap, the parser will stop, and NutHttpGetParameterCount will allways return 0. I'm not sure how much memory is required on the stack, but at least it uses very little memory on the heap. Try allocating more stack. When the query string is parsed, the req->req_query property is overwritten with the parsed data, since the decoded content is allways less or equal the size of req_query (and I guess most users don't need the req_query after that). The only extra allocated memory in the heap are two times the number of parameters in the query string. I just noted also that I'm using register hints on the local variables. Maybe there's a compiler issue here. What compiler/version do you use? I'm using avr-gcc 3.3(20030421). Btw, how long is your querystring in total? Request method+requested file+parameters+version may not be longer than 256 chars. / Mikael On Wed, 10 Sep 2003, Lars Andersson wrote: > Hi Mikael, > > Sorry for not being specific on the version and HW. I am using Nut/OS > 3.3 on a rev-d board. > > I have found out that the "NutHttpGetParameterCount" function works fine > and returns the correct number of parameters. It seams that the mpu > makes weird things inside the loop. The output is different for the same > query string. > > I have used the httpd.c and httpd.h files and not patched anything. > > Do you have any clue on how much memory this process requires compared > to the original code. Could it be that I have not dedicated enough > memory when starting the thread dong the processing? > > I'll try this code in a simpler application than I am working on right > now and see what happens. _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From leedavies at comtech.uk.com Fri Sep 12 18:19:53 2003 From: leedavies at comtech.uk.com (Lee Davies) Date: Fri, 12 Sep 2003 17:19:53 +0100 Subject: [En-Nut-Discussion] ARM support ??? In-Reply-To: <002901c3786b$dac54120$4500a8c0@comtech.uk.com> Message-ID: <002101c37949$b3989280$4500a8c0@comtech.uk.com> I guess not then ??? -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Lee Davies Sent: 11 September 2003 14:52 To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] ARM support ??? Hello Everyone, I read in earlier thread that an ARM port of the NUT was underway. Have I got the facts right, if so does anybody have any details on when this version will be available and which ARM processor is it using ? Regards, Lee _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From harald.kipp at egnite.de Fri Sep 12 18:27:38 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 12 Sep 2003 18:27:38 +0200 Subject: [En-Nut-Discussion] ARM support ??? In-Reply-To: <002101c37949$b3989280$4500a8c0@comtech.uk.com> References: <002901c3786b$dac54120$4500a8c0@comtech.uk.com> Message-ID: <5.1.1.6.0.20030912182557.019f7de0@egnite.de> >I guess not then ??? :-) As far as time allows I'm preparing Nut/OS Version 4, which removes portability issues. But time doesn't allow much at the moment. Harald From peter.scandrett at transport.alstom.com Wed Sep 10 04:48:52 2003 From: peter.scandrett at transport.alstom.com (peter.scandrett at transport.alstom.com) Date: Wed, 10 Sep 2003 12:48:52 +1000 Subject: [En-Nut-Discussion] strtok_r conflicts Message-ID: Hi all, About a month ago there was a lot of comments about my version STRTOK_R and the prototype being different to everyone else's prototype. Attached is my compliant version. I have implemented it because 1. I need the separator functions STRSEP_R and STRSEP_RS. 2. STRTOK_R is not available on other platforms, and I need it there. So enjoy. Here is the test code. The output from STRTOK_R is identical to the Borland version of STRTOK. Peter S Peter Scandrett Engineering Systems Department ALSTOM Australia Limited 3 Bridge Street, Pymble, 2073, Australia Phone (+612) 94 88 49 11 Fax (+612) 94 88 49 00 peter.scandrett at transport.alstom.com :.________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030910/438a5d54/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: STRTOK_R.h Type: application/octet-stream Size: 1040 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030910/438a5d54/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: STRTOK_R.c Type: application/octet-stream Size: 6535 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030910/438a5d54/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Check_STRTOK_R.c Type: application/octet-stream Size: 2048 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030910/438a5d54/attachment-0002.obj From ma at stendahls.net Fri Sep 12 21:20:06 2003 From: ma at stendahls.net (Mikael Adolfsson) Date: Fri, 12 Sep 2003 21:20:06 +0200 (CEST) Subject: [En-Nut-Discussion] Re: smtp over ethernut In-Reply-To: <3F61280C.8050003@digital-telemetry.com> Message-ID: On Fri, 12 Sep 2003, Brett Abbott wrote: > Mikael > > Im very much interested in your prototype smtp code. I was about to > launch into writing a similar module. If you have a chance, I'd love a > copy of the source as it is to date. > Are you expecting to publish it to nut/os? Hi, here is a working prototype. It's quite uggly written, but it fulfills my current needs. I'll probably rewrite it completely in a later date. Currently the whole message body needs to be in ram. I'd rather like it being a stream. / Mikael -------------- next part -------------- /* SMTP module for ECBlite, based on Nut/OS */ #include #include #include #include #include #include #include #include #include static FILE *debugStream; static u_char debugEnabled = 0; /* * Waits for a message, and stores it into buff (mostly to save RAM) */ static int SMTPWaitMessage (FILE *stream, char *buff, int size) { int n; fgets (buff, size, stream); if (debugEnabled) fprintf_P (debugStream, PSTR("SMTP: %s"), buff); /* SMTP messages are allways 3 digits */ if (strlen(buff) < 4 || !isdigit(buff[0]) || !isdigit(buff[1]) || !isdigit(buff[2]) || buff[3] != ' ') { if (debugEnabled) { buff[4] = 0; fprintf_P(debugStream, PSTR("Illegal return code: '%s'\r\n"), strlen(buff)); } return -1; } n = (buff[0]-'0')*100 + (buff[1]-'0')*10 + (buff[2]-'0'); return n; } /* * \todo * Make it possible to write email addresses in the format * 'name
'. * Encode message body - hande specail case with sing dots. * React on 8-bit subjects. * Maybe add support for 7-bit mails with mime-encoding */ static int SMTPTransport (FILE *stream, char *buf, int size, const char *from, const char *to, const char *subject, const char *msg) { /* Wait for '220 servername ESMTP */ if ( SMTPWaitMessage (stream, buf, size) != 220 ) return SMTP_ERR_GREETING; /* Send greeting 'HELO [ip.addr.]' */ fprintf_P (stream, PSTR("HELO [%s]\r\n"), inet_ntoa(confnet.cdn_ip_addr)); fflush (stream); /* Wait for '250 servername' */ if ( SMTPWaitMessage (stream, buf, size) != 250 ) return SMTP_ERR_HELO; /* Send mail request: 'MAIL FROM:' */ fprintf_P (stream, PSTR("MAIL FROM:<%s>\r\n"), from); fflush (stream); /* Wait for '250 ok' */ if ( SMTPWaitMessage (stream, buf, size) != 250 ) return SMTP_ERR_MAILFROM; /* Specify recipients: 'RCPT TO:' */ fprintf_P(stream, PSTR("RCPT TO:<%s>\r\n"), to); fflush (stream); /* Wait for '250 ok' */ if ( SMTPWaitMessage (stream, buf, size) != 250 ) return SMTP_ERR_RCPTTO; /* Send data request: 'DATA' */ fputs_P (PSTR("DATA\r\n"), stream); fflush (stream); /* Wait for '354 go ahead' */ if ( SMTPWaitMessage (stream, buf, size) != 354 ) return SMTP_ERR_DATA; /* Send the encoded message */ fprintf_P (stream, PSTR("From: %s\r\n"), from); fprintf_P (stream, PSTR("To: %s\r\n"), to); fputs_P (PSTR("Content-Type: text/plain; charset=ISO-8859-1\r\n" "Content-Transfer-Encoding: 8BIT\r\n" "MIME-Version: 1.0\r\n"), stream); fprintf_P (stream, PSTR("User-Agent: ECBlite based on Nut/OS %s\r\n"), NutVersionString()); fprintf_P (stream, PSTR("Subject: %s\r\n\r\n"), subject); /* Fix encoding here!!! */ fputs (msg, stream); fputs_P (PSTR("\r\n.\r\n"), stream); fflush (stream); /* Wait for '250 ok' */ if ( SMTPWaitMessage (stream, buf, size) != 250 ) return SMTP_ERR_BODY; /* Exit session */ fputs_P (PSTR("QUIT\r\n"), stream); fflush (stream); // Wait for '221 ok' if ( SMTPWaitMessage (stream, buf, size) != 221 ) return SMTP_ERR_EXIT; return 0; } void SMTPSetDebugStream (FILE *stream) { debugStream = stream; debugEnabled = 1; } void SMTPDisableDebugStream (void) { debugStream = NULL; debugEnabled = 0; } int SMTPSendMail (u_long host, int port, const char *from, const char *to, const char *subject, const char *msg) { TCPSOCKET *sock; FILE *stream; int n; char *buf; const int size = 256; buf = (char *) NutHeapAlloc (size); if (!buf) return SMTP_ERR_OUTOFMEMORY; if ( (sock = NutTcpCreateSocket()) == 0 ) { NutHeapFree (buf); return SMTP_ERR_SOCKETCREATE; } if (!port) port = 25; if ( NutTcpConnect (sock, host, port) ) { NutHeapFree (buf); return SMTP_ERR_CONNECT; } if ( !(stream = _fdopen((int)sock, "r+b")) ) { NutTcpCloseSocket (sock); NutHeapFree (buf); return SMTP_ERR_STREAMCREATE; } /* Keep the error code - we'll have to do the rest anyway */ n = SMTPTransport (stream, buf, size, from, to, subject, msg); fclose(stream); NutTcpCloseSocket (sock); NutHeapFree (buf); return n; } -------------- next part -------------- /* SMTP module for ECBlite, based on Nus/OS */ #ifndef __MOD_SMTP_H #define __MOD_SMTP_H #include #define SMTP_ERR_SOCKETCREATE -1 #define SMTP_ERR_CONNECT -2 #define SMTP_ERR_STREAMCREATE -3 #define SMTP_ERR_OUTOFMEMORY -4 #define SMTP_ERR_GREETING -5 #define SMTP_ERR_HELO -6 #define SMTP_ERR_MAILFROM -7 #define SMTP_ERR_RCPTTO -8 #define SMTP_ERR_DATA -9 #define SMTP_ERR_BODY -10 #define SMTP_ERR_EXIT -11 extern int SMTPSendMail (u_long host, int port, const char *from, const char *to, const char *subject, const char *msg); extern void SMTPSetDebugStream (FILE *stream); extern void SMTPDisableDebugStream (void); #endif From ma at stendahls.net Sat Sep 13 09:59:38 2003 From: ma at stendahls.net (Mikael Adolfsson) Date: Sat, 13 Sep 2003 09:59:38 +0200 (CEST) Subject: [En-Nut-Discussion] HTTP QueryString parser In-Reply-To: <6D71E1FB451D984081153EC11D7A3DDB17873B@mail.ikp.liu.se> Message-ID: Lars, I've found the bug. The NutHttpProcessQueryString allocated too little memory. At row 329 in httpd.c change from req->req_qptrs = (char **)NutHeapAllocClear(sizeof(char *)*req->req_numqptrs); to req->req_qptrs = (char **)NutHeapAllocClear(sizeof(char *)*req->req_numqptrs*2); (double the memory - ofcourse it needs space for a pointer to the param name and one for the value.) / Mikael On Fri, 12 Sep 2003, Lars Andersson wrote: > Mikael, > > I use the same compiler version as you. The query string is also less > than 256 chars. > > I tried to implement similar code to what I explained earlier into the > httpd example that comes with the NUT/OS distribution. At first it > seemed to work fine, but after a while I noticed that the system was > very unstable. It seems that the connection is never closed. > > Could there be some memory leak? > > /Lars A Andersson From laran at ikp.liu.se Mon Sep 15 10:09:10 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Mon, 15 Sep 2003 10:09:10 +0200 Subject: [En-Nut-Discussion] HTTP QueryString parser Message-ID: <6D71E1FB451D984081153EC11D7A3DDB91AA78@mail.ikp.liu.se> Mikael, I have now made the changes to the code and it seems to work fine now. Thank you very much for the contribution of your solution. I think this will make implementation easier in the future! If I notice other strange results from your code I'll get back to you :) By the way, can you please explain, in more detail, the usage of these functions. I looked in the header file but unfortunately that didn't explain it to me. char *NutHttpURLEncode (char *str); void NutHttpURLDecode (char *str); Regards, /Lars A. A. -----Original Message----- From: Mikael Adolfsson [mailto:ma at stendahls.net] Sent: den 13 september 2003 10:00 To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] HTTP QueryString parser Lars, I've found the bug. The NutHttpProcessQueryString allocated too little memory. At row 329 in httpd.c change from req->req_qptrs = (char **)NutHeapAllocClear(sizeof(char *)*req->req_numqptrs); to req->req_qptrs = (char **)NutHeapAllocClear(sizeof(char *)*req->req_numqptrs*2); (double the memory - ofcourse it needs space for a pointer to the param name and one for the value.) / Mikael On Fri, 12 Sep 2003, Lars Andersson wrote: > Mikael, > > I use the same compiler version as you. The query string is also less > than 256 chars. > > I tried to implement similar code to what I explained earlier into the > httpd example that comes with the NUT/OS distribution. At first it > seemed to work fine, but after a while I noticed that the system was > very unstable. It seems that the connection is never closed. > > Could there be some memory leak? > > /Lars A Andersson _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From laran at ikp.liu.se Mon Sep 15 10:46:41 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Mon, 15 Sep 2003 10:46:41 +0200 Subject: [En-Nut-Discussion] Changing password for "cgi-bin" catalog in httpd example Message-ID: <6D71E1FB451D984081153EC11D7A3DDB91AA79@mail.ikp.liu.se> Hi, If I am not mistaking this issue has been brought up before, but I can't find the messages. Anyhow, I am trying to change the user and password for the "cgi-bin" directory in the httpd example. when I change the input parameters to the NutRegisterAuth function I can't get access to the directory. Is there something else that needs to be changed to be able to get this to work? This is what I changed it to: NutRegisterAuth("cgi-bin", "boot:boot"); Regards, /Lars A. A. From ethernut at ma.stendahls.net Mon Sep 15 12:49:17 2003 From: ethernut at ma.stendahls.net (Mikael Adolfsson) Date: Mon, 15 Sep 2003 12:49:17 +0200 (CEST) Subject: [En-Nut-Discussion] HTTP QueryString parser In-Reply-To: <6D71E1FB451D984081153EC11D7A3DDB91AA78@mail.ikp.liu.se> Message-ID: Hi, There is a short doxygen-style description of these functions in httpd.c. In short, they convert a parameter name or value to conform with rfc1738 (see section 2.2). Typically you never have to call NutHttpURLDecode, since it's done internally by the parser. The URLEncode is useful if you for example want to do a link with parameters from your cgi script. Here's an example: char *v = "some strange text &%/+"; /* Typically an unknown string */ char *s = NutHttpURLEncode (v); fprintf_P (stream, PSTR("link"), s); NutHeapFree (s); This will generate a link like this: link Note: char *NutHttpURLEncode(char *s) returns a new allocated string, that must be free'd by the user. void NutHttpURLDecode(char *s) overwrites s (since the decoded string is allways shorter or equal the length of s) / Mikael On Mon, 15 Sep 2003, Lars Andersson wrote: > Mikael, > > I have now made the changes to the code and it seems to work fine now. > Thank you very much for the contribution of your solution. I think this > will make implementation easier in the future! > > By the way, can you please explain, in more detail, the usage of these > functions. I looked in the header file but unfortunately that didn't > explain it to me. > > char *NutHttpURLEncode (char *str); > void NutHttpURLDecode (char *str); From m.kresse at cut5-systemhaus.de Mon Sep 15 14:23:15 2003 From: m.kresse at cut5-systemhaus.de (Martin Kresse) Date: Mon, 15 Sep 2003 14:23:15 +0200 Subject: [En-Nut-Discussion] Mapped memory extension Message-ID: <3F65AF33.80001@cut5-systemhaus.de> Hi, I am pretty much a newbie, not only regarding ethernut but also hardware design in general. Nonetheless I'd like to expand the memory on my Ethernut (revision 1.3 f), so I can do some buffering for playing internet radio. With my limited knowledge, I designed the attached scheme, and I'd be glad, if some experienced person could have a look at it and tell me if this is going to work like I hope it should. The scheme does pretty much what was already suggested by people in this forum: a 16kByte address window controlled by a bank select register. I tried to make it simple, and since I don't know how to move the RTL controller from its base address 0x8300 away, I chose the following memory layout (opposing to what the guide "Memory Considerations" recommends): 0x0000 - 0x7FFF: internal memory etc. 0x8000 - 0xB7FF: memory mapped I/O (e.g. Ethernet controller), segmented in 8 x 2kb regions 0xB800 - 0xBFFF: bank select register 0xC000 - 0xFFFF: bank switched memory window Are there any 512k RAM chips in standard DIL package (easier to solder) ? I'd appreciate any comments - thanks in advance. Sincerely, Martin Kresse -------------- next part -------------- A non-text attachment was scrubbed... Name: mem3.pdf Type: application/pdf Size: 78422 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030915/9fafeb93/attachment.pdf From ethernut at ma.stendahls.net Mon Sep 15 23:41:46 2003 From: ethernut at ma.stendahls.net (Mikael Adolfsson) Date: Mon, 15 Sep 2003 23:41:46 +0200 (CEST) Subject: [En-Nut-Discussion] >64kB code on mega103? Message-ID: Hi, Maybe this isn't the right forum for this question, but does anyone know how (to configure gcc?) to build code larger than 64kB that will work on the mega103 (or mega128)? My software is growing larger, and it doesn't fit in 64k any longer. My static content (prog_char) is quite small and would fit in the lower 64k. Is it possible to let gcc put all that content in the lower 64k, and only code in the upper 64k, so I don't need to mess with the elpm/rampz- instructions? / Mikael From damian at commtech.com.au Tue Sep 16 02:24:29 2003 From: damian at commtech.com.au (Damian Slee) Date: Tue, 16 Sep 2003 08:24:29 +0800 Subject: [En-Nut-Discussion] >64kB code on mega103? Message-ID: gcc should do that anyway? it appears all our PROGMEM strings are linked/allocated first, then program code after that. -----Original Message----- From: Mikael Adolfsson [mailto:ethernut at ma.stendahls.net] Sent: Tuesday, 16 September 2003 5:42 AM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] >64kB code on mega103? Hi, Maybe this isn't the right forum for this question, but does anyone know how (to configure gcc?) to build code larger than 64kB that will work on the mega103 (or mega128)? My software is growing larger, and it doesn't fit in 64k any longer. My static content (prog_char) is quite small and would fit in the lower 64k. Is it possible to let gcc put all that content in the lower 64k, and only code in the upper 64k, so I don't need to mess with the elpm/rampz- instructions? / Mikael _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From damian at commtech.com.au Tue Sep 16 09:39:18 2003 From: damian at commtech.com.au (Damian Slee) Date: Tue, 16 Sep 2003 15:39:18 +0800 Subject: [En-Nut-Discussion] anyone had probs with setting SO_RCVTIMEO causing lockups? Message-ID: u_long opt; // set receive timeout opt = 500; NutTcpSetSockOpt(sock, SO_RCVTIMEO, &opt, sizeof(opt)); for(;;) { rx = NutTcpReceive(sock, rxBuf, 64); seems to lock in NutTcpReceive() forever. other threads no longer function. Removing NutTcpSetSockOpt() fixes it, but data required for NutTcpReceive() to return. if (rx == -1) // socket error? break; ... } From johnny_k76 at yahoo.com Tue Sep 16 10:29:03 2003 From: johnny_k76 at yahoo.com (=?iso-8859-1?q?Johnny=20Karlsson?=) Date: Tue, 16 Sep 2003 10:29:03 +0200 (CEST) Subject: [En-Nut-Discussion] about debugging Message-ID: <20030916082903.15339.qmail@web14909.mail.yahoo.com> Hi, i'm looking at buying an ethernut board for my masters thesis. My question is this, how is debbugging done? I used to program a 68HC11 in school and there we had a hardware emulator to do all the debugging. Does Ethernut have support for on-chip debugging? Best Wishes Johnny Karlsson H?strusk och gr? moln - k?p en resa till solen p? Yahoo! Resor p? adressen http://se.docs.yahoo.com/travel/index.html From harald.kipp at egnite.de Tue Sep 16 10:53:00 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 10:53:00 +0200 Subject: [En-Nut-Discussion] Changing password for "cgi-bin" catalog in httpd example In-Reply-To: <6D71E1FB451D984081153EC11D7A3DDB91AA79@mail.ikp.liu.se> Message-ID: <5.1.1.6.0.20030916105224.01cfd268@egnite.de> > >This is what I changed it to: >NutRegisterAuth("cgi-bin", "boot:boot"); Works fine here. May be a problem with your browser? Harald From harald.kipp at egnite.de Tue Sep 16 11:06:13 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 11:06:13 +0200 Subject: [En-Nut-Discussion] Mapped memory extension In-Reply-To: <3F65AF33.80001@cut5-systemhaus.de> Message-ID: <5.1.1.6.0.20030916105423.01d2fd58@egnite.de> Martin, >0x8000 - 0xB7FF: memory mapped I/O (e.g. Ethernet controller), >segmented in 8 x 2kb regions The advantage of moving memory mapped I/O to upper addresses is, that you can specify additional wait states for this region. >Are there any 512k RAM chips in standard DIL package (easier to solder) ? There are. In Germany you may check Reichelt. But manually soldering SOIC is really easy, even for newbies. Important: Use a lot of flux. Harald From harald.kipp at egnite.de Tue Sep 16 11:18:30 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 11:18:30 +0200 Subject: [En-Nut-Discussion] >64kB code on mega103? In-Reply-To: Message-ID: <5.1.1.6.0.20030916110825.01d28438@egnite.de> Damian, >gcc should do that anyway? >it appears all our PROGMEM strings are linked/allocated first, then >program code after that. Indeed at least GCC version 3.3 does that. It links the .progmem.data segment first. Harald From harald.kipp at egnite.de Tue Sep 16 11:34:42 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 11:34:42 +0200 Subject: [En-Nut-Discussion] about debugging In-Reply-To: <20030916082903.15339.qmail@web14909.mail.yahoo.com> Message-ID: <5.1.1.6.0.20030916111930.01dbc710@egnite.de> Johnny, for Ethernut 1.3 please check: http://www.ethernut.de/en/jtag/jtagconn.html The adapter shown came with our ATJTAGICE. However, the ATJTAGICE costs about 300 US$. Our board manufacturer is currently producing four prototypes of http://savannah.nongnu.org/projects/freeice But it may take months until all hardware and software parts are working flawlessly. Considerations for your shopping plans: Ethernut 2 (yes, we finally start shipping in about two weeks) provides a jumper to select between ISP/JTAG, so no adapter required. Some other advantages: - 512k RAM - 10/100 MBit Ethernet - RS485 Main disadvantages: - Draws about 400 mA - Regulator and Ethernet Controller getting more than warm - Slightly higher price Harald From harald.kipp at egnite.de Tue Sep 16 11:41:11 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 11:41:11 +0200 Subject: [En-Nut-Discussion] anyone had probs with setting SO_RCVTIMEO causing lockups? In-Reply-To: Message-ID: <5.1.1.6.0.20030916113524.01d776b8@egnite.de> Damian, We are using socket timeouts in most of our own applications. Because of a bug in timer handling, make sure to keep the timeout above 62 millisecs. This is also true for NutSleep(). 90% of lockups are caused by loops without NutThreadYield(). (Just in case: If you are calling input or NutSleep() functions in your loop, NutTreadYield() is not required.) Harald From harald.kipp at egnite.de Tue Sep 16 12:16:11 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 12:16:11 +0200 Subject: [En-Nut-Discussion] WinAVR: Using uisp with Ethernut's STK500 dongle Message-ID: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> The uisp version, which comes with the latest WinAVR release WinAVR-20030913, works fine with the serial port dongle included in the Starter Kit. Two entries in UserConf.mk need to be changed: BURN=c:\WinAVR\bin\uisp.exe BURNFLAGS=-dprog=stk500 -dserial=/dev/ttyS0 -dpart=$(MCU) --erase --upload if=$(TARG) Note, that nutconf will override UserConf.mk. Harald From ralf at spettel.de Tue Sep 16 19:22:29 2003 From: ralf at spettel.de (Ralf Spettel) Date: Tue, 16 Sep 2003 19:22:29 +0200 Subject: [En-Nut-Discussion] Close TCP connection if cable disconnected Message-ID: <5.1.1.6.2.20030916191725.00a71be8@pop.1und1.com> Hi, what's the best way to close the TCP connection if the thread waits with NutTcpReceive() for data and the network-cable was removed or the (any) router failed. If I pluging in the cable again, no TCP connection is possible. Thx, Ralf From jjj at iki.fi Tue Sep 16 22:17:32 2003 From: jjj at iki.fi (Janne Jarvinen) Date: Tue, 16 Sep 2003 23:17:32 +0300 Subject: [En-Nut-Discussion] Nut/OS in STK300 In-Reply-To: <3F65AF33.80001@cut5-systemhaus.de> Message-ID: <000c01c37c8f$927a6c10$6901a8c0@thinkpad> Hi Any hints what do I need to change in order to get UART to work in STK300 meaning in ATMega103 generally ? Is it necessary to enable this flag for example? (STK300 is 4MHz) DEFS = -DNUT_CPU_FREQ=3686400 I saw some comment in sources about this being for 1ms resolution enable, but what if it is not defined ? Does it make timers&rtc still to work but with worse resolution ? Currently app/threads works nicely with 3 different threads blinking leds with specific speed defined differetnly for each threads. However, LCD and UART shows random rubbish only ... For LCD I have redefined different port setup without any help. For UART(chip hw uart) I couldn?t find really anything to change. I set nutconf to stk200 and atmega103. Whatever stk200 then defines, I have no idea. BR, Janne From spm at iteso.mx Tue Sep 16 22:26:10 2003 From: spm at iteso.mx (Sergio Palacios Macias) Date: Tue, 16 Sep 2003 15:26:10 -0500 Subject: [En-Nut-Discussion] Not using Ethernut but using the RTL8019as, can you help me out? Message-ID: <1063743970.3f6771e2e6ddd@iteso.mx> Hello, If i'm developing an embedded project that is not directly related with the Ethernut but it is with the RTL8019as, could you help me out? Thanks pd. The project cosists of an RTL8019as ISA-card interfaced to an 8051 microcontroller. --- From jjj at iki.fi Tue Sep 16 22:34:42 2003 From: jjj at iki.fi (Janne Jarvinen) Date: Tue, 16 Sep 2003 23:34:42 +0300 Subject: [En-Nut-Discussion] Not using Ethernut but using the RTL8019as, can you help me out? In-Reply-To: <1063743970.3f6771e2e6ddd@iteso.mx> Message-ID: <000d01c37c91$f8e894c0$6901a8c0@thinkpad> What is the thing you are asking or needing really? There is spec for RTL8019 available if you just get it by Google and there is Ethernut drivers as c source codes to look for examples ... Janne > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of > Sergio Palacios Macias > Sent: 16. syyskuuta 2003 23:26 > To: en-nut-discussion at egnite.de > Subject: [En-Nut-Discussion] Not using Ethernut but using the > RTL8019as, can you help me out? > > > > Hello, If i'm developing an embedded project that is not > directly related with > the Ethernut but it is with the RTL8019as, could you help me out? > > Thanks > > pd. The project cosists of an RTL8019as ISA-card interfaced > to an 8051 > microcontroller. > > --- > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-> discussion > From Douglas.Pearless at pearless.co.nz Wed Sep 17 01:46:00 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Wed, 17 Sep 2003 11:46:00 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: Message-ID: Hi People, I'd appreciate some comments. I have an Oxford quad UART mapped into 0xFF00 to 0xFFFF I cannot seem to be able to read or write to it. I have checked the hardware carefully (famous last words...) and neither the RD\ nor WR\ lines seem to change, or at least may be they are changing too fast for my logic probe. Does this code cover what it needs to in order to be able to access the Oxford chip (note that I am using UART0 on the Ethernut for comms and debug!) Cheers Douglas #define UARTQUAD_BASE 0xFF00 #define UARTQUAD_DLL 0x008 #define uartquad_read(reg) *(base + (reg)) #define uartquad_write(reg, data) *(base + (reg)) = data #include #include #include #include #include static char *banner = "\nNut/OXFORD UART Sample\n"; static char inbuf[128]; int main(void) { int got; int i,j,k; char *cp; u_long baud = 115200; FILE *uart; float dval = 0.0; u_long TWI_speed; volatile u_char *base = (u_char *) UARTQUAD_BASE; /* * Enable external data and address * bus. */ outp(BV(SRE) | BV(SRW), MCUCR); NutRegisterDevice(&devUart0, 0, 0); uart = fopen("uart0", "r+"); _ioctl(_fileno(uart), UART_SETSPEED, &baud); NutSleep(200); _write(_fileno(uart), banner, strlen(banner)); _write(_fileno(uart), 0, 0); for(i = 0;; i++) { fputs("\nPress Enter", uart); fflush(uart); fgets(inbuf, sizeof(inbuf), uart); j = uartquad_read(UARTQUAD_DLL); fprintf(uart, "\ni = %x : READ UARTQUAD_DLL = %x\n", i,j); fflush(uart); /* set it to 0x20 */ j = 0x20; uartquad_write(UARTQUAD_DLL,j); /* did it work ?*/ k = uartquad_read(UARTQUAD_DLL); fprintf(uart, "\n UARTQUAD_DLL = %x\n", k); fflush(uart); } } --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From damian at commtech.com.au Wed Sep 17 05:02:11 2003 From: damian at commtech.com.au (Damian Slee) Date: Wed, 17 Sep 2003 11:02:11 +0800 Subject: [En-Nut-Discussion] media sense/cable detect Message-ID: Hi all, has anyone looked at media sense to detect if the cable is unplugged, like Windows2000/XP? When the cable is unplugged all TCP connections can be flaged as closed. Does anyone know if the "Carrier sense lost" bit in the RTL8019 status register indicates the state of the link LED? Commtech Wireless www.commtech.com.au (Australia) www.commtechwireless.com (USA) PO Box 1037 OPDC WA 6916 Ph:+61 8 9242 5651 Fax:+61 8 9242 5652 Confidentiality/Limited Liability Statement This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message, you must not disseminate, copy or take any action in reliance on it. If you have received this message in error, please notify Commtech Wireless Pty Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Commtech Wireless. Additionally if prices are quoted in this document then you may consider this document to be an official quotation and the prices quoted are valid for a period of fourteen days from the date of this document. From damian at commtech.com.au Wed Sep 17 07:29:50 2003 From: damian at commtech.com.au (Damian Slee) Date: Wed, 17 Sep 2003 13:29:50 +0800 Subject: [En-Nut-Discussion] anyone had probs with setting SO_RCVTIMEO causing lockups? Message-ID: Turned out to be a really wierd problem with a call to memcpy_P() in my code. Despite using it else where in the same thread, this instance caused strange problems. Replaced it with two _LPM() calls, and I am not having the problem now? Using GCC 3.3. -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Tuesday, 16 September 2003 5:41 PM To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] anyone had probs with setting SO_RCVTIMEO causing lockups? Damian, We are using socket timeouts in most of our own applications. Because of a bug in timer handling, make sure to keep the timeout above 62 millisecs. This is also true for NutSleep(). 90% of lockups are caused by loops without NutThreadYield(). (Just in case: If you are calling input or NutSleep() functions in your loop, NutTreadYield() is not required.) Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From harald.kipp at egnite.de Wed Sep 17 09:33:00 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 17 Sep 2003 09:33:00 +0200 Subject: [En-Nut-Discussion] Close TCP connection if cable disconnected In-Reply-To: <5.1.1.6.2.20030916191725.00a71be8@pop.1und1.com> Message-ID: <5.1.1.6.0.20030917092931.023ebbf0@egnite.de> Hi Ralf, Not just the best but the only way is to use a timeout. Are you sure, that unplugging and replugging again causes the problem? It may be because your app allows one connection only. Harald From harald.kipp at egnite.de Wed Sep 17 09:40:45 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 17 Sep 2003 09:40:45 +0200 Subject: [En-Nut-Discussion] Nut/OS in STK300 In-Reply-To: <000c01c37c8f$927a6c10$6901a8c0@thinkpad> References: <3F65AF33.80001@cut5-systemhaus.de> Message-ID: <5.1.1.6.0.20030917093413.024aa160@egnite.de> Hi Janne, >Any hints what do I need to change in order to get UART to work in >STK300 meaning in ATMega103 generally ? > >Is it necessary to enable this flag for example? (STK300 is 4MHz) >DEFS = -DNUT_CPU_FREQ=3686400 This definition is only required if the 32kHz crystal is not mounted. >I saw some comment in sources about this being for 1ms resolution >enable, but what if it is not defined ? Does it make timers&rtc still to >work but with worse resolution ? If NUT_CPU_FREQ is not defined, the resolution is 62.5 ms, using the 32 kHz crystal. Taking this as a reference, Ethernut is able to determine its main crystal frequency. >Currently app/threads works nicely with 3 different threads blinking >leds with specific speed defined differetnly for each threads. However, >LCD and UART shows random rubbish only ... For LCD it may be a hardware timing problem. For the UART, check the baudrate table in the ATmega datasheet, specially the deviation. >I set nutconf to stk200 and atmega103. Whatever stk200 then defines, I >have no idea. The STK200 defines the type of programming adapter you're using. This definition enables to simply call make burn on the command line. Harald From harald.kipp at egnite.de Wed Sep 17 09:48:17 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 17 Sep 2003 09:48:17 +0200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: References: Message-ID: <5.1.1.6.0.20030917094134.024ac810@egnite.de> Hi Douglas, >Does this code cover what it needs to in order to be able to access the >Oxford chip (note that I am using UART0 on the Ethernut for comms and >debug!) Not at all. You need to write a new device driver for the QUART, the registers are definitely different from the one used by uartavr. Harald From harald.kipp at egnite.de Wed Sep 17 09:56:53 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 17 Sep 2003 09:56:53 +0200 Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: Message-ID: <5.1.1.6.0.20030917094830.024a4438@egnite.de> Hi Damian, >has anyone looked at media sense to detect if the cable is unplugged, like >Windows2000/XP? > >When the cable is unplugged all TCP connections can be flaged as closed. Does Windows do this? TCP rules define, that a connection should _not_ be closed on lower level problems. The application may close the connection on transmit failures. If one node is receiving and the remote is switched off, the receiver will never detect the loss. It may use a socket timeout (supported by Nut/Net) or set the KEEPALIVE option (not supported by Nut/Net). Beside that, it would still make a lot of sense to detect a link loss, but I never tried. Anyone else? Harald From Douglas.Pearless at pearless.co.nz Wed Sep 17 11:43:07 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Wed, 17 Sep 2003 21:43:07 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: <5.1.1.6.0.20030917094134.024ac810@egnite.de> Message-ID: Hi Harald, I have started to do that too, but it is a bit of a learning curve! I am just trying to prove that I can access the device at this point, but cannot seem to. My question is around, if the hardware is OK, then is the software OK as a test to prove I can see the hardware. Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Harald Kipp Sent: Wednesday, 17 September 2003 7:48 p.m. To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut Hi Douglas, >Does this code cover what it needs to in order to be able to access the >Oxford chip (note that I am using UART0 on the Ethernut for comms and >debug!) Not at all. You need to write a new device driver for the QUART, the registers are definitely different from the one used by uartavr. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From harald.kipp at egnite.de Wed Sep 17 12:17:32 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 17 Sep 2003 12:17:32 +0200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: References: <5.1.1.6.0.20030917094134.024ac810@egnite.de> Message-ID: <5.1.1.6.0.20030917121211.01a0f188@egnite.de> Douglas, I'd suggest to write a simple program first (no Nut/OS!) and use outb and inb statements to access the hardware. 1. Initialize QUART registers 2. Try to output one character 3. Test interrupts After this is working fine, you should be ready to modify uartavr.c. Btw. I recommend to use a different file. Do not intend to make uartavr.c working with both devices, on-chip UART and external QUAD. Harald From Douglas.Pearless at pearless.co.nz Wed Sep 17 12:36:46 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Wed, 17 Sep 2003 22:36:46 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: <5.1.1.6.0.20030917121211.01a0f188@egnite.de> Message-ID: Hi Harald, Thanks for the feedback. I am creating a new file, rather than modifing uartavr.c. cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Harald Kipp Sent: Wednesday, 17 September 2003 10:18 p.m. To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut Douglas, I'd suggest to write a simple program first (no Nut/OS!) and use outb and inb statements to access the hardware. 1. Initialize QUART registers 2. Try to output one character 3. Test interrupts After this is working fine, you should be ready to modify uartavr.c. Btw. I recommend to use a different file. Do not intend to make uartavr.c working with both devices, on-chip UART and external QUAD. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From Brett.Abbott at digital-telemetry.com Wed Sep 17 12:54:59 2003 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Wed, 17 Sep 2003 22:54:59 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford References: <20030917100001.9254.81892.Mailman@p15095813.pureserver.info> Message-ID: <3F683D83.7060806@digital-telemetry.com> > > >Doug > The uart is memory mapped. Try a couple of things... Try using NutCritical around the functions. You may find that the memory is getting zapped by other calculations.... Going NutCritical will stop interupts and other stuff (NutEnterCritical()) NutExitCritical() Also, try using direct memory reads and writes: be explicit with addresses rather than formulas. perhaps achieve this with inline assembler. Have a look at the ethernet nic drivers as an example. Cheers Brett From m.kresse at cut5-systemhaus.de Wed Sep 17 13:16:01 2003 From: m.kresse at cut5-systemhaus.de (Martin Kresse) Date: Wed, 17 Sep 2003 13:16:01 +0200 Subject: [En-Nut-Discussion] Mapped memory extension Message-ID: <3F684271.1030909@cut5-systemhaus.de> >>0x8000 - 0xB7FF: memory mapped I/O (e.g. Ethernet controller), >>segmented in 8 x 2kb regions >The advantage of moving memory mapped I/O to upper addresses >is, that you can specify additional wait states for this >region. I feared that. Does the IDE extension using the XC9572 need any waitstates? Is there any way to move the base address of the NIC controller of an existing Ethernut 1.3 into the 0xC000-0xFFFF range? Martin From jjj at iki.fi Wed Sep 17 18:50:54 2003 From: jjj at iki.fi (Janne Jarvinen) Date: Wed, 17 Sep 2003 19:50:54 +0300 Subject: [En-Nut-Discussion] Nut/OS in STK300 In-Reply-To: <5.1.1.6.0.20030917093413.024aa160@egnite.de> Message-ID: <002e01c37d3b$df090a80$6901a8c0@thinkpad> Thanks Harald You were absolutely right about UART diveder. I replaced UBBR line by my own manual setup and it worked just fine. Now I can finally debug scheduling of the example program :) What about LCD then, you mentioned hw timing.. I have HD44780 based display connected straight to the PORTA pins, no extra components except contrast pot. For whatkind of connection lcd-driver is designed ? I have used Peter Fleury?s (http://www.mysunrise.ch/users/pfleury/avr-lcd44780.html) way to access LCD but I would like to use Nut?s own drivers of course. If it is aimed to connect straight to the pins aswell then only thing I could imagine is timing difference caused by een 4MHz / 14MHz cpu clock difference ...? Janne > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of Harald Kipp > Sent: 17. syyskuuta 2003 10:41 > To: en-nut-discussion at egnite.de > Subject: Re: [En-Nut-Discussion] Nut/OS in STK300 > > > Hi Janne, > > > >Any hints what do I need to change in order to get UART to work in > >STK300 meaning in ATMega103 generally ? > > > >Is it necessary to enable this flag for example? (STK300 is > 4MHz) DEFS > >= -DNUT_CPU_FREQ=3686400 > > This definition is only required if the 32kHz crystal is not mounted. > > >I saw some comment in sources about this being for 1ms resolution > >enable, but what if it is not defined ? Does it make > timers&rtc still > >to work but with worse resolution ? > > If NUT_CPU_FREQ is not defined, the resolution is 62.5 ms, > using the 32 kHz crystal. Taking this as a reference, > Ethernut is able to determine its main crystal frequency. > > > >Currently app/threads works nicely with 3 different threads blinking > >leds with specific speed defined differetnly for each > threads. However, > >LCD and UART shows random rubbish only ... > > For LCD it may be a hardware timing problem. For the > UART, check the baudrate table in the ATmega datasheet, > specially the deviation. > > > >I set nutconf to stk200 and atmega103. Whatever stk200 then > defines, I > >have no idea. > > The STK200 defines the type of programming adapter you're > using. This definition enables to simply call > > make burn > > on the command line. > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-> discussion > From ceba at vabo.cz Wed Sep 17 20:05:08 2003 From: ceba at vabo.cz (Pavel Celeda) Date: 17 Sep 2003 20:05:08 +0200 Subject: [En-Nut-Discussion] WinAVR: Using uisp with Ethernut's STK500 dongle In-Reply-To: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> References: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> Message-ID: <1063821908.2278.47.camel@hw.vabo.cz> > The uisp version, which comes with the latest WinAVR release > WinAVR-20030913, works fine with the serial port dongle > included in the Starter Kit. Two entries in UserConf.mk need > to be changed: > > BURN=c:\WinAVR\bin\uisp.exe > BURNFLAGS=-dprog=stk500 -dserial=/dev/ttyS0 -dpart=$(MCU) --erase --upload > if=$(TARG) > > Note, that nutconf will override UserConf.mk. I'm using Ethernut's STK500 dongle firmware 1.14, uisp from WinAVR-20030913 and can't program ATmega128 correctly. If I use Ethernut's STK500 dongle with AVR studio everything works OK. I have replaced the Ethernut's STK500 dongle with STK500 Protocol AVR Bootloader - http://avr1.org/stk500boot/stk500boot.html and UISP works fine. Which version of dongle firmware are you using ? Pavel From tex at off.org Wed Sep 17 20:25:39 2003 From: tex at off.org (Austin Schutz) Date: Wed, 17 Sep 2003 11:25:39 -0700 Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: <5.1.1.6.0.20030917094830.024a4438@egnite.de>; from harald.kipp@egnite.de on Wed, Sep 17, 2003 at 09:56:53AM +0200 References: <5.1.1.6.0.20030917094830.024a4438@egnite.de> Message-ID: <20030917112539.L2732@gblx.net> On Wed, Sep 17, 2003 at 09:56:53AM +0200, Harald Kipp wrote: > Hi Damian, > > > >has anyone looked at media sense to detect if the cable is unplugged, like > >Windows2000/XP? > > > >When the cable is unplugged all TCP connections can be flaged as closed. > > Does Windows do this? > > TCP rules define, that a connection should _not_ be closed on lower > level problems. The application may close the connection on > transmit failures. > > If one node is receiving and the remote is switched off, the > receiver will never detect the loss. It may use a socket timeout > (supported by Nut/Net) or set the KEEPALIVE option (not supported > by Nut/Net). > > Beside that, it would still make a lot of sense to detect a link > loss, but I never tried. Anyone else? > If the link is down it should flag packets going to that interface with an icmp network unreachable, or something like that. The received icmp should be interpreted by the device as being a good reason to close the connection. Or something like that. I'm not _that_ familiar with the exact method. Austin From ralph.mason at telogis.com Wed Sep 17 20:57:47 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Thu, 18 Sep 2003 06:57:47 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: Message-ID: To save yourself some work and codespace I suggest you use the 'virtualised' AVR uart if possible from nut os. I wrote a 16550 driver in a few hours that way. Here is my declaration, you can see how much of the avr driver I used static UARTDCB dcb_uarta; NUTDEVICE devUartA = { 0, /*!< Pointer to next device. */ {'u', 'a', 'r', 't', 'a', 0, 0, 0, 0}, /*!< Unique device name. */ IFTYP_STREAM, /*!< Type of device. */ (u_char*)0xf900, /*!< Base address. */ 4, /*!< First interrupt number. */ 0, /*!< Interface control block. */ &dcb_uarta, /*!< Driver control block. */ UartExtInit, /*!< Driver initialization routine. */ UartExtIOCtl, /*!< Driver specific control function. */ UartAvrRead, UartAvrWrite, UartAvrWrite_P, UartAvrOpen, UartAvrClose }; THere are only 2 of my own functions there. In the init I setup the stream (so that the memory for it can be allocated from the heap) and put my own stream handler functions in. int UartExtInit(NUTDEVICE *dev) { IFSTREAM *ifs; //Already done if ( dev->dev_icb ) return 0; ifs = NutHeapAllocClear(sizeof(IFSTREAM)); dev->dev_icb = ifs; ifs->if_input = UartAvrInput; ifs->if_output = UartExtOutput; ifs->if_flush = UartAvrFlush; /* * Initialize driver control block. */ memset(dev->dev_dcb, 0, sizeof(UARTDCB)); Init16550((volatile u_char*)dev->dev_base,38400); So you can see, I only provided 3 functions to the driver(UartExtOutput,UartExtInit,UartExtInit) and my own interupt handler. Hope this is of some help Regards Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Pearless > Sent: Wednesday, 17 September 2003 10:37 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford > Quad UART) device to an EtherNut > > > Hi Harald, > > Thanks for the feedback. > > I am creating a new file, rather than modifing uartavr.c. > > cheers Douglas > > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Harald Kipp > Sent: Wednesday, 17 September 2003 10:18 p.m. > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford > Quad UART) device to an EtherNut > > > Douglas, > > I'd suggest to write a simple program first (no Nut/OS!) > and use outb and inb statements to access the hardware. > > 1. Initialize QUART registers > 2. Try to output one character > 3. Test interrupts > > After this is working fine, you should be ready to modify > uartavr.c. Btw. I recommend to use a different file. Do not > intend to make uartavr.c working with both devices, on-chip > UART and external QUAD. > > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 From troth at openavr.org Wed Sep 17 21:51:18 2003 From: troth at openavr.org (Theodore A. Roth) Date: Wed, 17 Sep 2003 12:51:18 -0700 (PDT) Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: <20030917112539.L2732@gblx.net> References: <5.1.1.6.0.20030917094830.024a4438@egnite.de> <20030917112539.L2732@gblx.net> Message-ID: On Wed, 17 Sep 2003, Austin Schutz wrote: > On Wed, Sep 17, 2003 at 09:56:53AM +0200, Harald Kipp wrote: > > Hi Damian, > > > > > > >has anyone looked at media sense to detect if the cable is unplugged, like > > >Windows2000/XP? > > > > > >When the cable is unplugged all TCP connections can be flaged as closed. > > > > Does Windows do this? > > > > TCP rules define, that a connection should _not_ be closed on lower > > level problems. The application may close the connection on > > transmit failures. > > > > If one node is receiving and the remote is switched off, the > > receiver will never detect the loss. It may use a socket timeout > > (supported by Nut/Net) or set the KEEPALIVE option (not supported > > by Nut/Net). > > > > Beside that, it would still make a lot of sense to detect a link > > loss, but I never tried. Anyone else? > > > > If the link is down it should flag packets going to that interface > with an icmp network unreachable, or something like that. The received icmp > should be interpreted by the device as being a good reason to close the > connection. Or something like that. I'm not _that_ familiar with the > exact method. There's an excellant discussion of this in the Introduction section of chapter 23 ("TCP Keepalive Timer") in Stevens "TCP Illustrated Vol 1." Is it possible to tell the difference between the cable being disconnected and the hub/switch/router losing power temporarily? Ted Roth From Douglas.Pearless at pearless.co.nz Wed Sep 17 22:17:44 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Thu, 18 Sep 2003 08:17:44 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: Message-ID: Hi Ralph, Thanks!!!! Your code has cleared up some of the workings of the UART device drivers for me. Would you consider sharing the UartExtOutput and UartExtInit code too? A question for all those on the list, has any one written device drivers where they share an interrupt? I am expecting for my interrupt handler for the 4 uarts to first check to see which uart has generated the interrupt and then perform the appropriate task. Might prove to be a bit tricky? Any comments? Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Ralph Mason Sent: Thursday, 18 September 2003 6:58 a.m. To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut To save yourself some work and codespace I suggest you use the 'virtualised' AVR uart if possible from nut os. I wrote a 16550 driver in a few hours that way. Here is my declaration, you can see how much of the avr driver I used static UARTDCB dcb_uarta; NUTDEVICE devUartA = { 0, /*!< Pointer to next device. */ {'u', 'a', 'r', 't', 'a', 0, 0, 0, 0}, /*!< Unique device name. */ IFTYP_STREAM, /*!< Type of device. */ (u_char*)0xf900, /*!< Base address. */ 4, /*!< First interrupt number. */ 0, /*!< Interface control block. */ &dcb_uarta, /*!< Driver control block. */ UartExtInit, /*!< Driver initialization routine. */ UartExtIOCtl, /*!< Driver specific control function. */ UartAvrRead, UartAvrWrite, UartAvrWrite_P, UartAvrOpen, UartAvrClose }; THere are only 2 of my own functions there. In the init I setup the stream (so that the memory for it can be allocated from the heap) and put my own stream handler functions in. int UartExtInit(NUTDEVICE *dev) { IFSTREAM *ifs; //Already done if ( dev->dev_icb ) return 0; ifs = NutHeapAllocClear(sizeof(IFSTREAM)); dev->dev_icb = ifs; ifs->if_input = UartAvrInput; ifs->if_output = UartExtOutput; ifs->if_flush = UartAvrFlush; /* * Initialize driver control block. */ memset(dev->dev_dcb, 0, sizeof(UARTDCB)); Init16550((volatile u_char*)dev->dev_base,38400); So you can see, I only provided 3 functions to the driver(UartExtOutput,UartExtInit,UartExtInit) and my own interupt handler. Hope this is of some help Regards Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Pearless > Sent: Wednesday, 17 September 2003 10:37 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford > Quad UART) device to an EtherNut > > > Hi Harald, > > Thanks for the feedback. > > I am creating a new file, rather than modifing uartavr.c. > > cheers Douglas > > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Harald Kipp > Sent: Wednesday, 17 September 2003 10:18 p.m. > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford > Quad UART) device to an EtherNut > > > Douglas, > > I'd suggest to write a simple program first (no Nut/OS!) > and use outb and inb statements to access the hardware. > > 1. Initialize QUART registers > 2. Try to output one character > 3. Test interrupts > > After this is working fine, you should be ready to modify > uartavr.c. Btw. I recommend to use a different file. Do not > intend to make uartavr.c working with both devices, on-chip > UART and external QUAD. > > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From spm at iteso.mx Wed Sep 17 23:20:35 2003 From: spm at iteso.mx (Sergio Palacios Macias) Date: Wed, 17 Sep 2003 16:20:35 -0500 Subject: [En-Nut-Discussion] Not using Ethernut but using the RTL8019as, can you help me out? In-Reply-To: <000d01c37c91$f8e894c0$6901a8c0@thinkpad> References: <000d01c37c91$f8e894c0$6901a8c0@thinkpad> Message-ID: <1063833635.3f68d023d487e@iteso.mx> As I said, I'm developing a school project that consists to interface an 8051 with an rtl8019 isa-card. I've done al the wiring between both devices and I checked all the connections and they all seem to be right. For testing good communication between the nic and the uC I did a program that initializes the nic and then access the mac address from the card to store such address in to de microcontroller but finally I get no response from the card at all. I?ve checked several times every signal to and from the nic and they all look ok but nothing seems to happen, no data comes out from the isa-card. For developing this project I was based on the datasheets for the rtl8019 and also for the dp8390. I also have checked out many projects (embeddedethernet, the one that is at 8052 web page, Sx Stack, web51, the packet whacker, Ethernut of course, etc) and in theory my hardware and software should work but they don?t. Any tip? Sergio Quoting Janne Jarvinen : > What is the thing you are asking or needing really? There is spec for > RTL8019 available if you just get it by Google and there is Ethernut > drivers as c source codes to look for examples ... > > Janne > > > > > -----Original Message----- > > From: en-nut-discussion-admin at egnite.de > > [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of > > Sergio Palacios Macias > > Sent: 16. syyskuuta 2003 23:26 > > To: en-nut-discussion at egnite.de > > Subject: [En-Nut-Discussion] Not using Ethernut but using the > > RTL8019as, can you help me out? > > > > > > > > Hello, If i'm developing an embedded project that is not > > directly related with > > the Ethernut but it is with the RTL8019as, could you help me out? > > > > Thanks > > > > pd. The project cosists of an RTL8019as ISA-card interfaced > > to an 8051 > > microcontroller. > > > > --- > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo/en-nut-> discussion > > > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > --- From s354335 at student.uq.edu.au Thu Sep 18 00:30:45 2003 From: s354335 at student.uq.edu.au (Toby Smith) Date: Thu, 18 Sep 2003 08:30:45 +1000 (GMT+1000) Subject: [En-Nut-Discussion] i2c on ethernut Message-ID: I'm looking at interfacing my ethernut board to some external i2c devices. IU know the atmega128 has a built in TWI module, but my board has an atmega103. I need the ethernut to act as master in a single master i2c network. Perhaps this question is a little open ended, but does anyone have any tips or pointers on where to start with writing some code to get this happening? --Toby From ngbmoreau at yahoo.com.au Thu Sep 18 03:13:16 2003 From: ngbmoreau at yahoo.com.au (NGB) Date: Thu, 18 Sep 2003 11:13:16 +1000 Subject: [En-Nut-Discussion] New winavr avr-libc 0.99.90.20030829 Message-ID: <1063847596.3f6906ac743a8@tiger> Hi I have been testing the new winavr with avr-libc 0.99.90.20030829, there are a few problems building ethernut now: 1-XRAM end is defined in iom128.h that creates a conflict with nutinit.c, I'm not sure why XRAMEND would be defined in iom128.h as this should be application specific ! in the mean while I did this #include #ifdef XRAMEND #undef XRAMEND #endif #define XRAMEND ((volatile u_char *)0x7FFF) to get nutinit.c to compile, I can submit a patch if you want Harald 2- strtok_r is now in the libc (at last), problem is it's conflicting with Peter Scandrett version, I suggest we rename the Ethernut strtok_r to etehrnut_strtok_r to maintain some backward compatibility or we simply remove it and use the libc one ? BTW, the 2 versions havew different agruments Nic ------------------------------------------------- From peter.scandrett at transport.alstom.com Thu Sep 18 03:55:00 2003 From: peter.scandrett at transport.alstom.com (peter.scandrett at transport.alstom.com) Date: Thu, 18 Sep 2003 11:55:00 +1000 Subject: [En-Nut-Discussion] New winavr avr-libc 0.99.90.20030829 Message-ID: Hi all, On 18-Sep-03 Nic wrote > 2- strtok_r is now in the libc (at last), > problem is it's conflicting with Peter > Scandrett version, I suggest we rename > the Ethernut strtok_r to etehrnut_strtok_r > to maintain some backward compatibility or > we simply remove it and use the libc one ? > BTW, the 2 versions havew different agruments IMHO, I think we should remove my original version of STRTOK_R as it has a different function prototype to every other implementation. This has portability implications if one wants to take code to other platforms. In addition, my version supports STRSEP_R too, which is useful for parsing a string with consecutive separators which are significant (like a CSV file). My new version has a date of 10-Sep-03 at the top of the file. Peter Scandrett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030918/fe49a4b0/attachment.htm From damian at commtech.com.au Thu Sep 18 05:39:25 2003 From: damian at commtech.com.au (Damian Slee) Date: Thu, 18 Sep 2003 11:39:25 +0800 Subject: [En-Nut-Discussion] gateway parameter addition to NutNetIfConfig() Message-ID: Hi, can I have the gateway param added to NutNetIfConfig() and used in NutDhcpIfConfig() so manual configuration can be used. please? ifconfig.c int NutNetIfConfig(CONST char *name, void *params, u_long ip_addr, u_long ip_mask) { .. return NutNetIfSetup(dev, ip_addr, ip_mask, 0); to int NutNetIfConfig(CONST char *name, void *params, u_long ip_addr, u_long ip_mask, u_long gateway) { .. return NutNetIfSetup(dev, ip_addr, ip_mask, gateway); and in dhcpc.c int NutDhcpIfConfig(CONST char *name, u_char *mac, u_long timeout) { ... return NutNetIfConfig(name, confnet.cdn_mac, confnet.cdn_ip_addr, confnet.cdn_ip_mask, confnet.cdn_gateway); From damian at commtech.com.au Thu Sep 18 06:04:43 2003 From: damian at commtech.com.au (Damian Slee) Date: Thu, 18 Sep 2003 12:04:43 +0800 Subject: [En-Nut-Discussion] should fclose(stream) also close the socket? Message-ID: Hi, currently it doesn't, a separate call to NutTcpCloseSocket(sock) has to be made. From gedas at post.tvk.lt Thu Sep 18 06:42:57 2003 From: gedas at post.tvk.lt (Gediminas Simanskis) Date: Thu, 18 Sep 2003 07:42:57 +0300 Subject: [En-Nut-Discussion] comport driver for tl16c554 References: Message-ID: <003101c37d9f$554a2360$6400a8c0@elgama> 8 comport , 2x TL16C554 -------------- next part -------------- A non-text attachment was scrubbed... Name: uart_tl16c554.zip Type: application/octet-stream Size: 4537 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030918/79a63190/attachment.obj From Douglas.Pearless at pearless.co.nz Thu Sep 18 07:17:23 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Thu, 18 Sep 2003 17:17:23 +1200 Subject: [En-Nut-Discussion] comport driver for tl16c554 In-Reply-To: <003101c37d9f$554a2360$6400a8c0@elgama> Message-ID: This is great. Do I assume from reading the code, UART 1-4 are at 0xF840 and 5-8 at 0xF860, both sharing INT4? I'll need to digest this over the next few days. Thanks very much. Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Gediminas Simanskis Sent: Thursday, 18 September 2003 4:43 p.m. To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] comport driver for tl16c554 8 comport , 2x TL16C554 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From Douglas.Pearless at pearless.co.nz Thu Sep 18 07:21:22 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Thu, 18 Sep 2003 17:21:22 +1200 Subject: [En-Nut-Discussion] comport driver for tl16c554 In-Reply-To: <003101c37d9f$554a2360$6400a8c0@elgama> Message-ID: Could you also post the uart554.h file too? Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Gediminas Simanskis Sent: Thursday, 18 September 2003 4:43 p.m. To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] comport driver for tl16c554 8 comport , 2x TL16C554 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From gedas at post.tvk.lt Thu Sep 18 07:33:32 2003 From: gedas at post.tvk.lt (Gediminas Simanskis) Date: Thu, 18 Sep 2003 08:33:32 +0300 Subject: [En-Nut-Discussion] comport driver for tl16c554 References: Message-ID: <00ba01c37da6$68e3ab60$6400a8c0@elgama> > Do I assume from reading the code, UART 1-4 are at 0xF840 and 5-8 at 0xF860, > both sharing INT4? Yes. first chip TL16C554 INTA-INTD conected via OR to port adress 0xF8400 ,second TL16C554 to 0xF860.And all share INT4. From gedas at post.tvk.lt Thu Sep 18 07:34:52 2003 From: gedas at post.tvk.lt (Gediminas Simanskis) Date: Thu, 18 Sep 2003 08:34:52 +0300 Subject: [En-Nut-Discussion] comport driver for tl16c554 References: Message-ID: <00c101c37da6$97d57de0$6400a8c0@elgama> -------------- next part -------------- A non-text attachment was scrubbed... Name: Uart554.h Type: application/octet-stream Size: 2340 bytes Desc: not available Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030918/bef2faf0/attachment.obj From damian at commtech.com.au Thu Sep 18 09:36:31 2003 From: damian at commtech.com.au (Damian Slee) Date: Thu, 18 Sep 2003 15:36:31 +0800 Subject: [En-Nut-Discussion] src ip filtering addition Message-ID: Hi, I have made a change to allow/drop IP in packets, ie filter. Can this be added to CVS? Attached modified ipin.c, ip.h from cvs yesterday. Summary ------- I have a callback function that I register with, NutIpSetInputFilter(NutIpFilterFunc callbackFunc). The callback receives the source IP address as a parmater. It returns 0 for allow, -1 for deny. The developer implements their own rule table. e.g. Allows all devices on subnet 192.168.0.0/255.255.255.0 to talk to ethernut. u_long myFilterIp; u_long myFilterMask; int MyNutIpFilter(u_long ip_src) { if ((ip_src & myFilterMask) == myFilterIp) return 0; return -1; } main() { // Do DHCP.... ... myFilterIp = inet_addr("192.168.0.0"); myFilterMask = inet_addr("255.255.255.0"); NutIpSetInputFilter(MyNutIpFilter); ... } ----------------------------------------------------------- Changes to ipin.c Addition NutIpFilterFunc NutIpFilter = 0; void NutIpSetInputFilter(NutIpFilterFunc callbackFunc) { NutIpFilter = callbackFunc; } Change void NutIpInput(NUTDEVICE * dev, NETBUF * nb) { ... /* * Silently discard datagrams of different IP version * and fragmented datagrams, and Filtered IP datagrams */ if (ip->ip_v != IPVERSION || (ntohs(ip->ip_off) & (IP_MF | IP_OFFMASK)) != 0 || (NutIpFilter && NutIpFilter(ip->ip_src))) { NutNetBufFree(nb); return; } ... } -------------- next part -------------- A non-text attachment was scrubbed... Name: ipin.zip Type: application/x-zip-compressed Size: 5946 bytes Desc: ipin.zip Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030918/03b1b37f/attachment.bin From damian at commtech.com.au Thu Sep 18 09:32:13 2003 From: damian at commtech.com.au (Damian Slee) Date: Thu, 18 Sep 2003 15:32:13 +0800 Subject: [En-Nut-Discussion] src ip filtering addition Message-ID: Hi, I have made a change to allow/drop IP in packets, ie filter. Can this be added to CVS? Attached modified ipin.c, ip.h from cvs yesterday. Summary ------- I have a callback function that I register with, NutIpSetInputFilter(NutIpFilterFunc callbackFunc). The callback receives the source IP address as a parmater. It returns 0 for allow, -1 for deny. The developer implements their own rule table. e.g. Allows all devices on subnet 192.168.0.0/255.255.255.0 to talk to ethernut. u_long myFilterIp; u_long myFilterMask; int MyNutIpFilter(u_long ip_src) { if ((ip_src & myFilterMask) == myFilterIp) return 0; return -1; } main() { // Do DHCP.... ... myFilterIp = inet_addr("192.168.0.0"); myFilterMask = inet_addr("255.255.255.0"); NutIpSetInputFilter(MyNutIpFilter); ... } ----------------------------------------------------------- Changes to ipin.c Addition NutIpFilterFunc NutIpFilter = 0; void NutIpSetInputFilter(NutIpFilterFunc callbackFunc) { NutIpFilter = callbackFunc; } Change void NutIpInput(NUTDEVICE * dev, NETBUF * nb) { ... /* * Silently discard datagrams of different IP version * and fragmented datagrams, and Filtered IP datagrams */ if (ip->ip_v != IPVERSION || (ntohs(ip->ip_off) & (IP_MF | IP_OFFMASK)) != 0 || (NutIpFilter && NutIpFilter(ip->ip_src))) { NutNetBufFree(nb); return; } ... } Commtech Wireless www.commtech.com.au (Australia) www.commtechwireless.com (USA) PO Box 1037 OPDC WA 6916 Ph:+61 8 9242 5651 Fax:+61 8 9242 5652 Confidentiality/Limited Liability Statement This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message, you must not disseminate, copy or take any action in reliance on it. If you have received this message in error, please notify Commtech Wireless Pty Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Commtech Wireless. Additionally if prices are quoted in this document then you may consider this document to be an official quotation and the prices quoted are valid for a period of fourteen days from the date of this document. -------------- next part -------------- A non-text attachment was scrubbed... Name: ip.h Type: application/octet-stream Size: 7380 bytes Desc: ip.h Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030918/ddca6ae8/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: ipin.c Type: application/octet-stream Size: 9047 bytes Desc: ipin.c Url : http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030918/ddca6ae8/attachment-0001.obj From damian at commtech.com.au Thu Sep 18 10:41:03 2003 From: damian at commtech.com.au (Damian Slee) Date: Thu, 18 Sep 2003 16:41:03 +0800 Subject: [En-Nut-Discussion] media sense/cable detect Message-ID: >>>Is it possible to tell the difference between the cable being >>>disconnected and the hub/switch/router losing power temporarily? I know on Windows 2k and on, there is no diff. if the switch looses power, all the PC's drop their external interface (192.168.0.x). They are removed from routing tables and everything. I think the arguement is mobility. eg changing from LAN to 802.11 with a notebook. There is a registry entry to disable it in windows. >>>>When the cable is unplugged all TCP connections can be flaged as closed. >>Does Windows do this? yep. I'm thinking now it may not be a good option. From cosminbuhu at lycos.co.uk Thu Sep 18 15:02:34 2003 From: cosminbuhu at lycos.co.uk (Cosmin Buhu) Date: Thu, 18 Sep 2003 16:02:34 +0300 Subject: [En-Nut-Discussion] Socket timeouts In-Reply-To: References: Message-ID: <20030918160234.0042788d.cosminbuhu@lycos.co.uk> Hello, Please if anyone can comment about socket timeouts, SO_SNDTIMEO and SO_RCVTIMEO, how are they acting and what should be a good strategy to use them. Thanks, Cosmin From harald.kipp at egnite.de Thu Sep 18 12:21:07 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 18 Sep 2003 12:21:07 +0200 Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: References: <20030917112539.L2732@gblx.net> <5.1.1.6.0.20030917094830.024a4438@egnite.de> <20030917112539.L2732@gblx.net> Message-ID: <5.1.1.6.0.20030918121049.01b1c890@egnite.de> Ted, >There's an excellant discussion of this in the Introduction section of >chapter 23 ("TCP Keepalive Timer") in Stevens "TCP Illustrated Vol 1." This book is the first choice for TCP development. Volume 2 2. ;-) >Is it possible to tell the difference between the cable being >disconnected and the hub/switch/router losing power temporarily? Definitely not. To all: The problem may sound exotic to some of us, but becomes important with PPP and even more important with GPRS. If the line is cut, you don't expect your browser to report an error, but expect the GPRS layer to silently re-establish the link, right? On the other hand, in reliable embedded systems a link cut is an important event. Harald From harald.kipp at egnite.de Thu Sep 18 12:26:12 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 18 Sep 2003 12:26:12 +0200 Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: <20030917112539.L2732@gblx.net> References: <5.1.1.6.0.20030917094830.024a4438@egnite.de> <5.1.1.6.0.20030917094830.024a4438@egnite.de> Message-ID: <5.1.1.6.0.20030918122150.02464090@egnite.de> Hi Austin, > If the link is down it should flag packets going to that interface >with an icmp network unreachable, or something like that. The received icmp >should be interpreted by the device as being a good reason to close the >connection. Or something like that. I'm not _that_ familiar with the >exact method. Grumble...[Very small font]Ethernut doesn't handle this ICMP message. Quite tricky to implement without destroying the layered design[/Very smal font] But, if I didn't misunderstood, the problem is on the receiver side. The receiver will not notice a cut link and may hang forever. Harald From harald.kipp at egnite.de Thu Sep 18 12:48:08 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 18 Sep 2003 12:48:08 +0200 Subject: [En-Nut-Discussion] WinAVR: Using uisp with Ethernut's STK500 dongle In-Reply-To: <1063821908.2278.47.camel@hw.vabo.cz> References: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> Message-ID: <5.1.1.6.0.20030918122809.01aea868@egnite.de> Pavel, >If I use Ethernut's STK500 dongle with AVR studio everything works OK. I >have replaced the Ethernut's STK500 dongle with STK500 Protocol AVR >Bootloader - http://avr1.org/stk500boot/stk500boot.html and UISP works >fine. You did what?!?! Wow, didn't expect that this works. Thanks for the info. But now you spoiled your dongle and lost guarantee, hehehehe... Nah, seriously. I'll publish our dongle firmware, which is completely in assembler. I'm just a little bit scared, because dongle problems are reported most often by people who bought Starter Kits. Since their first release, we never changed the firmware, if I remember correctly. What would happen, if modified releases are floating around? Btw. there is a serious problem with it. Our dongle will not work with targets running on 8 MHz or below. Jan Rehak reported this recently and we also failed to program older systems with 3.6864 MHz crystals. Jan plans to design a newer version using an AVR with more RAM. >Which version of dongle firmware are you using ? SISP 1.0.1.1 and uisp version 20030827cvs Harald From ceba at vabo.cz Thu Sep 18 13:27:24 2003 From: ceba at vabo.cz (Pavel Celeda) Date: 18 Sep 2003 13:27:24 +0200 Subject: [En-Nut-Discussion] WinAVR: Using uisp with Ethernut's STK500 dongle In-Reply-To: <5.1.1.6.0.20030918122809.01aea868@egnite.de> References: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> <5.1.1.6.0.20030918122809.01aea868@egnite.de> Message-ID: <1063884444.2317.23.camel@hw.vabo.cz> > >If I use Ethernut's STK500 dongle with AVR studio everything works OK. I > >have replaced the Ethernut's STK500 dongle with STK500 Protocol AVR > >Bootloader - http://avr1.org/stk500boot/stk500boot.html and UISP works > >fine. > > You did what?!?! Wow, didn't expect that this works. 1) I have patched the code of stk500boot.c so it works with Charon II and Development Board. 2) I have flashed the bootloader in the ATmega128 and set the necessary fuses. 3) I have removed all programming dongles (STK200, STK500). Now I download the code via UART0. > Thanks for the info. > > But now you spoiled your dongle and lost guarantee, hehehehe... I didn't touched the dongle. :) > Nah, seriously. I'll publish our dongle firmware, which > is completely in assembler. I'm just a little bit scared, > because dongle problems are reported most often by people > who bought Starter Kits. Since their first release, we > never changed the firmware, if I remember correctly. > What would happen, if modified releases are floating > around? > > Btw. there is a serious problem with it. Our dongle will > not work with targets running on 8 MHz or below. Jan Rehak > reported this recently and we also failed to program older > systems with 3.6864 MHz crystals. Jan plans to design a > newer version using an AVR with more RAM. I know about it, I have already faced with this problem. > >Which version of dongle firmware are you using ? > > SISP 1.0.1.1 > and > uisp version 20030827cvs I have tested a dozen of UISP versions but without success. So I was really startled after receiving your email. Pavel From troth at openavr.org Thu Sep 18 18:33:31 2003 From: troth at openavr.org (Theodore A. Roth) Date: Thu, 18 Sep 2003 09:33:31 -0700 (PDT) Subject: [En-Nut-Discussion] WinAVR: Using uisp with Ethernut's STK500 dongle In-Reply-To: <1063884444.2317.23.camel@hw.vabo.cz> References: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> <5.1.1.6.0.20030918122809.01aea868@egnite.de> <1063884444.2317.23.camel@hw.vabo.cz> Message-ID: On Thu, 18 Sep 2003, Pavel Celeda wrote: > > >Which version of dongle firmware are you using ? > > > > SISP 1.0.1.1 > > and > > uisp version 20030827cvs > > I have tested a dozen of UISP versions but without success. So I was > really startled after receiving your email. Can you send me a dump of the uisp output using -v=4? From ralph.mason at telogis.com Thu Sep 18 22:57:56 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Fri, 19 Sep 2003 08:57:56 +1200 Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: <5.1.1.6.0.20030918122150.02464090@egnite.de> Message-ID: > > Grumble...[Very small font]Ethernut doesn't handle this ICMP > message. Quite tricky to implement without destroying the layered > design[/Very smal font] > The ICMP socket class I contributed would make it very easy to receive this message if one were interested in it. Ralph --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 From damian at commtech.com.au Fri Sep 19 01:51:12 2003 From: damian at commtech.com.au (Damian Slee) Date: Fri, 19 Sep 2003 07:51:12 +0800 Subject: [En-Nut-Discussion] Socket timeouts Message-ID: I'm using SO_RCVTIMEO, mainly so I can do some other things on the same thread, I could do it on another thread, but then would have to handle syncronising access to variables from different threads. And some more resources would be used by the second thread. I'm not changing SO_SNDTIMEO. ie leaving it as blocking, if the internally buffer can't take it all. -----Original Message----- From: Cosmin Buhu [mailto:cosminbuhu at lycos.co.uk] Sent: Thursday, 18 September 2003 9:03 PM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] Socket timeouts Hello, Please if anyone can comment about socket timeouts, SO_SNDTIMEO and SO_RCVTIMEO, how are they acting and what should be a good strategy to use them. Thanks, Cosmin _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From michael at lfiinternational.com Fri Sep 19 01:49:50 2003 From: michael at lfiinternational.com (Michael G. Svob) Date: Thu, 18 Sep 2003 16:49:50 -0700 Subject: [En-Nut-Discussion] Using WinAVR libraries Message-ID: Greetings, I was wondering if anyone could provide me assistance with using the WinAVR header files and libraries with my Ethernut. In particular, I would like to take advantage of functions in stdlib.h and math.h. Thanks in advance for any insight. Best Regards, Michael Svob LFI International From damian at commtech.com.au Fri Sep 19 05:40:02 2003 From: damian at commtech.com.au (Damian Slee) Date: Fri, 19 Sep 2003 11:40:02 +0800 Subject: [En-Nut-Discussion] Changing password for "cgi-bin" catalog in httpd example Message-ID: I'm getting same problem here. I've debugged it a bit further tho. Works ok for root:root. But if I change string lengths it doesn't work, works for some... NutRegisterAuth("cgi-bin", "root:public"); then dumping the strings out the serial port... - root:public entered into browser NutHttpAuthValidate() - pre, post base64 decode base64:cm9vdDpwdWJsaWM= Notice the crap character at the end after the decode. base64dec:root:public? NutHttpAuthLookup() - login, auth in memory root:public?, root:public Fails! I just tried copying the NutDecodeBase64 into a Win32 console app with same base64 string "cm9vdDpwdWJsaWM=" and am getting no problem under VC. I'll trace the output of the two, and find out where it differs. -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Tuesday, 16 September 2003 4:53 PM To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] Changing password for "cgi-bin" catalog in httpd example > >This is what I changed it to: >NutRegisterAuth("cgi-bin", "boot:boot"); Works fine here. May be a problem with your browser? Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From damian at commtech.com.au Fri Sep 19 07:02:09 2003 From: damian at commtech.com.au (Damian Slee) Date: Fri, 19 Sep 2003 13:02:09 +0800 Subject: [En-Nut-Discussion] BUGFIX: NutDecodeBase64() Message-ID: hehe, this has caught me out a couple of times as well porting some code from VC to GCC. What was happening was the if statment was never failing when 'code == -1' for (tp = sp = str; *sp; ++sp) { if ((code = PRG_RDB(&base64dtab[(int) *sp])) == -1) continue; This is because base64dtab[] is an array of char, and -1 is 255. 'code' is an int. -1 is 65535. 255 != 65535. Changing 'code' & 'last' to char, from int, fixes the problem. From ralph.mason at telogis.com Fri Sep 19 07:02:44 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Fri, 19 Sep 2003 17:02:44 +1200 Subject: [En-Nut-Discussion] Socket timeouts In-Reply-To: Message-ID: You should not need any synchronisation between threads, because there is no preemptive scheduling. Your thread will only context switch if you let it. Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Damian Slee > Sent: Friday, 19 September 2003 11:51 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Socket timeouts > > > I'm using SO_RCVTIMEO, mainly so I can do some other things on > the same thread, I could do it on another thread, but then would > have to handle syncronising access to variables from different > threads. And some more resources would be used by the second thread. > > I'm not changing SO_SNDTIMEO. ie leaving it as blocking, if the > internally buffer can't take it all. > > -----Original Message----- > From: Cosmin Buhu [mailto:cosminbuhu at lycos.co.uk] > Sent: Thursday, 18 September 2003 9:03 PM > To: en-nut-discussion at egnite.de > Subject: [En-Nut-Discussion] Socket timeouts > > > > > Hello, > > Please if anyone can comment about socket timeouts, > SO_SNDTIMEO and SO_RCVTIMEO, how are they acting and what should > be a good strategy to use them. > > Thanks, > Cosmin > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 From ngbmoreau at yahoo.com.au Fri Sep 19 09:03:33 2003 From: ngbmoreau at yahoo.com.au (NGB) Date: Fri, 19 Sep 2003 17:03:33 +1000 Subject: [En-Nut-Discussion] Sockets Message-ID: <1063955013.3f6aaa4540e0a@tiger.enttec> I have 1 UDP socket that I needs to be accessed from 2 threads, 1 thread is reading from the socket the other writing. Does ethernut support this ? Anything I should be aware of ? Nic ------------------------------------------------- From harald.kipp at egnite.de Fri Sep 19 10:32:07 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 19 Sep 2003 10:32:07 +0200 Subject: [En-Nut-Discussion] Sockets In-Reply-To: <1063955013.3f6aaa4540e0a@tiger.enttec> Message-ID: <5.1.1.6.0.20030919103054.01a92f88@egnite.de> > >I have 1 UDP socket that I needs to be accessed from 2 threads, 1 thread is >reading from the socket the other writing. >Does ethernut support this ? >Anything I should be aware of ? No known problems. You can share UDP and TCP sockets between threads. Harald From ngbmoreau at yahoo.com.au Mon Sep 22 04:24:17 2003 From: ngbmoreau at yahoo.com.au (NGB) Date: Mon, 22 Sep 2003 12:24:17 +1000 Subject: [En-Nut-Discussion] Sockets In-Reply-To: <5.1.1.6.0.20030919103054.01a92f88@egnite.de> References: <5.1.1.6.0.20030919103054.01a92f88@egnite.de> Message-ID: <1064197457.3f6e5d515282d@tiger.enttec> Out of curiostity what happens if 2 tasks wait on the same socket Is it the first one that waits that get's suspended, what happens to the other ? Thanks Nic Quoting Harald Kipp : > > > > >I have 1 UDP socket that I needs to be accessed from 2 threads, 1 thread is > >reading from the socket the other writing. > >Does ethernut support this ? > >Anything I should be aware of ? > > No known problems. You can share UDP and TCP sockets > between threads. > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > ------------------------------------------------- From ralph.mason at telogis.com Mon Sep 22 04:52:21 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Mon, 22 Sep 2003 14:52:21 +1200 Subject: [En-Nut-Discussion] Sockets In-Reply-To: <1064197457.3f6e5d515282d@tiger.enttec> Message-ID: Same as if two threads waited on any event. The would both get suspended. The one with the highest priority would get woken first. You might like to look at NutEventWait. Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of NGB > Sent: Monday, 22 September 2003 2:24 > To: en-nut-discussion at egnite.de > Subject: Re: [En-Nut-Discussion] Sockets > > > Out of curiostity what happens if 2 tasks wait on the same socket > Is it the first one that waits that get's suspended, what happens > to the other ? > > Thanks > > Nic > > > Quoting Harald Kipp : > > > > > > > > >I have 1 UDP socket that I needs to be accessed from 2 > threads, 1 thread is > > >reading from the socket the other writing. > > >Does ethernut support this ? > > >Anything I should be aware of ? > > > > No known problems. You can share UDP and TCP sockets > > between threads. > > > > Harald > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > > > > > > ------------------------------------------------- > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 From damian at commtech.com.au Mon Sep 22 06:02:51 2003 From: damian at commtech.com.au (Damian Slee) Date: Mon, 22 Sep 2003 12:02:51 +0800 Subject: [En-Nut-Discussion] Socket timeouts Message-ID: >>You should not need any synchronisation between threads what about the Nut timer callbacks which is interrupt based? -----Original Message----- From: Ralph Mason [mailto:ralph.mason at telogis.com] Sent: Friday, 19 September 2003 1:03 PM To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] Socket timeouts You should not need any synchronisation between threads, because there is no preemptive scheduling. Your thread will only context switch if you let it. Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Damian Slee > Sent: Friday, 19 September 2003 11:51 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Socket timeouts > > > I'm using SO_RCVTIMEO, mainly so I can do some other things on > the same thread, I could do it on another thread, but then would > have to handle syncronising access to variables from different > threads. And some more resources would be used by the second thread. > > I'm not changing SO_SNDTIMEO. ie leaving it as blocking, if the > internally buffer can't take it all. > > -----Original Message----- > From: Cosmin Buhu [mailto:cosminbuhu at lycos.co.uk] > Sent: Thursday, 18 September 2003 9:03 PM > To: en-nut-discussion at egnite.de > Subject: [En-Nut-Discussion] Socket timeouts > > > > > Hello, > > Please if anyone can comment about socket timeouts, > SO_SNDTIMEO and SO_RCVTIMEO, how are they acting and what should > be a good strategy to use them. > > Thanks, > Cosmin > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From ralph.mason at telogis.com Mon Sep 22 06:10:24 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Mon, 22 Sep 2003 16:10:24 +1200 Subject: [En-Nut-Discussion] Socket timeouts In-Reply-To: Message-ID: I don't really think there is much need to interact with the operating system in a timer call back. It has many many drawbacks (not the least of which is non deterministic stack requirements) What is wrong with a thread like? while(1){ NutSleep(1000); //Do synchronised code } Nice, safe simple. Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Damian Slee > Sent: Monday, 22 September 2003 4:03 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Socket timeouts > > > >>You should not need any synchronisation between threads > > what about the Nut timer callbacks which is interrupt based? > > -----Original Message----- > From: Ralph Mason [mailto:ralph.mason at telogis.com] > Sent: Friday, 19 September 2003 1:03 PM > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Socket timeouts > > > You should not need any synchronisation between threads, because > there is no > preemptive scheduling. > > Your thread will only context switch if you let it. > > Ralph > > > -----Original Message----- > > From: en-nut-discussion-admin at egnite.de > > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Damian Slee > > Sent: Friday, 19 September 2003 11:51 > > To: en-nut-discussion at egnite.de > > Subject: RE: [En-Nut-Discussion] Socket timeouts > > > > > > I'm using SO_RCVTIMEO, mainly so I can do some other things on > > the same thread, I could do it on another thread, but then would > > have to handle syncronising access to variables from different > > threads. And some more resources would be used by the second thread. > > > > I'm not changing SO_SNDTIMEO. ie leaving it as blocking, if the > > internally buffer can't take it all. > > > > -----Original Message----- > > From: Cosmin Buhu [mailto:cosminbuhu at lycos.co.uk] > > Sent: Thursday, 18 September 2003 9:03 PM > > To: en-nut-discussion at egnite.de > > Subject: [En-Nut-Discussion] Socket timeouts > > > > > > > > > > Hello, > > > > Please if anyone can comment about socket timeouts, > > SO_SNDTIMEO and SO_RCVTIMEO, how are they acting and what should > > be a good strategy to use them. > > > > Thanks, > > Cosmin > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > > > --- > > Incoming mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 From mikec at call-direct.com.au Tue Sep 23 03:57:34 2003 From: mikec at call-direct.com.au (Mike Cornelius) Date: Tue, 23 Sep 2003 11:57:34 +1000 Subject: [En-Nut-Discussion] ICMP Sockets In-Reply-To: Message-ID: <013901c38176$0fbb19f0$2301a8c0@Mike> Hi Ralph, Thanks a lot for the ICMP code, I've just been getting to use it and found that you refer to :- icp->ident In NutIcmpInput() The version of ICMPHDR in ip_icmp.h in the distribution that I have has a single u_long icmp_spec where I figure ident would go. What's the deal ? Have you modified ICMPHDR and therefore NutIcmpReply() in icmpout.c which uses icmp_spec ? Or is NutIcmpInput() not quite right ? Or something else ? I also notice the following :- #ifdef NAT_SUPPORT RouteIncommingPacket(nb,IPPROTO_ICMP); #else This is most intriguing, I take it you have or are in the process of implementing NAT, this would be most useful, any chance of releasing this too? Regards, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Mike Cornelius Internet: mikec at call-direct.com.au Call Direct Cellular Solutions Phone: +61 2 9209-4259 Suite 145 FAX: +61 2 9209-4196 National Innovation Centre URL: http://www.call-direct.com.au Australian Technology Park Eveleigh NSW 1430 Australia ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of Ralph Mason Sent: Monday, August 11, 2003 6:10 PM To: en-Nut-Discussion Subject: [En-Nut-Discussion] ICMP Sockets I have implemented ICMP sockets for NutOS if anyone is interested. You can do tracert, ping etc. You can also receive unreachable messages etc for a given TCP or UDP connection. Example code int ping(char* args[],int argc, FILE* f){ u_long addr; ICMPSOCKET* sock; u_char data[32]; int i; if ( argc < 2 ){ fputs_P(PSTR("usage: ping host [timeout]\r\n"),f); return -1; } if( (addr = resolve_address_name(args[1],f)) == 0 ){ cr(f); return 0; } sock = NutIcmpCreateSocket(IPPROTO_ICMP,1); fprintf_P(f,PSTR("Pinging %s [%a] with 32 bytes\r\n\r\n"),args[1],addr); fflush(f); for( i = 0 ; i < 4 ; i++){ u_long reply_addr; u_char type; u_char code; u_long ticks; NutIcmpSendTo(sock,addr,ICMP_ECHO,0,data,32); ticks = NutGetTickCount(); if ( NutIcmpReceiveFrom(sock,&reply_addr,&type,&code,data,32,3000) != 0){ switch( type){ case ICMP_ECHOREPLY: fprintf_P(f,PSTR("Relpy from %a %i ms\r\n"),reply_addr, (int)(((NutGetTickCount()-ticks)*1000)/ 40L)); break; default: fprintf_P(f,PSTR("Relpy from %a type %i code %i\r\n"), reply_addr,type,code); } } else{ fputs_P(PSTR("Request timed out.\r\n"),f); } fflush(f); } NutIcmpDestroySocket(sock); return 0; } If you want the code reply via email. Cheers Ralph --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003 _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From laran at ikp.liu.se Tue Sep 23 14:11:19 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Tue, 23 Sep 2003 14:11:19 +0200 Subject: [En-Nut-Discussion] Generate graphics on Ethernut Message-ID: <6D71E1FB451D984081153EC11D7A3DDB91AA8B@mail.ikp.liu.se> Hi all, I have a wish and that is to generate graphics on the Ethernut and then present this in a web interface. I have heard that PNG is supposed to be a rather simple way of generating images and is therefore curious if anyone has done this on the ethernut or if anyone know of code that might be compact enough to work on a Mega128. Regards, /Lars A Andersson From ralph.mason at telogis.com Tue Sep 23 04:18:26 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Tue, 23 Sep 2003 14:18:26 +1200 Subject: [En-Nut-Discussion] ICMP Sockets In-Reply-To: <013901c38176$0fbb19f0$2301a8c0@Mike> Message-ID: Hi Mike, You are correct I did modify the ICMPHDR file forgot to include the file I updated (attached). Yes, I do have a rough version of NAT working for NutOS, but it's not ready for public consumption yet, it supports multiple PPP interfaces, so you can have a PPP server. I plan on releasing it 'some time' when it's more complete. Regards Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Mike Cornelius > Sent: Tuesday, 23 September 2003 1:58 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] ICMP Sockets > > > Hi Ralph, > > Thanks a lot for the ICMP code, I've just been getting to use it and > found that you refer to :- > > icp->ident In NutIcmpInput() > > The version of ICMPHDR in ip_icmp.h in the distribution that I have has > a single u_long icmp_spec where I figure ident would go. > > What's the deal ? > Have you modified ICMPHDR and therefore NutIcmpReply() in icmpout.c > which uses icmp_spec ? > Or is NutIcmpInput() not quite right ? > Or something else ? > > I also notice the following :- > #ifdef NAT_SUPPORT > RouteIncommingPacket(nb,IPPROTO_ICMP); > #else > > This is most intriguing, I take it you have or are in the process of > implementing NAT, this would be most useful, any chance of releasing > this too? > > Regards, > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~ > Mike Cornelius Internet: mikec at call-direct.com.au > Call Direct Cellular Solutions Phone: +61 2 9209-4259 > Suite 145 FAX: +61 2 9209-4196 > National Innovation Centre URL: http://www.call-direct.com.au > Australian Technology Park > Eveleigh NSW 1430 > Australia > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~ > > > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of Ralph Mason > Sent: Monday, August 11, 2003 6:10 PM > To: en-Nut-Discussion > Subject: [En-Nut-Discussion] ICMP Sockets > > > I have implemented ICMP sockets for NutOS if anyone is interested. > > You can do tracert, ping etc. > > You can also receive unreachable messages etc for a given TCP or UDP > connection. > > Example code > > int ping(char* args[],int argc, FILE* f){ > > u_long addr; > ICMPSOCKET* sock; > u_char data[32]; > int i; > > if ( argc < 2 ){ > fputs_P(PSTR("usage: ping host [timeout]\r\n"),f); > return -1; > } > > if( (addr = resolve_address_name(args[1],f)) == 0 ){ > cr(f); > return 0; > } > > sock = NutIcmpCreateSocket(IPPROTO_ICMP,1); > > fprintf_P(f,PSTR("Pinging %s [%a] with 32 > bytes\r\n\r\n"),args[1],addr); > fflush(f); > > for( i = 0 ; i < 4 ; i++){ > u_long reply_addr; > u_char type; > u_char code; > u_long ticks; > > NutIcmpSendTo(sock,addr,ICMP_ECHO,0,data,32); > ticks = NutGetTickCount(); > > if ( > NutIcmpReceiveFrom(sock,&reply_addr,&type,&code,data,32,3000) != 0){ > > switch( type){ > case ICMP_ECHOREPLY: > fprintf_P(f,PSTR("Relpy from %a > %i ms\r\n"),reply_addr, > > (int)(((NutGetTickCount()-ticks)*1000)/ 40L)); > break; > > default: > fprintf_P(f,PSTR("Relpy from %a > type %i code %i\r\n"), > > reply_addr,type,code); > } > } > else{ > fputs_P(PSTR("Request timed > out.\r\n"),f); > } > > fflush(f); > } > > NutIcmpDestroySocket(sock); > > return 0; > } > > > > If you want the code reply via email. > > Cheers > Ralph > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003 > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ip_icmp.h Url: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030923/b0b443f0/attachment.pot From Fahad.Gilani at anu.edu.au Tue Sep 23 19:15:58 2003 From: Fahad.Gilani at anu.edu.au (Fahad G.) Date: 24 Sep 2003 03:15:58 +1000 Subject: [En-Nut-Discussion] X-10 anyone? Message-ID: <1064337358.3922.3.camel@Fahad> Hi, I recently started working on an X-10 device, trying to communicate with it using ethernut and a GSM Ultralite E iT device. I was wondering if anyone on the mailing list has tried ethernut with X-10 devices? If so, could s/he share code/experiences with me? thanks, cheers, Fahad ----------------------------------------------------------------------------------------------- main(){int j=1234;char t[]=":@abcdefghijklmnopqrstuvwxyz.\n",*i= "iqgbgxmfxfvbviabrlxt at lfeg\npecsf";char *strchr(const char*,int); while(*i){j+=strchr(t,*i++)-t;j%=sizeof t-1;putchar(t[j]);}return 0;} -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030924/ed873714/attachment.html From Brett.Abbott at digital-telemetry.com Wed Sep 24 02:34:10 2003 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Wed, 24 Sep 2003 12:34:10 +1200 Subject: [En-Nut-Discussion] PPP Retrying when no PPP/GPRS is available Message-ID: <3F70E682.8050308@digital-telemetry.com> Hi Using the PPP in version 3.3.0, you may find that when a PPP service (such as a GPRS modem) only partially responds to a Dial command, or the ifconfig fails, the lcp state engine may time out. Repeated attempts to redial (atd99*** etc) then seem to fall on deaf ears. A specific example of this is when the initial chat command is acknowledged (ie. OK, CONNECT) and then no reponse comes from the PPP engine, it will send 9 retries before going to bed.. Will the kind assistance from Harald, Ive tracked down that in this timeout scenario, the lcp state is set to STOPPED. When STOPPED, the subsequent request to perform an "if (NutNetIfConfig("ppp", 0, 0, 0)) " will not result in any outgoing packets and the ppp thread will remain STOPPED. Also, there is a (useful) workaround in place using a the global variable ppp_hackup. When set to 0, the ppp engine does not attempt to talk with the interface. We use this to allow chat commands to control the modem. Note that when set to 1 (when calling NutNetIfConfig), even if the engine is STOPPED, any characters sent to the interface (like ATD to reconnect) are absorbed by the ppp engine and rejected as invalid, never reaching the modem. The quick fix to this is a two parter..... First we set the global variable to 0 (ppp_hackup=0), then we tickle the ppp state machine by setting the lcp_status to STARTING (Using the lcp_lowerdown function). The ppp_hackup setting stops the newly woken ppp state machine from saying hi to the modem until we've redone our dial command. We redial if needed then reprod the engine using "if (NutNetIfConfig("ppp", 0, 0, 0)) " Ideally you ought to close the engine and go through a proper restart/retry but this ought to solve the problem for now. Ive taken this approach rather than solving it nicely as I know Harald is soon to modify/improve the way this functionality is to work. I would like to propose the "ideal" solution but Im still reading the PPP text book and would greatfully receive thoughts on how it really ought to be solved. I include the modified source showing the workaround. Also refer you to the pppd.c sample in the CVS repository. Additionally, I am writing commands to pause the PPP interface, interogate the modem status (ie. go into command mode), execute a command such as "Signal Strength" and then return to Data Mode (ATO) and resume PPP. Has anyone else done this? (the ppp_hackup supports this). Perhaps it is better named "ppp_pause". In the ideal world, I guess this is done by putting the engine into a known PAUSE state as it is possible to have more than one PPP interface. Many Thanks in advance. Brett // If the link is lost, it will try to reopen link if( dcb->dcb_ipcp_state != PPPS_OPENED ) // only proceed if the ppp isnt opened { // Put your code here to ensure the modem is hungup, perhaps : // sleep 1 second, +++, sleep 1 second, ATH // Tell the modem to connect to PPP if (NutChat(pppcom,"'' 'at+cgdcont=1,\"IP\",\"yourAPN\"' 'OK' 'atd*99***1#' 'CONNECT'") == 0) { // attempt to configure the network interface if (NutNetIfConfig("ppp", 0, 0, 0)) { fprintf(tcpip1, "PPP failed\r\n"); fflush(tcpip1); // WORKAROUND CODE STARTS HERE ---- Note ppp_hackup is local to the ppp code and to work like this you must // include the library code in your source or place this code in the library pppdev = NutDeviceLookup("ppp"); ppp_hackup=0; rc=NutPppIOCtl(pppdev, LCP_LOWERDOWN, 0); // WORKAROUND CODE ENDS HERE NutSleep(5000); continue; // go back and try again } else { // Worked // * Set name server and default route. Actually the PPP interface // * should do this, but the current release doesn't. dcb = devPpp.dev_dcb; NutDnsConfig2(0, 0, dcb->dcb_ip_dns1, dcb->dcb_ip_dns2); NutIpRouteAdd(0, 0, dcb->dcb_remote_ip, &devPpp); if((rip = NutDnsGetHostByName(INETSERVER)) != 0) { fprintf(tcpip1, "%s: %s\r\n", INETSERVER, inet_ntoa(rip)); fflush(tcpip1); } } } else { // Error with chat fprintf(tcpip1,"...error in chat \r\n"); fflush(tcpip1); NutSleep(5000); continue; } } ----------------------------------------------------------------- Brett Abbott, Managing Director, Digital Telemetry Limited Email: Brett.Abbott at digital-telemetry.com PO Box 24 036 Manners Street, Wellington, New Zealand Phone +64 (4) 5666-860 Mobile +64 (21) 656-144 ------------------- Commercial in confidence -------------------- From mikec at call-direct.com.au Wed Sep 24 03:06:51 2003 From: mikec at call-direct.com.au (Mike Cornelius) Date: Wed, 24 Sep 2003 11:06:51 +1000 Subject: [En-Nut-Discussion] PPP Retrying when no PPP/GPRS is available In-Reply-To: <3F70E682.8050308@digital-telemetry.com> Message-ID: <018501c38238$242c2c40$2301a8c0@Mike> Hi Brett, Second things first, I've not tried interrupting the PPP session whilst it's going and then going back. I assume you're thinking something like: <>PPP[] >+++ >AT+CSQ? <+CSQ: ??,?? >ATO <>PPP[] But it's certainly an interesting idea and if I get a chance I give it a whirl and let you know what I find. On the first point I do things slightly differently and IMHO a little bit less hackish as folows:- int fd_ppp = -1; While (whatever) { if (not up and we want to be) { if ((fd_ppp != -1) && (pdcb->dcb_ipcp_state != PPPS_CLOSED)) { if (_close(fd_ppp) == 0) { ppp_hackup = 0; fd_ppp = -1; } } DisconnectCall(comm_phone); if (NutChat(_fileno(comm_phone), confgprs->setup_string) == 0) { if (fd_ppp == -1) { fd_ppp = _open("ppp:uart0", _O_RDWR | _O_BINARY); ltmp = PHONE_BAUD; _ioctl(fd_ppp, UART_SETSPEED, <mp); } if (NutNetIfConfig("ppp", 0, 0, 0)) { // If we can't establish PPP 3 times in a row reboot ppp_attempts ++; if (ppp_attempts >= 3) CDCS_Reboot(); } else { NutDnsConfig2 (0,0,pdcb->dcb_ip_dns1,pdcb->dcb_ip_dns2); } } } } Regards, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Mike Cornelius Internet: mikec at call-direct.com.au Call Direct Cellular Solutions Phone: +61 2 9209-4259 Suite 145 FAX: +61 2 9209-4196 National Innovation Centre URL: http://www.call-direct.com.au Australian Technology Park Eveleigh NSW 1430 Australia ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of Brett Abbott Sent: Wednesday, September 24, 2003 10:34 AM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] PPP Retrying when no PPP/GPRS is available Hi Using the PPP in version 3.3.0, you may find that when a PPP service (such as a GPRS modem) only partially responds to a Dial command, or the ifconfig fails, the lcp state engine may time out. Repeated attempts to redial (atd99*** etc) then seem to fall on deaf ears. A specific example of this is when the initial chat command is acknowledged (ie. OK, CONNECT) and then no reponse comes from the PPP engine, it will send 9 retries before going to bed.. Will the kind assistance from Harald, Ive tracked down that in this timeout scenario, the lcp state is set to STOPPED. When STOPPED, the subsequent request to perform an "if (NutNetIfConfig("ppp", 0, 0, 0)) " will not result in any outgoing packets and the ppp thread will remain STOPPED. Also, there is a (useful) workaround in place using a the global variable ppp_hackup. When set to 0, the ppp engine does not attempt to talk with the interface. We use this to allow chat commands to control the modem. Note that when set to 1 (when calling NutNetIfConfig), even if the engine is STOPPED, any characters sent to the interface (like ATD to reconnect) are absorbed by the ppp engine and rejected as invalid, never reaching the modem. The quick fix to this is a two parter..... First we set the global variable to 0 (ppp_hackup=0), then we tickle the ppp state machine by setting the lcp_status to STARTING (Using the lcp_lowerdown function). The ppp_hackup setting stops the newly woken ppp state machine from saying hi to the modem until we've redone our dial command. We redial if needed then reprod the engine using "if (NutNetIfConfig("ppp", 0, 0, 0)) " Ideally you ought to close the engine and go through a proper restart/retry but this ought to solve the problem for now. Ive taken this approach rather than solving it nicely as I know Harald is soon to modify/improve the way this functionality is to work. I would like to propose the "ideal" solution but Im still reading the PPP text book and would greatfully receive thoughts on how it really ought to be solved. I include the modified source showing the workaround. Also refer you to the pppd.c sample in the CVS repository. Additionally, I am writing commands to pause the PPP interface, interogate the modem status (ie. go into command mode), execute a command such as "Signal Strength" and then return to Data Mode (ATO) and resume PPP. Has anyone else done this? (the ppp_hackup supports this). Perhaps it is better named "ppp_pause". In the ideal world, I guess this is done by putting the engine into a known PAUSE state as it is possible to have more than one PPP interface. Many Thanks in advance. Brett // If the link is lost, it will try to reopen link if( dcb->dcb_ipcp_state != PPPS_OPENED ) // only proceed if the ppp isnt opened { // Put your code here to ensure the modem is hungup, perhaps : // sleep 1 second, +++, sleep 1 second, ATH // Tell the modem to connect to PPP if (NutChat(pppcom,"'' 'at+cgdcont=1,\"IP\",\"yourAPN\"' 'OK' 'atd*99***1#' 'CONNECT'") == 0) { // attempt to configure the network interface if (NutNetIfConfig("ppp", 0, 0, 0)) { fprintf(tcpip1, "PPP failed\r\n"); fflush(tcpip1); // WORKAROUND CODE STARTS HERE ---- Note ppp_hackup is local to the ppp code and to work like this you must // include the library code in your source or place this code in the library pppdev = NutDeviceLookup("ppp"); ppp_hackup=0; rc=NutPppIOCtl(pppdev, LCP_LOWERDOWN, 0); // WORKAROUND CODE ENDS HERE NutSleep(5000); continue; // go back and try again } else { // Worked // * Set name server and default route. Actually the PPP interface // * should do this, but the current release doesn't. dcb = devPpp.dev_dcb; NutDnsConfig2(0, 0, dcb->dcb_ip_dns1, dcb->dcb_ip_dns2); NutIpRouteAdd(0, 0, dcb->dcb_remote_ip, &devPpp); if((rip = NutDnsGetHostByName(INETSERVER)) != 0) { fprintf(tcpip1, "%s: %s\r\n", INETSERVER, inet_ntoa(rip)); fflush(tcpip1); } } } else { // Error with chat fprintf(tcpip1,"...error in chat \r\n"); fflush(tcpip1); NutSleep(5000); continue; } } ----------------------------------------------------------------- Brett Abbott, Managing Director, Digital Telemetry Limited Email: Brett.Abbott at digital-telemetry.com PO Box 24 036 Manners Street, Wellington, New Zealand Phone +64 (4) 5666-860 Mobile +64 (21) 656-144 ------------------- Commercial in confidence -------------------- _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From Brett.Abbott at digital-telemetry.com Wed Sep 24 04:13:49 2003 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Wed, 24 Sep 2003 14:13:49 +1200 Subject: [En-Nut-Discussion] Pausing PPP to interogate a GPRS modem Message-ID: <3F70FDDD.4080400@digital-telemetry.com> Mike, Thanks for your reply - very helpful. Further on the interrogation of a GPRS modem. Be aware that most modems allow a more elegant (and speedy) means of executing commands whilst in a call (both PPP and data call). (ie. to check Signal Strength, issue AT commands, perhaps change pin numbers etc whilst still in a session). There is an AT config command which allows you to switch between command (issue AT commands) and Data Mode (assuming you are in a PPP session for GPRS or data call for GSM) using the DTR signal line. When this mode is set prior to the connection, you can raise/lower DTR to go between modes - This effectively avoids the 1 second delay whilst the +++ escape sequence takes hold and gives some certainty to the call mode - always a bit dodgy when you have multiple reasons why +++ wont work. Ive tested this method (ie. pausing PPP session to execute commands) on several modems with success from a PC, however not from Ethernut yet but expect no issues. Cheers and Thanks Brett Message: 5 From: "Mike Cornelius" To: Subject: RE: [En-Nut-Discussion] PPP Retrying when no PPP/GPRS is available Date: Wed, 24 Sep 2003 11:06:51 +1000 Organization: CDCS Reply-To: en-nut-discussion at egnite.de Hi Brett, Second things first, I've not tried interrupting the PPP session whilst it's going and then going back. I assume you're thinking something like: <>PPP[] >>+++ >>AT+CSQ? > <+CSQ: ??,?? >>ATO > <>PPP[] But it's certainly an interesting idea and if I get a chance I give it a whirl and let you know what I find. -- ----------------------------------------------------------------- Brett Abbott, Managing Director, Digital Telemetry Limited Email: Brett.Abbott at digital-telemetry.com PO Box 24 036 Manners Street, Wellington, New Zealand Phone +64 (4) 5666-860 Mobile +64 (21) 656-144 ------------------- Commercial in confidence -------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030924/6a9d69e8/attachment.htm From Fahad.Gilani at anu.edu.au Wed Sep 24 09:28:56 2003 From: Fahad.Gilani at anu.edu.au (Fahad G.) Date: Wed, 24 Sep 2003 17:28:56 +1000 Subject: [En-Nut-Discussion] c_turn in turn.c Message-ID: <000c01c3826d$83f2cf00$3cebcb96@Fahad> Hi, What exactly is the function "c_turn(argc, argv)" in turn.c doing (conversely)? By looking at the code I can tell that if 0x55 is not returned, c_turn gets called... since my implementation is a bit different to heyu, could someone explain step-wise what one should do if 0x55 is not returned? Do we wait and send 0x00 again to the device or is there something else that needs to be done? I can't seem to initialize my activehome device upon transmission of 0x00. Thanks, Fahad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20030924/262fced0/attachment.html From ltlee at baycomp.com Tue Sep 23 22:12:18 2003 From: ltlee at baycomp.com (Lin Tak Lee) Date: Tue, 23 Sep 2003 16:12:18 -0400 Subject: [En-Nut-Discussion] Error to generate obj file in WINAVR for ethernut Message-ID: Dear sir/madam, I am implementing a small web server on Ethernut board and want to use AVR studio 4 to do the debugging. At a starting point, I use basemon program, which is already built in app folder, as a foundation and configure it. Since AVR studio needs obj file to debug my program, I use Winavr as a compiler to generate obj file by 'make studio' command. But, I got the following error: ********************************** avr-gcc basemon.o urom.o -mmcu=atmega128 -Wl,--defsym=main=0,-Map=basemon.map,-- cref -L../../lib/gcc/atmega128 -lnutnet -lnutpro -lnutfs -lnutos -lnutdev -lnut net -lnutcrt -o basemon.elf avr-objcopy -O avrobj basemon.elf basemon.obj avr-objcopy: basemon.obj: Invalid bfd target make: *** [basemon.obj] Error 1 rm basemon.elf ********************************** Any solutions? On the other hand, I tried another way and used AVR coff beta package which could generates coff file and is accepted as a target in studio too. But, the sample makefile is not really for building a webserver program. So, do you know where I can get a sample makefile which could generate coff file for a webserver like basemon program? If you have this particular sample makefile file, please send it to me. That would be a big help for me! Thanks! Lin Lee From raymax83 at hotmail.com Thu Sep 25 19:52:25 2003 From: raymax83 at hotmail.com (Niels Bergsma) Date: Thu, 25 Sep 2003 19:52:25 +0200 Subject: [En-Nut-Discussion] Board rev 1.1 question Message-ID: Hi all, I'm working on my board, and right now I have a question about the databus going in and out of the 74573.... what lines come in and out of that IC? I seems to my that pin 2 ... 9 are D0 .... D7 and 12 .... 19 are A7.... A0 (12=A7, 13=A6) is this right ? Thanks, Niels _________________________________________________________________ Hotmail en Messenger on the move http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/ From iliev at caretec.at Fri Sep 26 12:28:44 2003 From: iliev at caretec.at (Ilko Iliev) Date: Fri, 26 Sep 2003 12:28:44 +0200 Subject: [En-Nut-Discussion] message queues in nut Message-ID: <3F7414DC.7060508@caretec.at> Hello, Are there message queues or only semaphores in NutOs? How can I use message queues in NutOs? best regards ilko From olischulz at web.de Sun Sep 28 13:36:33 2003 From: olischulz at web.de (Oliver Schulz) Date: Sun, 28 Sep 2003 13:36:33 +0200 Subject: [En-Nut-Discussion] XRAMEND and strtok_r Message-ID: <000301c385b4$c565b390$5b42a8c0@ose.de> Hello all together, I'm very new to the ethernut development, so be a little bit patient if I ask stupid questions... Yesterday I installed the current HEAD of the CVS repository and the newest release of WinAVR (20030913), which includes the gcc 3.3.1 and the avr-libc 0.99.90.20030829. First Problem: The first try to compile the Nut/OS there was an error because XRAMEND was defined twice. First time in iom128.h to 0xFFFF (64KB) and second at netinit.c to 0x7FFF (32KB). After simple #ifdef .. #undef .. statements in netinit.c this error was fixed. I wonder whether I did something wrong in general, because everybody else must experience the same error, right? Second Problem: The current avr-libc comes with the function strtok_r (but it's not mentioned in the docs), and the prototype is defined in string.h. Nut/OS has its own implementation of strtok_r and the prototype is defined in strtok_r.h. The problem is, that the implementations differ already in the number of parameters, so for example the app httpd will not compile. My workaround is to copy the string.h from the WinAVR\avr\include directory to nut\include and comment out the line with the prototype to use the Nut/OS implementation. But will there be any fix in the CVS in the future? And what is the best solution? Using the avr-libc or still Peter Scandrett's strtok_r? Is there any ANSI C definition of strtok_r? It would be fine, if anyone can answer my questions.. So long, Oliver Schulz. From s354335 at student.uq.edu.au Mon Sep 29 02:09:22 2003 From: s354335 at student.uq.edu.au (Toby Smith) Date: Mon, 29 Sep 2003 10:09:22 +1000 (GMT+1000) Subject: [En-Nut-Discussion] Stack overflow? Message-ID: I'm running some tests of a small Elvin content-based routing library that I've written for the Ethernut. I've test my library on Solaris and it all seems to work fine. I've ported it across to the ethernut. I'm using avrgcc as my compiler. I've converted all the necessary functions and I have my code running okay on the ethernut. With one exception. Whenever I receive a certain type of packet, the machine hangs. I'm using a rather deeply nested set of function calls to parse this packet, and I suspect that I'm overfilling the stack. I suspect this because I've placed printf's before return statements and after the function is called. For eg: ... printf("returing from function XXX\n"); return; ... ... functionXXX(); printf("returned from function XXX\n"); ... And when this runs on the ethernut, line 'returned from blah' never appears for one level of function calls. So it looks like the stack might be getting screwed? I've tried placing my code in another thread and setting the stack size to a huge value, but that didn't seem to help. Any other ideas about what this culd be, or how I could fix it? --Toby From s354335 at student.uq.edu.au Mon Sep 29 05:15:29 2003 From: s354335 at student.uq.edu.au (Toby Smith) Date: Mon, 29 Sep 2003 13:15:29 +1000 (GMT+1000) Subject: [En-Nut-Discussion] Stack overflow? In-Reply-To: References: Message-ID: Never mind. I found the problem. it seems that a 'double' is 64bits on Solaris machines and 32bits on the avr. So when I ported my code across from solaris to the ethernut I forgot to change the number of bytes to copy across from my packets to the automatic variable that stored the result, hence writing over something on the stack prevent the return statement from completing correctly! --Toby On Mon, 29 Sep 2003, Toby Smith wrote: > I'm running some tests of a small Elvin content-based routing library that > I've written for the Ethernut. > > I've test my library on Solaris and it all seems to work fine. > > I've ported it across to the ethernut. I'm using avrgcc as my compiler. > I've converted all the necessary functions and I have my code running okay > on the ethernut. > > With one exception. > > Whenever I receive a certain type of packet, the machine hangs. I'm using > a rather deeply nested set of function calls to parse this packet, and I > suspect that I'm overfilling the stack. > > I suspect this because I've placed printf's before return statements and > after the function is called. > > For eg: > > ... > printf("returing from function XXX\n"); > return; > ... > > ... > functionXXX(); > printf("returned from function XXX\n"); > ... > > And when this runs on the ethernut, line 'returned from blah' never > appears for one level of function calls. So it looks like the stack might > be getting screwed? > > I've tried placing my code in another thread and setting the stack size to > a huge value, but that didn't seem to help. > > Any other ideas about what this culd be, or how I could fix it? > > --Toby > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > From harald.kipp at egnite.de Mon Sep 29 09:24:55 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 29 Sep 2003 09:24:55 +0200 Subject: [En-Nut-Discussion] XRAMEND and strtok_r In-Reply-To: <000301c385b4$c565b390$5b42a8c0@ose.de> Message-ID: <5.1.1.6.0.20030929091941.01a584c0@egnite.de> Hi Oliver, >First Problem: >The first try to compile the Nut/OS there was an error because XRAMEND was >defined twice. First time in iom128.h to 0xFFFF (64KB) and second at >netinit.c to 0x7FFF (32KB). After simple #ifdef .. #undef .. statements in >netinit.c this error was fixed. > >I wonder whether I did something wrong in general, because everybody else >must experience the same error, right? XRAMEND re-appeared in the latest WinAVR. >Second Problem: >The current avr-libc comes with the function strtok_r (but it's not >mentioned in the docs), and the prototype is defined in string.h. Nut/OS has >its own implementation of strtok_r and the prototype is defined in >strtok_r.h. The problem is, that the implementations differ already in the >number of parameters, so for example the app httpd will not compile. > >My workaround is to copy the string.h from the WinAVR\avr\include directory >to nut\include and comment out the line with the prototype to use the Nut/OS >implementation. strtok_r has been added to WinAVR recently. Nut/OS uses a different, incompatible call >But will there be any fix in the CVS in the future? And what is the best >solution? Using the avr-libc or still Peter Scandrett's strtok_r? Is there >any ANSI C definition of strtok_r? I'll commit these and other fixes to the repository soon. It will use strtok_r which come with WinAVR. Thanks for your comments, Harald From harald.kipp at egnite.de Mon Sep 29 09:29:25 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 29 Sep 2003 09:29:25 +0200 Subject: [En-Nut-Discussion] Stack overflow? In-Reply-To: References: Message-ID: <5.1.1.6.0.20030929092601.01a6dae8@egnite.de> Hi Toby, I just started to comment on your last post. :-) Good you found the problem. Yes, in case of stack problems, copy and fill statements like memcpy or memset are the main targets to look for. Harald From harald.kipp at egnite.de Mon Sep 29 20:33:22 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 29 Sep 2003 20:33:22 +0200 Subject: [En-Nut-Discussion] Problems with crurom from CVS Message-ID: <5.1.1.6.0.20030929202947.01a61cc8@egnite.de> It had been reported, that the CVS version of crurom won't work with AVRGCC (WinAVR). I checked this and can't find any problem. Does anyone have problems with /* * $Log: crurom.c,v $ * Revision 1.3 2003/07/20 20:06:28 haraldkipp * MSC compilation error fixed. Harald From troth at openavr.org Mon Sep 29 21:05:20 2003 From: troth at openavr.org (Theodore A. Roth) Date: Mon, 29 Sep 2003 12:05:20 -0700 (PDT) Subject: [En-Nut-Discussion] Problems with crurom from CVS In-Reply-To: <5.1.1.6.0.20030929202947.01a61cc8@egnite.de> References: <5.1.1.6.0.20030929202947.01a61cc8@egnite.de> Message-ID: On Mon, 29 Sep 2003, Harald Kipp wrote: > It had been reported, that the CVS version of > crurom won't work with AVRGCC (WinAVR). > > I checked this and can't find any problem. > Does anyone have problems with > > /* > * $Log: crurom.c,v $ > * Revision 1.3 2003/07/20 20:06:28 haraldkipp > * MSC compilation error fixed. It compiles on linux, but for grins, I just tried to compile it with '-Wall -Werror' and it fails. It could probably use some cleanup. - Needs for read() and write() prototypes. - There's a namespace clash with the system getopt() and the supplied getopt(). - There's some bad formats in a few fprintf() calls. I'd send a patch, but I can't access the anon-cvs repo (man, I wish SF would get that fixed...) Ted Roth From harald.kipp at egnite.de Mon Sep 29 21:07:34 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 29 Sep 2003 21:07:34 +0200 Subject: [En-Nut-Discussion] Problems with crurom from CVS In-Reply-To: References: <5.1.1.6.0.20030929202947.01a61cc8@egnite.de> <5.1.1.6.0.20030929202947.01a61cc8@egnite.de> Message-ID: <5.1.1.6.0.20030929210050.01b613d8@egnite.de> > >I'd send a patch, but I can't access the anon-cvs repo (man, I wish SF >would get that fixed...) Thanks, Ted. No need to send a patch. I'll try '-Wall -Werror' on RH9. Yes, SF's anonymous CVS problem reminds me of German Toll Collect. New time schedule each week. Harald From harald.kipp at egnite.de Tue Sep 30 11:18:39 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 30 Sep 2003 11:18:39 +0200 Subject: [En-Nut-Discussion] DHCP Bugs in Version 3.3.1 Message-ID: <5.1.1.6.0.20030930111418.01a83678@egnite.de> - DHCP lease timing fails, if the system is running without 32 kHz crystal. - DHCP fails, if the server rejects the initial request of the previously used IP. This happens, if you change the IP but keep the MAC. Thanks to Jelle Martijn, who discovered these issues. Harald From harald.kipp at egnite.de Tue Sep 30 11:13:49 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 30 Sep 2003 11:13:49 +0200 Subject: [En-Nut-Discussion] CVS commits Message-ID: <5.1.1.6.0.20030930110720.01b3ce80@egnite.de> A few updates are available via CVS http://cvs.sourceforge.net/viewcvs.py/ethernut/nut/ * Tested with WinAVR-20030913 * app/httpd/httpserv.c: Using strtok and portable version of strtok_r. * crt/srttok_r.c: Incompatible strtok_r marked deprecated and removed from GCC compile. * os/nutinit.c: XRAMEND replaced by NUTRAMEND to avoid GCC conflicts. * app/nutpiper/player.c: Include file sequence changed. * app/nutpiper/scanner.c: dito. Harald From heli.pad at ntlworld.com Tue Sep 30 21:42:16 2003 From: heli.pad at ntlworld.com (helipad) Date: Tue, 30 Sep 2003 20:42:16 +0100 Subject: [En-Nut-Discussion] Bluetooth Message-ID: <001701c3878a$fa51b040$8e7ba8c0@davids2000> before i start , i thought i would ask if anyone has done bluetooth code for ethernut and would be able to share etc , or at least any gotcha's regards all Dave From Douglas.Pearless at pearless.co.nz Tue Sep 30 22:01:06 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Wed, 01 Oct 2003 08:01:06 +1200 Subject: [En-Nut-Discussion] Bluetooth In-Reply-To: <001701c3878a$fa51b040$8e7ba8c0@davids2000> Message-ID: Hi, I too would be interested in this! Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of helipad Sent: Wednesday, 1 October 2003 7:42 a.m. To: En-Nut-Discussion at egnite.de Subject: [En-Nut-Discussion] Bluetooth before i start , i thought i would ask if anyone has done bluetooth code for ethernut and would be able to share etc , or at least any gotcha's regards all Dave _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003 From michael at lfiinternational.com Tue Sep 30 22:48:22 2003 From: michael at lfiinternational.com (Michael G. Svob) Date: Tue, 30 Sep 2003 13:48:22 -0700 Subject: [En-Nut-Discussion] Bluetooth In-Reply-To: Message-ID: Hello, Me three :-) - Michael -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Pearless Sent: Tuesday, September 30, 2003 1:01 PM To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] Bluetooth Hi, I too would be interested in this! Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of helipad Sent: Wednesday, 1 October 2003 7:42 a.m. To: En-Nut-Discussion at egnite.de Subject: [En-Nut-Discussion] Bluetooth before i start , i thought i would ask if anyone has done bluetooth code for ethernut and would be able to share etc , or at least any gotcha's regards all Dave _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003 _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From dvorakvik at seznam.cz Tue Sep 2 22:26:19 2003 From: dvorakvik at seznam.cz (Viktor Dvorak) Date: Tue, 2 Sep 2003 22:26:19 +0200 Subject: [En-Nut-Discussion] ImageCraft library libnutcrtf.a Message-ID: <000c01c37190$782ab540$0200a8c0@viktor> Hi, building the libnutcrtf.a in/for ImageCraft iccavr is simple. Use the content of makefile_gcc for seeing the difference between libnutcrt.a and libnutcrtfa.a and make your own library(s). Librarian name is ilibw.exe. Compile the sourcecode.c using iccavr and make your library usind ilibw -a mylibrary.a myobject.o. Viktor -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbuenaobra at nip.upd.edu.ph Fri Sep 5 20:12:09 2003 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Fri, 5 Sep 2003 11:12:09 -0700 Subject: [En-Nut-Discussion] Querying Ethernut from HTTP References: <20030903100001.30732.73438.Mailman@p15095813.pureserver.info> Message-ID: <009601c373d9$396f5180$5065a8c0@instru.nip.upd.edu.ph> Hello: Just got my kit two days to go and raring to have it wired in the lab. I can ping the address at 192.168.101.82 but cant http://192.168.101.82/index.htm . How is it done? Berns B. ************************************ Bernardino J. Buenaobra University Research Associate National Institute of Physics University of the Philippines Diliman, Quezon City 1101 Philippines Email: bbuenaobra at nip.upd.edu.ph Tel/Voice: +632-434-4232 Fax/Data: +632-928-0296 Mobile: 0916-2550-056 URL: www.nip.upd.edu.ph/ipl ************************************ ----- Original Message ----- From: To: Sent: Wednesday, September 03, 2003 3:00 AM Subject: En-Nut-Discussion digest, Vol 1 #277 - 1 msg > Send En-Nut-Discussion mailing list submissions to > en-nut-discussion at egnite.de > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.egnite.de/mailman/listinfo/en-nut-discussion > or, via email, send a message with subject or body 'help' to > en-nut-discussion-request at egnite.de > > You can reach the person managing the list at > en-nut-discussion-admin at egnite.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of En-Nut-Discussion digest..." > > > Today's Topics: > > 1. ImageCraft library libnutcrtf.a (Viktor Dvorak) > > --__--__-- > > Message: 1 > From: "Viktor Dvorak" > To: > Date: Tue, 2 Sep 2003 22:26:19 +0200 > Subject: [En-Nut-Discussion] ImageCraft library libnutcrtf.a > Reply-To: en-nut-discussion at egnite.de > > Toto je zprava ve formatu MIME obsahujmcm vmce hastm. > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > Content-Type: text/plain; > charset="iso-8859-2" > Content-Transfer-Encoding: quoted-printable > > Hi,=20 > > building the libnutcrtf.a in/for ImageCraft iccavr is simple. Use = > the content of makefile_gcc for seeing the difference between = > libnutcrt.a and libnutcrtfa.a and make your own library(s). Librarian = > name is ilibw.exe. Compile the sourcecode.c using iccavr and make your = > library usind ilibw -a mylibrary.a myobject.o. > > Viktor > > > > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > Content-Type: text/html; > charset="iso-8859-2" > Content-Transfer-Encoding: quoted-printable > > > > http-equiv=3DContent-Type> > > > > >
Hi,
>
 
>
    building the = > libnutcrtf.a=20 > in/for ImageCraft iccavr is simple. Use the content of makefile_gcc for = > seeing=20 > the difference between libnutcrt.a and libnutcrtfa.a and make your = > own=20 > library(s). Librarian name is ilibw.exe. Compile the sourcecode.c using = > iccavr=20 > and make your library usind ilibw -a mylibrary.a = > myobject.o.
>
 
>
    = > Viktor
>
 
>
 
> > ------=_NextPart_000_0009_01C371A1.3B5F98E0-- > > > > --__--__-- > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > > End of En-Nut-Discussion Digest > From Douglas.Pearless at pearless.co.nz Fri Sep 5 06:15:44 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Fri, 05 Sep 2003 16:15:44 +1200 Subject: [En-Nut-Discussion] Querying Ethernut from HTTP In-Reply-To: <009601c373d9$396f5180$5065a8c0@instru.nip.upd.edu.ph> Message-ID: try 192.168.168.101:82 (:82 means port 82, unless you are usign another port!) Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Berns J. Buenaobra Sent: Saturday, 6 September 2003 6:12 a.m. To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] Querying Ethernut from HTTP Hello: Just got my kit two days to go and raring to have it wired in the lab. I can ping the address at 192.168.101.82 but cant http://192.168.101.82/index.htm . How is it done? Berns B. ************************************ Bernardino J. Buenaobra University Research Associate National Institute of Physics University of the Philippines Diliman, Quezon City 1101 Philippines Email: bbuenaobra at nip.upd.edu.ph Tel/Voice: +632-434-4232 Fax/Data: +632-928-0296 Mobile: 0916-2550-056 URL: www.nip.upd.edu.ph/ipl ************************************ ----- Original Message ----- From: To: Sent: Wednesday, September 03, 2003 3:00 AM Subject: En-Nut-Discussion digest, Vol 1 #277 - 1 msg > Send En-Nut-Discussion mailing list submissions to > en-nut-discussion at egnite.de > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.egnite.de/mailman/listinfo/en-nut-discussion > or, via email, send a message with subject or body 'help' to > en-nut-discussion-request at egnite.de > > You can reach the person managing the list at > en-nut-discussion-admin at egnite.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of En-Nut-Discussion digest..." > > > Today's Topics: > > 1. ImageCraft library libnutcrtf.a (Viktor Dvorak) > > --__--__-- > > Message: 1 > From: "Viktor Dvorak" > To: > Date: Tue, 2 Sep 2003 22:26:19 +0200 > Subject: [En-Nut-Discussion] ImageCraft library libnutcrtf.a > Reply-To: en-nut-discussion at egnite.de > > Toto je zprava ve formatu MIME obsahujmcm vmce hastm. > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > Content-Type: text/plain; > charset="iso-8859-2" > Content-Transfer-Encoding: quoted-printable > > Hi,=20 > > building the libnutcrtf.a in/for ImageCraft iccavr is simple. Use = > the content of makefile_gcc for seeing the difference between = > libnutcrt.a and libnutcrtfa.a and make your own library(s). Librarian = > name is ilibw.exe. Compile the sourcecode.c using iccavr and make your = > library usind ilibw -a mylibrary.a myobject.o. > > Viktor > > > > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > Content-Type: text/html; > charset="iso-8859-2" > Content-Transfer-Encoding: quoted-printable > > > > http-equiv=3DContent-Type> > > > > >
Hi,
>
 
>
    building the = > libnutcrtf.a=20 > in/for ImageCraft iccavr is simple. Use the content of makefile_gcc for = > seeing=20 > the difference between libnutcrt.a and libnutcrtfa.a and make your = > own=20 > library(s). Librarian name is ilibw.exe. Compile the sourcecode.c using = > iccavr=20 > and make your library usind ilibw -a mylibrary.a = > myobject.o.
>
 
>
    = > Viktor
>
 
>
 
> > ------=_NextPart_000_0009_01C371A1.3B5F98E0-- > > > > --__--__-- > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > > End of En-Nut-Discussion Digest > _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.514 / Virus Database: 312 - Release Date: 28/08/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.514 / Virus Database: 312 - Release Date: 28/08/2003 From bbuenaobra at nip.upd.edu.ph Fri Sep 5 23:35:12 2003 From: bbuenaobra at nip.upd.edu.ph (Berns J. Buenaobra) Date: Fri, 5 Sep 2003 14:35:12 -0700 Subject: [En-Nut-Discussion] Re: Querying Ethernut from HTTP Message-ID: <00c601c373f5$96b175a0$5065a8c0@instru.nip.upd.edu.ph> Hello: We figured that the PROXY server has to be disabled for this to work. Thanks. Berns B. ************************************ Bernardino J. Buenaobra University Research Associate National Institute of Physics University of the Philippines Diliman, Quezon City 1101 Philippines Email: bbuenaobra at nip.upd.edu.ph Tel/Voice: +632-434-4232 Fax/Data: +632-928-0296 Mobile: 0916-2550-056 URL: www.nip.upd.edu.ph/ipl ************************************ ----- Original Message ----- From: "Berns J. Buenaobra" To: Sent: Friday, September 05, 2003 11:12 AM Subject: Querying Ethernut from HTTP > Hello: > > Just got my kit two days to go and raring to have it wired in the lab. I can > ping the address at 192.168.101.82 but cant http://192.168.101.82/index.htm > . How is it done? > > Berns B. > > > > > ************************************ > Bernardino J. Buenaobra > University Research Associate > National Institute of Physics > University of the Philippines > Diliman, Quezon City 1101 > Philippines > > Email: bbuenaobra at nip.upd.edu.ph > Tel/Voice: +632-434-4232 > Fax/Data: +632-928-0296 > Mobile: 0916-2550-056 > URL: www.nip.upd.edu.ph/ipl > ************************************ > > ----- Original Message ----- > From: > To: > Sent: Wednesday, September 03, 2003 3:00 AM > Subject: En-Nut-Discussion digest, Vol 1 #277 - 1 msg > > > > Send En-Nut-Discussion mailing list submissions to > > en-nut-discussion at egnite.de > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > or, via email, send a message with subject or body 'help' to > > en-nut-discussion-request at egnite.de > > > > You can reach the person managing the list at > > en-nut-discussion-admin at egnite.de > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of En-Nut-Discussion digest..." > > > > > > Today's Topics: > > > > 1. ImageCraft library libnutcrtf.a (Viktor Dvorak) > > > > --__--__-- > > > > Message: 1 > > From: "Viktor Dvorak" > > To: > > Date: Tue, 2 Sep 2003 22:26:19 +0200 > > Subject: [En-Nut-Discussion] ImageCraft library libnutcrtf.a > > Reply-To: en-nut-discussion at egnite.de > > > > Toto je zprava ve formatu MIME obsahujmcm vmce hastm. > > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > > Content-Type: text/plain; > > charset="iso-8859-2" > > Content-Transfer-Encoding: quoted-printable > > > > Hi,=20 > > > > building the libnutcrtf.a in/for ImageCraft iccavr is simple. Use = > > the content of makefile_gcc for seeing the difference between = > > libnutcrt.a and libnutcrtfa.a and make your own library(s). Librarian = > > name is ilibw.exe. Compile the sourcecode.c using iccavr and make your = > > library usind ilibw -a mylibrary.a myobject.o. > > > > Viktor > > > > > > > > ------=_NextPart_000_0009_01C371A1.3B5F98E0 > > Content-Type: text/html; > > charset="iso-8859-2" > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > http-equiv=3DContent-Type> > > > > > > > > > >
Hi,
> >
 
> >
    building the = > > libnutcrtf.a=20 > > in/for ImageCraft iccavr is simple. Use the content of makefile_gcc for = > > seeing=20 > > the difference between libnutcrt.a and libnutcrtfa.a and make your = > > own=20 > > library(s). Librarian name is ilibw.exe. Compile the sourcecode.c using = > > iccavr=20 > > and make your library usind ilibw -a mylibrary.a = > > myobject.o.
> >
 
> >
    = > > Viktor
> >
 
> >
 
> > > > ------=_NextPart_000_0009_01C371A1.3B5F98E0-- > > > > > > > > --__--__-- > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > > > > > End of En-Nut-Discussion Digest > > > From janne.jarvinen at pp8.inet.fi Fri Sep 5 08:53:27 2003 From: janne.jarvinen at pp8.inet.fi (janne.jarvinen at pp8.inet.fi) Date: Fri, 5 Sep 2003 9:53:27 +0300 Subject: [En-Nut-Discussion] Porting Enut to STK300 Message-ID: <20030905065327.CBKO5025.fep05.tmt.tele.fi@fep05> Hi Is there any document or anything about howto port critical parts of Nut/OS to other hardware ? I gave a try to compile example applications for atmega103, but neither "threads" or "simple" did work on stk300 hardware. I am kind of confused which parts belongs to OS and which are for Ethernut board to work... Janne From harald.kipp at egnite.de Fri Sep 5 11:33:49 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 05 Sep 2003 11:33:49 +0200 Subject: [En-Nut-Discussion] Porting Enut to STK300 In-Reply-To: <20030905065327.CBKO5025.fep05.tmt.tele.fi@fep05> Message-ID: <5.1.1.6.0.20030905112823.02dd6008@egnite.de> Hi Janne, there is no hardware dependency other than the CPU and the required 32kHz clock crystal with the samples you tested. They should work on the STK300. As far as I can remember, the STK300 comes with the second crystal, right? Are you sure you compiled and linked ATmega103 code? Did you call ./configure (Linux) or nutconf.exe (Win32)? Harald From janne.jarvinen at pp8.inet.fi Fri Sep 5 14:19:34 2003 From: janne.jarvinen at pp8.inet.fi (janne.jarvinen at pp8.inet.fi) Date: Fri, 5 Sep 2003 15:19:34 +0300 Subject: Vas: Re: [En-Nut-Discussion] Porting Enut to STK300 Message-ID: <20030905121934.CLSR5025.fep05.tmt.tele.fi@fep05> Yes, I have run it in atmega103 mode. What about other services it offers like LCD and UART interfaces ? I tried to configure LCD stuff in medianut configuration file but it didn?t solve anything. > > L?hett?j?: Harald Kipp > P?iv?: 05.09.2003 12:33 > Vastaanottaja: en-nut-discussion at egnite.de > Otsikko: Re: [En-Nut-Discussion] Porting Enut to STK300 > > Hi Janne, > > there is no hardware dependency other than the CPU and > the required 32kHz clock crystal with the samples you > tested. They should work on the STK300. As far as I can > remember, the STK300 comes with the second crystal, right? > > Are you sure you compiled and linked ATmega103 code? Did > you call ./configure (Linux) or nutconf.exe (Win32)? > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > From harald.kipp at egnite.de Fri Sep 5 15:21:48 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 05 Sep 2003 15:21:48 +0200 Subject: Vas: Re: [En-Nut-Discussion] Porting Enut to STK300 In-Reply-To: <20030905121934.CLSR5025.fep05.tmt.tele.fi@fep05> Message-ID: <5.1.1.6.0.20030905152038.02cc4480@egnite.de> > >I tried to configure LCD stuff in medianut configuration file but it >didn?t solve anything. Make sure to call make clean followed by make install in the topmost nut directory if you change any system header. Harald From laran at ikp.liu.se Sat Sep 6 13:16:47 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Sat, 6 Sep 2003 13:16:47 +0200 Subject: [En-Nut-Discussion] Problem with gateway when using DHCP Message-ID: <6D71E1FB451D984081153EC11D7A3DDB91AA6C@mail.ikp.liu.se> I'll try with Ethereal first thing on monday morning. As soon as I have figured Ethereal out I'll get back with the results :) /Lars -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: den 30 augusti 2003 11:51 To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] Problem with gateway when using DHCP Would it be possible to install Ethereal? However, you need to attach both, the PC running Ethereal and the Ethernut board, to a HUB, not an Ethernet switch. Btw. which Nut/OS version do you use? Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From faxel at zoellich.de Sat Sep 6 19:24:44 2003 From: faxel at zoellich.de (=?iso-8859-1?q?Z=F6llich=20Axel?=) Date: Sat, 6 Sep 2003 19:24:44 +0200 Subject: [En-Nut-Discussion] httpd response Message-ID: <200309061924.44449.faxel@zoellich.de> Greetings, I'm using an ethernut board with ATMEGA103. The ethernut-version is 3.3.0. Linux enviroment with avr-gcc. The example apps basemon and httpd both send an response to requests to cgi-bin/... But if I request some file located in the html or sample dir I get an 404 error. The make run builds the urom.c file, compiles it to urom.o and as far as I understand it links it to the .hex file. Any help would be appreciated. Thanks, Axel From unreal at home.nl Mon Sep 8 17:39:55 2003 From: unreal at home.nl (Michel) Date: Mon, 8 Sep 2003 17:39:55 +0200 (CEST) Subject: [En-Nut-Discussion] Ethernet interface not properly booting In-Reply-To: <200309061924.44449.faxel@zoellich.de> References: <200309061924.44449.faxel@zoellich.de> Message-ID: <37135.193.67.187.139.1063035595.squirrel@cp233264-a.dbsch1.nb.home.nl> Hi, I've been working with ethernut for a couple of months now and I'm impressed with it's capabilities and ease of working with it. But now I seem to have some problems with the ethernet interface not booting properly: When I use the reset button (or reboot from within WinAVR) the ethernet device does not get a connection with my switch (a Linksys wireless AP with builtin 4 port 100Mbit switch). When I unplug the 9V and plug it back in the ethernet adapter has no problems getting a link with my switch. And after that I can do some debugging, get UART output, setup an internet connection, etc. So for some reason the ethernet device is not properly reset except at power on. This is very strange because my setup didn't change and it always used to reinitialise without problems. I already tried to give some extra resets but that didn't work. Apparently because I have the 1.3F board where the reset line for ethernet is not connected to any processor I/O. I checked all the cables and found no problems. Does anyone else have this problem? How can I detect in software if ethernet was started ok and then take some action? Greetings, Michel From ethernut at ma.stendahls.net Mon Sep 8 00:17:49 2003 From: ethernut at ma.stendahls.net (Mikael Adolfsson) Date: Mon, 8 Sep 2003 00:17:49 +0200 (CEST) Subject: [En-Nut-Discussion] HTTP QueryString parser Message-ID: Hi, I've made some modifications to the pro/httpd to make it able to parse the QueryString into a decoded table, so you can access form parameters more easily. Feel free to use it, or put it into the Nut/OS source, if you find it usefull. Please note that this code is not tested on the ethernut board. It's only tested on my homebuilt hardware, but should work fine on ethernut as well. In the attached .zip-file, you'll find both the modified source-files and their coresponding patch-files. The added functions are: char *NutHttpURLEncode (char *str); void NutHttpURLDecode (char *str); char *NutHttpGetParameter (REQUEST *req, char *name); int NutHttpGetParameterCount (REQUEST *req); char *NutHttpGetParameterName (REQUEST *req, int index); char *NutHttpGetParameterValue (REQUEST *req, int index); Btw, I have a (very unfinished) smtp-module as well if someone is interested. I've found it usefull to let the board notify me by email on special events etc. At the moment this module can only send simple mails. Mikael -------------- next part -------------- A non-text attachment was scrubbed... Name: httpd_param_patch.zip Type: application/zip Size: 9292 bytes Desc: URL: From ngbmoreau at yahoo.com.au Wed Sep 10 00:30:40 2003 From: ngbmoreau at yahoo.com.au (NGB) Date: Wed, 10 Sep 2003 08:30:40 +1000 Subject: [En-Nut-Discussion] Strange problem Message-ID: <1063146640.3f5e5490a6b24@tiger> Hi I recntly upgraded to 3.3 of the library and I'm seeing strange things running the example programs. For starters the board takes for ever to start up !! (this is a customn board, but have worked flwalessly in the past) Once it's up the http server works, but displaying the threads produces an endless list of dummy threads (the first 4 are ok) Considering how the code is written while(tdp) { ... tdp = tdp->td_next; I am suspecting next is never NULL could this be due to the BSS no been cleared on startup ? In case it helps, I am linking the source with these libs: LIBS = $(LIBDIR)/nutinit.o -lnutnet -lnutpro -lnutfs -lnutos -lnutdev -lnutnet -lnutcrt Thanks Nick ------------------------------------------------- From laran at ikp.liu.se Wed Sep 10 18:10:01 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Wed, 10 Sep 2003 18:10:01 +0200 Subject: [En-Nut-Discussion] HTTP QueryString parser Message-ID: <6D71E1FB451D984081153EC11D7A3DDB178738@mail.ikp.liu.se> Hi, I have tried some of your functions and with mixed success. When I do the following operation the processor sometimes hang and most of the time the output strings ook very strange. char *cpn; char *cpv; u_char i; u_char count; count=NutHttpGetParameterCount(req); for (i =0 ; i < count; i++) { cpn=NutHttpGetParameterName(req, i); cpv=NutHttpGetParameterValue(req, i); printf("%s:%s\n\r",cpn,cpv); } please advise, Regards, /Lars -----Original Message----- From: Mikael Adolfsson [mailto:ethernut at ma.stendahls.net] Sent: den 8 september 2003 00:18 To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] HTTP QueryString parser Hi, I've made some modifications to the pro/httpd to make it able to parse the QueryString into a decoded table, so you can access form parameters more easily. Feel free to use it, or put it into the Nut/OS source, if you find it usefull. Please note that this code is not tested on the ethernut board. It's only tested on my homebuilt hardware, but should work fine on ethernut as well. In the attached .zip-file, you'll find both the modified source-files and their coresponding patch-files. The added functions are: char *NutHttpURLEncode (char *str); void NutHttpURLDecode (char *str); char *NutHttpGetParameter (REQUEST *req, char *name); int NutHttpGetParameterCount (REQUEST *req); char *NutHttpGetParameterName (REQUEST *req, int index); char *NutHttpGetParameterValue (REQUEST *req, int index); Btw, I have a (very unfinished) smtp-module as well if someone is interested. I've found it usefull to let the board notify me by email on special events etc. At the moment this module can only send simple mails. Mikael From harald.kipp at egnite.de Wed Sep 10 18:21:27 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 10 Sep 2003 18:21:27 +0200 Subject: [En-Nut-Discussion] Strange problem In-Reply-To: <1063146640.3f5e5490a6b24@tiger> Message-ID: <5.1.1.6.0.20030910181732.01b44c60@egnite.de> Hi Nick, Because you are using a Makefile, I assume GCC, not Imagecraft. May be you need to update your Makefile. Note, that version 3.3 doesn't include main(). GCC handles main() in a strange way, updating the stack pointer again. Have a look to the Makefiles in the app samples. Harald From harald.kipp at egnite.de Wed Sep 10 18:36:16 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 10 Sep 2003 18:36:16 +0200 Subject: [En-Nut-Discussion] Ethernet interface not properly booting In-Reply-To: <37135.193.67.187.139.1063035595.squirrel@cp233264-a.dbsch1 .nb.home.nl> References: <200309061924.44449.faxel@zoellich.de> <200309061924.44449.faxel@zoellich.de> Message-ID: <5.1.1.6.0.20030910182335.01a9ac70@egnite.de> Michel, The opposite case is well known. Power on will fail, if the DS1811 is broken, because the Realtek needs a hardware reset signal. May be the reset switch weared out, producing a bad signal. We replaced the previous Omron through hole reset switch with the Schurter SMD part. Hopefully that wasn't a bad decision. Just today I talked to another user on the phone, who experienced a similar problem. But it fortunately disappeared as sudden as it appeared. He critisized, that there's no RC delay mounted at the reset switch to avoid switching noise and I replied, that there were no problems with it so far...grumble... Anyone else around here with reset switch problems and Rev. 1.3F? Harald From lakab at telia.com Wed Sep 10 20:01:29 2003 From: lakab at telia.com (Lars Andersson) Date: Wed, 10 Sep 2003 20:01:29 +0200 Subject: [En-Nut-Discussion] Ethernet interface not properly booting In-Reply-To: <5.1.1.6.0.20030910182335.01a9ac70@egnite.de> Message-ID: <000001c377c5$8f4ee1c0$0d01a8c0@p3> Maybe you should look at DS1813 to replace DS1811? It debounces the reset push button. I do not have the schematic of version F but I belive it will work on your board w/o modification. Lars H. Andersson (Lots of Lars Anderssons on this group so I put a middle initial in) -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of Harald Kipp Sent: Wednesday, 10 September, 2003 18:36 To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] Ethernet interface not properly booting Michel, The opposite case is well known. Power on will fail, if the DS1811 is broken, because the Realtek needs a hardware reset signal. May be the reset switch weared out, producing a bad signal. We replaced the previous Omron through hole reset switch with the Schurter SMD part. Hopefully that wasn't a bad decision. Just today I talked to another user on the phone, who experienced a similar problem. But it fortunately disappeared as sudden as it appeared. He critisized, that there's no RC delay mounted at the reset switch to avoid switching noise and I replied, that there were no problems with it so far...grumble... Anyone else around here with reset switch problems and Rev. 1.3F? Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From harald.kipp at egnite.de Wed Sep 10 20:15:41 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 10 Sep 2003 20:15:41 +0200 Subject: [En-Nut-Discussion] Ethernet interface not properly booting In-Reply-To: <000001c377c5$8f4ee1c0$0d01a8c0@p3> References: <5.1.1.6.0.20030910182335.01a9ac70@egnite.de> Message-ID: <5.1.1.6.0.20030910200815.01a9adb8@egnite.de> Yes, the DS1813 would have been the better choice. Thanks for the hint. Harald From harald.kipp at egnite.de Wed Sep 10 20:15:35 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 10 Sep 2003 20:15:35 +0200 Subject: [En-Nut-Discussion] httpd response In-Reply-To: <200309061924.44449.faxel@zoellich.de> Message-ID: <5.1.1.6.0.20030910201232.01a0bec0@egnite.de> It has been reported recently, that the CVS version of crurom might be broken. I haven't checked it so far. Here's the part of the email (thanks to Jelle): ----------- The changes to uromfs.c are not correctly working with crurom.exe. Crurom.exe doesn't make a "PSTR filename" in the c file it generates: static ROMENTRY file1entry = { 0, "keyboard.bin", 2002, (prog_char *)file1data }; while I guess it should be: static ROMENTRY file1entry = { 0, PSTR("keyboard.bin"), 2002, (prog_char *)file1data }; (So I'm still running with the old urom for the moment) (The "tricky" part is that the compiler doesn't generate any kind of warning for this error) ----------- From ethernut at ma.stendahls.net Wed Sep 10 21:42:50 2003 From: ethernut at ma.stendahls.net (Mikael Adolfsson) Date: Wed, 10 Sep 2003 21:42:50 +0200 (CEST) Subject: [En-Nut-Discussion] HTTP QueryString parser In-Reply-To: <6D71E1FB451D984081153EC11D7A3DDB178738@mail.ikp.liu.se> Message-ID: Hi, Your code is a correct way of using it. Here are a few things to check: Do you get various results on the same querystring? Does the NutHttpGetParameter(req, name)-method work? Can you see if the mpu hangs before it enters your cgi, or if it hangs on one of the NutHttpGet*-methods? (The querystring is parsed, when NutHttpProcessRequest() finds out that the request contains a questionmark) What version of Nut/OS do you use? The patch I submitted was based on the current Nut/OS 3.3-file, taken from the cvs 7/9. Did you use my httpd.c-file or did you patch your own httpd.c? I first wrote this code for Nut/OS 2.2(?), and I have to admit that I just applied my changes to the 3.3-file. The httpd.c-file is only tested with my modified version of Nut/OS 3.3. As I mentioned before, this code is not tested on the ethernut board; only on my hardare. I will test it further as soon as I get one. / Mikael On Wed, 10 Sep 2003, Lars Andersson wrote: > Hi, > > I have tried some of your functions and with mixed success. > > When I do the following operation the processor sometimes hang and most > of the time the output strings look very strange. > > char *cpn; > char *cpv; > u_char i; > u_char count; > > count=NutHttpGetParameterCount(req); > for (i =0 ; i < count; i++) > { > cpn=NutHttpGetParameterName(req, i); > cpv=NutHttpGetParameterValue(req, i); > printf("%s:%s\n\r",cpn,cpv); > } > > please advise, > > Regards, > /Lars From laran at ikp.liu.se Wed Sep 10 22:33:33 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Wed, 10 Sep 2003 22:33:33 +0200 Subject: [En-Nut-Discussion] HTTP QueryString parser Message-ID: <6D71E1FB451D984081153EC11D7A3DDB178739@mail.ikp.liu.se> Hi Mikael, Sorry for not being specific on the version and HW. I am using Nut/OS 3.3 on a rev-d board. I have found out that the "NutHttpGetParameterCount" function works fine and returns the correct number of parameters. It seams that the mpu makes weird things inside the loop. The output is different for the same query string. I have used the httpd.c and httpd.h files and not patched anything. Do you have any clue on how much memory this process requires compared to the original code. Could it be that I have not dedicated enough memory when starting the thread dong the processing? I'll try this code in a simpler application than I am working on right now and see what happens. Regards, /Lars A Andersson -----Original Message----- From: Mikael Adolfsson [mailto:ethernut at ma.stendahls.net] Sent: den 10 september 2003 21:43 To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] HTTP QueryString parser Hi, Your code is a correct way of using it. Here are a few things to check: Do you get various results on the same querystring? Does the NutHttpGetParameter(req, name)-method work? Can you see if the mpu hangs before it enters your cgi, or if it hangs on one of the NutHttpGet*-methods? (The querystring is parsed, when NutHttpProcessRequest() finds out that the request contains a questionmark) What version of Nut/OS do you use? The patch I submitted was based on the current Nut/OS 3.3-file, taken from the cvs 7/9. Did you use my httpd.c-file or did you patch your own httpd.c? I first wrote this code for Nut/OS 2.2(?), and I have to admit that I just applied my changes to the 3.3-file. The httpd.c-file is only tested with my modified version of Nut/OS 3.3. As I mentioned before, this code is not tested on the ethernut board; only on my hardare. I will test it further as soon as I get one. / Mikael On Wed, 10 Sep 2003, Lars Andersson wrote: > Hi, > > I have tried some of your functions and with mixed success. > > When I do the following operation the processor sometimes hang and most > of the time the output strings look very strange. > > char *cpn; > char *cpv; > u_char i; > u_char count; > > count=NutHttpGetParameterCount(req); > for (i =0 ; i < count; i++) > { > cpn=NutHttpGetParameterName(req, i); > cpv=NutHttpGetParameterValue(req, i); > printf("%s:%s\n\r",cpn,cpv); > } > > please advise, > > Regards, > /Lars _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From ethernut at ma.stendahls.net Wed Sep 10 23:19:14 2003 From: ethernut at ma.stendahls.net (Mikael Adolfsson) Date: Wed, 10 Sep 2003 23:19:14 +0200 (CEST) Subject: [En-Nut-Discussion] HTTP QueryString parser In-Reply-To: <6D71E1FB451D984081153EC11D7A3DDB178739@mail.ikp.liu.se> Message-ID: Hi, hmm, interesting. Since you get the right number of parameters, it sounds like there isn't enough memory left on the stack. Also, if there aren't enough memory on the heap, the parser will stop, and NutHttpGetParameterCount will allways return 0. I'm not sure how much memory is required on the stack, but at least it uses very little memory on the heap. Try allocating more stack. When the query string is parsed, the req->req_query property is overwritten with the parsed data, since the decoded content is allways less or equal the size of req_query (and I guess most users don't need the req_query after that). The only extra allocated memory in the heap are two times the number of parameters in the query string. I just noted also that I'm using register hints on the local variables. Maybe there's a compiler issue here. What compiler/version do you use? I'm using avr-gcc 3.3(20030421). Btw, how long is your querystring in total? Request method+requested file+parameters+version may not be longer than 256 chars. / Mikael On Wed, 10 Sep 2003, Lars Andersson wrote: > Hi Mikael, > > Sorry for not being specific on the version and HW. I am using Nut/OS > 3.3 on a rev-d board. > > I have found out that the "NutHttpGetParameterCount" function works fine > and returns the correct number of parameters. It seams that the mpu > makes weird things inside the loop. The output is different for the same > query string. > > I have used the httpd.c and httpd.h files and not patched anything. > > Do you have any clue on how much memory this process requires compared > to the original code. Could it be that I have not dedicated enough > memory when starting the thread dong the processing? > > I'll try this code in a simpler application than I am working on right > now and see what happens. From ngbmoreau at yahoo.com.au Thu Sep 11 01:53:39 2003 From: ngbmoreau at yahoo.com.au (NGB) Date: Thu, 11 Sep 2003 09:53:39 +1000 Subject: [En-Nut-Discussion] Strange problem In-Reply-To: <5.1.1.6.0.20030910181732.01b44c60@egnite.de> References: <5.1.1.6.0.20030910181732.01b44c60@egnite.de> Message-ID: <1063238019.3f5fb98362b94@tiger> Hi Found the problem, a buffer overflow in another routine was corrupting the thread list !! Thanks Nicolas Quoting Harald Kipp : > Hi Nick, > > Because you are using a Makefile, I assume GCC, not Imagecraft. > May be you need to update your Makefile. Note, that version 3.3 > doesn't include main(). GCC handles main() in a strange way, > updating the stack pointer again. Have a look to the Makefiles > in the app samples. > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > ------------------------------------------------- From leedavies at comtech.uk.com Thu Sep 11 15:51:51 2003 From: leedavies at comtech.uk.com (Lee Davies) Date: Thu, 11 Sep 2003 14:51:51 +0100 Subject: [En-Nut-Discussion] ARM support ??? Message-ID: <002901c3786b$dac54120$4500a8c0@comtech.uk.com> Hello Everyone, I read in earlier thread that an ARM port of the NUT was underway. Have I got the facts right, if so does anybody have any details on when this version will be available and which ARM processor is it using ? Regards, Lee From laran at ikp.liu.se Fri Sep 12 09:59:39 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Fri, 12 Sep 2003 09:59:39 +0200 Subject: [En-Nut-Discussion] HTTP QueryString parser Message-ID: <6D71E1FB451D984081153EC11D7A3DDB17873B@mail.ikp.liu.se> Mikael, I use the same compiler version as you. The query string is also less than 256 chars. I tried to implement similar code to what I explained earlier into the httpd example that comes with the NUT/OS distribution. At first it seemed to work fine, but after a while I noticed that the system was very unstable. It seems that the connection is never closed. Could there be some memory leak? /Lars A Andersson -----Original Message----- From: Mikael Adolfsson [mailto:ethernut at ma.stendahls.net] Sent: den 10 september 2003 23:19 To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] HTTP QueryString parser Hi, hmm, interesting. Since you get the right number of parameters, it sounds like there isn't enough memory left on the stack. Also, if there aren't enough memory on the heap, the parser will stop, and NutHttpGetParameterCount will allways return 0. I'm not sure how much memory is required on the stack, but at least it uses very little memory on the heap. Try allocating more stack. When the query string is parsed, the req->req_query property is overwritten with the parsed data, since the decoded content is allways less or equal the size of req_query (and I guess most users don't need the req_query after that). The only extra allocated memory in the heap are two times the number of parameters in the query string. I just noted also that I'm using register hints on the local variables. Maybe there's a compiler issue here. What compiler/version do you use? I'm using avr-gcc 3.3(20030421). Btw, how long is your querystring in total? Request method+requested file+parameters+version may not be longer than 256 chars. / Mikael On Wed, 10 Sep 2003, Lars Andersson wrote: > Hi Mikael, > > Sorry for not being specific on the version and HW. I am using Nut/OS > 3.3 on a rev-d board. > > I have found out that the "NutHttpGetParameterCount" function works fine > and returns the correct number of parameters. It seams that the mpu > makes weird things inside the loop. The output is different for the same > query string. > > I have used the httpd.c and httpd.h files and not patched anything. > > Do you have any clue on how much memory this process requires compared > to the original code. Could it be that I have not dedicated enough > memory when starting the thread dong the processing? > > I'll try this code in a simpler application than I am working on right > now and see what happens. _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From leedavies at comtech.uk.com Fri Sep 12 18:19:53 2003 From: leedavies at comtech.uk.com (Lee Davies) Date: Fri, 12 Sep 2003 17:19:53 +0100 Subject: [En-Nut-Discussion] ARM support ??? In-Reply-To: <002901c3786b$dac54120$4500a8c0@comtech.uk.com> Message-ID: <002101c37949$b3989280$4500a8c0@comtech.uk.com> I guess not then ??? -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Lee Davies Sent: 11 September 2003 14:52 To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] ARM support ??? Hello Everyone, I read in earlier thread that an ARM port of the NUT was underway. Have I got the facts right, if so does anybody have any details on when this version will be available and which ARM processor is it using ? Regards, Lee _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From harald.kipp at egnite.de Fri Sep 12 18:27:38 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 12 Sep 2003 18:27:38 +0200 Subject: [En-Nut-Discussion] ARM support ??? In-Reply-To: <002101c37949$b3989280$4500a8c0@comtech.uk.com> References: <002901c3786b$dac54120$4500a8c0@comtech.uk.com> Message-ID: <5.1.1.6.0.20030912182557.019f7de0@egnite.de> >I guess not then ??? :-) As far as time allows I'm preparing Nut/OS Version 4, which removes portability issues. But time doesn't allow much at the moment. Harald From peter.scandrett at transport.alstom.com Wed Sep 10 04:48:52 2003 From: peter.scandrett at transport.alstom.com (peter.scandrett at transport.alstom.com) Date: Wed, 10 Sep 2003 12:48:52 +1000 Subject: [En-Nut-Discussion] strtok_r conflicts Message-ID: Hi all, About a month ago there was a lot of comments about my version STRTOK_R and the prototype being different to everyone else's prototype. Attached is my compliant version. I have implemented it because 1. I need the separator functions STRSEP_R and STRSEP_RS. 2. STRTOK_R is not available on other platforms, and I need it there. So enjoy. Here is the test code. The output from STRTOK_R is identical to the Borland version of STRTOK. Peter S Peter Scandrett Engineering Systems Department ALSTOM Australia Limited 3 Bridge Street, Pymble, 2073, Australia Phone (+612) 94 88 49 11 Fax (+612) 94 88 49 00 peter.scandrett at transport.alstom.com :.________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: STRTOK_R.h Type: application/octet-stream Size: 1041 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: STRTOK_R.c Type: application/octet-stream Size: 6536 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Check_STRTOK_R.c Type: application/octet-stream Size: 2049 bytes Desc: not available URL: From ma at stendahls.net Fri Sep 12 21:20:06 2003 From: ma at stendahls.net (Mikael Adolfsson) Date: Fri, 12 Sep 2003 21:20:06 +0200 (CEST) Subject: [En-Nut-Discussion] Re: smtp over ethernut In-Reply-To: <3F61280C.8050003@digital-telemetry.com> Message-ID: On Fri, 12 Sep 2003, Brett Abbott wrote: > Mikael > > Im very much interested in your prototype smtp code. I was about to > launch into writing a similar module. If you have a chance, I'd love a > copy of the source as it is to date. > Are you expecting to publish it to nut/os? Hi, here is a working prototype. It's quite uggly written, but it fulfills my current needs. I'll probably rewrite it completely in a later date. Currently the whole message body needs to be in ram. I'd rather like it being a stream. / Mikael -------------- next part -------------- /* SMTP module for ECBlite, based on Nut/OS */ #include #include #include #include #include #include #include #include #include static FILE *debugStream; static u_char debugEnabled = 0; /* * Waits for a message, and stores it into buff (mostly to save RAM) */ static int SMTPWaitMessage (FILE *stream, char *buff, int size) { int n; fgets (buff, size, stream); if (debugEnabled) fprintf_P (debugStream, PSTR("SMTP: %s"), buff); /* SMTP messages are allways 3 digits */ if (strlen(buff) < 4 || !isdigit(buff[0]) || !isdigit(buff[1]) || !isdigit(buff[2]) || buff[3] != ' ') { if (debugEnabled) { buff[4] = 0; fprintf_P(debugStream, PSTR("Illegal return code: '%s'\r\n"), strlen(buff)); } return -1; } n = (buff[0]-'0')*100 + (buff[1]-'0')*10 + (buff[2]-'0'); return n; } /* * \todo * Make it possible to write email addresses in the format * 'name
'. * Encode message body - hande specail case with sing dots. * React on 8-bit subjects. * Maybe add support for 7-bit mails with mime-encoding */ static int SMTPTransport (FILE *stream, char *buf, int size, const char *from, const char *to, const char *subject, const char *msg) { /* Wait for '220 servername ESMTP */ if ( SMTPWaitMessage (stream, buf, size) != 220 ) return SMTP_ERR_GREETING; /* Send greeting 'HELO [ip.addr.]' */ fprintf_P (stream, PSTR("HELO [%s]\r\n"), inet_ntoa(confnet.cdn_ip_addr)); fflush (stream); /* Wait for '250 servername' */ if ( SMTPWaitMessage (stream, buf, size) != 250 ) return SMTP_ERR_HELO; /* Send mail request: 'MAIL FROM:' */ fprintf_P (stream, PSTR("MAIL FROM:<%s>\r\n"), from); fflush (stream); /* Wait for '250 ok' */ if ( SMTPWaitMessage (stream, buf, size) != 250 ) return SMTP_ERR_MAILFROM; /* Specify recipients: 'RCPT TO:' */ fprintf_P(stream, PSTR("RCPT TO:<%s>\r\n"), to); fflush (stream); /* Wait for '250 ok' */ if ( SMTPWaitMessage (stream, buf, size) != 250 ) return SMTP_ERR_RCPTTO; /* Send data request: 'DATA' */ fputs_P (PSTR("DATA\r\n"), stream); fflush (stream); /* Wait for '354 go ahead' */ if ( SMTPWaitMessage (stream, buf, size) != 354 ) return SMTP_ERR_DATA; /* Send the encoded message */ fprintf_P (stream, PSTR("From: %s\r\n"), from); fprintf_P (stream, PSTR("To: %s\r\n"), to); fputs_P (PSTR("Content-Type: text/plain; charset=ISO-8859-1\r\n" "Content-Transfer-Encoding: 8BIT\r\n" "MIME-Version: 1.0\r\n"), stream); fprintf_P (stream, PSTR("User-Agent: ECBlite based on Nut/OS %s\r\n"), NutVersionString()); fprintf_P (stream, PSTR("Subject: %s\r\n\r\n"), subject); /* Fix encoding here!!! */ fputs (msg, stream); fputs_P (PSTR("\r\n.\r\n"), stream); fflush (stream); /* Wait for '250 ok' */ if ( SMTPWaitMessage (stream, buf, size) != 250 ) return SMTP_ERR_BODY; /* Exit session */ fputs_P (PSTR("QUIT\r\n"), stream); fflush (stream); // Wait for '221 ok' if ( SMTPWaitMessage (stream, buf, size) != 221 ) return SMTP_ERR_EXIT; return 0; } void SMTPSetDebugStream (FILE *stream) { debugStream = stream; debugEnabled = 1; } void SMTPDisableDebugStream (void) { debugStream = NULL; debugEnabled = 0; } int SMTPSendMail (u_long host, int port, const char *from, const char *to, const char *subject, const char *msg) { TCPSOCKET *sock; FILE *stream; int n; char *buf; const int size = 256; buf = (char *) NutHeapAlloc (size); if (!buf) return SMTP_ERR_OUTOFMEMORY; if ( (sock = NutTcpCreateSocket()) == 0 ) { NutHeapFree (buf); return SMTP_ERR_SOCKETCREATE; } if (!port) port = 25; if ( NutTcpConnect (sock, host, port) ) { NutHeapFree (buf); return SMTP_ERR_CONNECT; } if ( !(stream = _fdopen((int)sock, "r+b")) ) { NutTcpCloseSocket (sock); NutHeapFree (buf); return SMTP_ERR_STREAMCREATE; } /* Keep the error code - we'll have to do the rest anyway */ n = SMTPTransport (stream, buf, size, from, to, subject, msg); fclose(stream); NutTcpCloseSocket (sock); NutHeapFree (buf); return n; } -------------- next part -------------- /* SMTP module for ECBlite, based on Nus/OS */ #ifndef __MOD_SMTP_H #define __MOD_SMTP_H #include #define SMTP_ERR_SOCKETCREATE -1 #define SMTP_ERR_CONNECT -2 #define SMTP_ERR_STREAMCREATE -3 #define SMTP_ERR_OUTOFMEMORY -4 #define SMTP_ERR_GREETING -5 #define SMTP_ERR_HELO -6 #define SMTP_ERR_MAILFROM -7 #define SMTP_ERR_RCPTTO -8 #define SMTP_ERR_DATA -9 #define SMTP_ERR_BODY -10 #define SMTP_ERR_EXIT -11 extern int SMTPSendMail (u_long host, int port, const char *from, const char *to, const char *subject, const char *msg); extern void SMTPSetDebugStream (FILE *stream); extern void SMTPDisableDebugStream (void); #endif From ma at stendahls.net Sat Sep 13 09:59:38 2003 From: ma at stendahls.net (Mikael Adolfsson) Date: Sat, 13 Sep 2003 09:59:38 +0200 (CEST) Subject: [En-Nut-Discussion] HTTP QueryString parser In-Reply-To: <6D71E1FB451D984081153EC11D7A3DDB17873B@mail.ikp.liu.se> Message-ID: Lars, I've found the bug. The NutHttpProcessQueryString allocated too little memory. At row 329 in httpd.c change from req->req_qptrs = (char **)NutHeapAllocClear(sizeof(char *)*req->req_numqptrs); to req->req_qptrs = (char **)NutHeapAllocClear(sizeof(char *)*req->req_numqptrs*2); (double the memory - ofcourse it needs space for a pointer to the param name and one for the value.) / Mikael On Fri, 12 Sep 2003, Lars Andersson wrote: > Mikael, > > I use the same compiler version as you. The query string is also less > than 256 chars. > > I tried to implement similar code to what I explained earlier into the > httpd example that comes with the NUT/OS distribution. At first it > seemed to work fine, but after a while I noticed that the system was > very unstable. It seems that the connection is never closed. > > Could there be some memory leak? > > /Lars A Andersson From laran at ikp.liu.se Mon Sep 15 10:09:10 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Mon, 15 Sep 2003 10:09:10 +0200 Subject: [En-Nut-Discussion] HTTP QueryString parser Message-ID: <6D71E1FB451D984081153EC11D7A3DDB91AA78@mail.ikp.liu.se> Mikael, I have now made the changes to the code and it seems to work fine now. Thank you very much for the contribution of your solution. I think this will make implementation easier in the future! If I notice other strange results from your code I'll get back to you :) By the way, can you please explain, in more detail, the usage of these functions. I looked in the header file but unfortunately that didn't explain it to me. char *NutHttpURLEncode (char *str); void NutHttpURLDecode (char *str); Regards, /Lars A. A. -----Original Message----- From: Mikael Adolfsson [mailto:ma at stendahls.net] Sent: den 13 september 2003 10:00 To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] HTTP QueryString parser Lars, I've found the bug. The NutHttpProcessQueryString allocated too little memory. At row 329 in httpd.c change from req->req_qptrs = (char **)NutHeapAllocClear(sizeof(char *)*req->req_numqptrs); to req->req_qptrs = (char **)NutHeapAllocClear(sizeof(char *)*req->req_numqptrs*2); (double the memory - ofcourse it needs space for a pointer to the param name and one for the value.) / Mikael On Fri, 12 Sep 2003, Lars Andersson wrote: > Mikael, > > I use the same compiler version as you. The query string is also less > than 256 chars. > > I tried to implement similar code to what I explained earlier into the > httpd example that comes with the NUT/OS distribution. At first it > seemed to work fine, but after a while I noticed that the system was > very unstable. It seems that the connection is never closed. > > Could there be some memory leak? > > /Lars A Andersson _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From laran at ikp.liu.se Mon Sep 15 10:46:41 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Mon, 15 Sep 2003 10:46:41 +0200 Subject: [En-Nut-Discussion] Changing password for "cgi-bin" catalog in httpd example Message-ID: <6D71E1FB451D984081153EC11D7A3DDB91AA79@mail.ikp.liu.se> Hi, If I am not mistaking this issue has been brought up before, but I can't find the messages. Anyhow, I am trying to change the user and password for the "cgi-bin" directory in the httpd example. when I change the input parameters to the NutRegisterAuth function I can't get access to the directory. Is there something else that needs to be changed to be able to get this to work? This is what I changed it to: NutRegisterAuth("cgi-bin", "boot:boot"); Regards, /Lars A. A. From ethernut at ma.stendahls.net Mon Sep 15 12:49:17 2003 From: ethernut at ma.stendahls.net (Mikael Adolfsson) Date: Mon, 15 Sep 2003 12:49:17 +0200 (CEST) Subject: [En-Nut-Discussion] HTTP QueryString parser In-Reply-To: <6D71E1FB451D984081153EC11D7A3DDB91AA78@mail.ikp.liu.se> Message-ID: Hi, There is a short doxygen-style description of these functions in httpd.c. In short, they convert a parameter name or value to conform with rfc1738 (see section 2.2). Typically you never have to call NutHttpURLDecode, since it's done internally by the parser. The URLEncode is useful if you for example want to do a link with parameters from your cgi script. Here's an example: char *v = "some strange text &%/+"; /* Typically an unknown string */ char *s = NutHttpURLEncode (v); fprintf_P (stream, PSTR("link"), s); NutHeapFree (s); This will generate a link like this: link Note: char *NutHttpURLEncode(char *s) returns a new allocated string, that must be free'd by the user. void NutHttpURLDecode(char *s) overwrites s (since the decoded string is allways shorter or equal the length of s) / Mikael On Mon, 15 Sep 2003, Lars Andersson wrote: > Mikael, > > I have now made the changes to the code and it seems to work fine now. > Thank you very much for the contribution of your solution. I think this > will make implementation easier in the future! > > By the way, can you please explain, in more detail, the usage of these > functions. I looked in the header file but unfortunately that didn't > explain it to me. > > char *NutHttpURLEncode (char *str); > void NutHttpURLDecode (char *str); From m.kresse at cut5-systemhaus.de Mon Sep 15 14:23:15 2003 From: m.kresse at cut5-systemhaus.de (Martin Kresse) Date: Mon, 15 Sep 2003 14:23:15 +0200 Subject: [En-Nut-Discussion] Mapped memory extension Message-ID: <3F65AF33.80001@cut5-systemhaus.de> Hi, I am pretty much a newbie, not only regarding ethernut but also hardware design in general. Nonetheless I'd like to expand the memory on my Ethernut (revision 1.3 f), so I can do some buffering for playing internet radio. With my limited knowledge, I designed the attached scheme, and I'd be glad, if some experienced person could have a look at it and tell me if this is going to work like I hope it should. The scheme does pretty much what was already suggested by people in this forum: a 16kByte address window controlled by a bank select register. I tried to make it simple, and since I don't know how to move the RTL controller from its base address 0x8300 away, I chose the following memory layout (opposing to what the guide "Memory Considerations" recommends): 0x0000 - 0x7FFF: internal memory etc. 0x8000 - 0xB7FF: memory mapped I/O (e.g. Ethernet controller), segmented in 8 x 2kb regions 0xB800 - 0xBFFF: bank select register 0xC000 - 0xFFFF: bank switched memory window Are there any 512k RAM chips in standard DIL package (easier to solder) ? I'd appreciate any comments - thanks in advance. Sincerely, Martin Kresse -------------- next part -------------- A non-text attachment was scrubbed... Name: mem3.pdf Type: application/pdf Size: 78423 bytes Desc: not available URL: From ethernut at ma.stendahls.net Mon Sep 15 23:41:46 2003 From: ethernut at ma.stendahls.net (Mikael Adolfsson) Date: Mon, 15 Sep 2003 23:41:46 +0200 (CEST) Subject: [En-Nut-Discussion] >64kB code on mega103? Message-ID: Hi, Maybe this isn't the right forum for this question, but does anyone know how (to configure gcc?) to build code larger than 64kB that will work on the mega103 (or mega128)? My software is growing larger, and it doesn't fit in 64k any longer. My static content (prog_char) is quite small and would fit in the lower 64k. Is it possible to let gcc put all that content in the lower 64k, and only code in the upper 64k, so I don't need to mess with the elpm/rampz- instructions? / Mikael From damian at commtech.com.au Tue Sep 16 02:24:29 2003 From: damian at commtech.com.au (Damian Slee) Date: Tue, 16 Sep 2003 08:24:29 +0800 Subject: [En-Nut-Discussion] >64kB code on mega103? Message-ID: gcc should do that anyway? it appears all our PROGMEM strings are linked/allocated first, then program code after that. -----Original Message----- From: Mikael Adolfsson [mailto:ethernut at ma.stendahls.net] Sent: Tuesday, 16 September 2003 5:42 AM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] >64kB code on mega103? Hi, Maybe this isn't the right forum for this question, but does anyone know how (to configure gcc?) to build code larger than 64kB that will work on the mega103 (or mega128)? My software is growing larger, and it doesn't fit in 64k any longer. My static content (prog_char) is quite small and would fit in the lower 64k. Is it possible to let gcc put all that content in the lower 64k, and only code in the upper 64k, so I don't need to mess with the elpm/rampz- instructions? / Mikael _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From damian at commtech.com.au Tue Sep 16 09:39:18 2003 From: damian at commtech.com.au (Damian Slee) Date: Tue, 16 Sep 2003 15:39:18 +0800 Subject: [En-Nut-Discussion] anyone had probs with setting SO_RCVTIMEO causing lockups? Message-ID: u_long opt; // set receive timeout opt = 500; NutTcpSetSockOpt(sock, SO_RCVTIMEO, &opt, sizeof(opt)); for(;;) { rx = NutTcpReceive(sock, rxBuf, 64); seems to lock in NutTcpReceive() forever. other threads no longer function. Removing NutTcpSetSockOpt() fixes it, but data required for NutTcpReceive() to return. if (rx == -1) // socket error? break; ... } From johnny_k76 at yahoo.com Tue Sep 16 10:29:03 2003 From: johnny_k76 at yahoo.com (=?iso-8859-1?q?Johnny=20Karlsson?=) Date: Tue, 16 Sep 2003 10:29:03 +0200 (CEST) Subject: [En-Nut-Discussion] about debugging Message-ID: <20030916082903.15339.qmail@web14909.mail.yahoo.com> Hi, i'm looking at buying an ethernut board for my masters thesis. My question is this, how is debbugging done? I used to program a 68HC11 in school and there we had a hardware emulator to do all the debugging. Does Ethernut have support for on-chip debugging? Best Wishes Johnny Karlsson H?strusk och gr? moln - k?p en resa till solen p? Yahoo! Resor p? adressen http://se.docs.yahoo.com/travel/index.html From harald.kipp at egnite.de Tue Sep 16 10:53:00 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 10:53:00 +0200 Subject: [En-Nut-Discussion] Changing password for "cgi-bin" catalog in httpd example In-Reply-To: <6D71E1FB451D984081153EC11D7A3DDB91AA79@mail.ikp.liu.se> Message-ID: <5.1.1.6.0.20030916105224.01cfd268@egnite.de> > >This is what I changed it to: >NutRegisterAuth("cgi-bin", "boot:boot"); Works fine here. May be a problem with your browser? Harald From harald.kipp at egnite.de Tue Sep 16 11:06:13 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 11:06:13 +0200 Subject: [En-Nut-Discussion] Mapped memory extension In-Reply-To: <3F65AF33.80001@cut5-systemhaus.de> Message-ID: <5.1.1.6.0.20030916105423.01d2fd58@egnite.de> Martin, >0x8000 - 0xB7FF: memory mapped I/O (e.g. Ethernet controller), >segmented in 8 x 2kb regions The advantage of moving memory mapped I/O to upper addresses is, that you can specify additional wait states for this region. >Are there any 512k RAM chips in standard DIL package (easier to solder) ? There are. In Germany you may check Reichelt. But manually soldering SOIC is really easy, even for newbies. Important: Use a lot of flux. Harald From harald.kipp at egnite.de Tue Sep 16 11:18:30 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 11:18:30 +0200 Subject: [En-Nut-Discussion] >64kB code on mega103? In-Reply-To: Message-ID: <5.1.1.6.0.20030916110825.01d28438@egnite.de> Damian, >gcc should do that anyway? >it appears all our PROGMEM strings are linked/allocated first, then >program code after that. Indeed at least GCC version 3.3 does that. It links the .progmem.data segment first. Harald From harald.kipp at egnite.de Tue Sep 16 11:34:42 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 11:34:42 +0200 Subject: [En-Nut-Discussion] about debugging In-Reply-To: <20030916082903.15339.qmail@web14909.mail.yahoo.com> Message-ID: <5.1.1.6.0.20030916111930.01dbc710@egnite.de> Johnny, for Ethernut 1.3 please check: http://www.ethernut.de/en/jtag/jtagconn.html The adapter shown came with our ATJTAGICE. However, the ATJTAGICE costs about 300 US$. Our board manufacturer is currently producing four prototypes of http://savannah.nongnu.org/projects/freeice But it may take months until all hardware and software parts are working flawlessly. Considerations for your shopping plans: Ethernut 2 (yes, we finally start shipping in about two weeks) provides a jumper to select between ISP/JTAG, so no adapter required. Some other advantages: - 512k RAM - 10/100 MBit Ethernet - RS485 Main disadvantages: - Draws about 400 mA - Regulator and Ethernet Controller getting more than warm - Slightly higher price Harald From harald.kipp at egnite.de Tue Sep 16 11:41:11 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 11:41:11 +0200 Subject: [En-Nut-Discussion] anyone had probs with setting SO_RCVTIMEO causing lockups? In-Reply-To: Message-ID: <5.1.1.6.0.20030916113524.01d776b8@egnite.de> Damian, We are using socket timeouts in most of our own applications. Because of a bug in timer handling, make sure to keep the timeout above 62 millisecs. This is also true for NutSleep(). 90% of lockups are caused by loops without NutThreadYield(). (Just in case: If you are calling input or NutSleep() functions in your loop, NutTreadYield() is not required.) Harald From harald.kipp at egnite.de Tue Sep 16 12:16:11 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 16 Sep 2003 12:16:11 +0200 Subject: [En-Nut-Discussion] WinAVR: Using uisp with Ethernut's STK500 dongle Message-ID: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> The uisp version, which comes with the latest WinAVR release WinAVR-20030913, works fine with the serial port dongle included in the Starter Kit. Two entries in UserConf.mk need to be changed: BURN=c:\WinAVR\bin\uisp.exe BURNFLAGS=-dprog=stk500 -dserial=/dev/ttyS0 -dpart=$(MCU) --erase --upload if=$(TARG) Note, that nutconf will override UserConf.mk. Harald From ralf at spettel.de Tue Sep 16 19:22:29 2003 From: ralf at spettel.de (Ralf Spettel) Date: Tue, 16 Sep 2003 19:22:29 +0200 Subject: [En-Nut-Discussion] Close TCP connection if cable disconnected Message-ID: <5.1.1.6.2.20030916191725.00a71be8@pop.1und1.com> Hi, what's the best way to close the TCP connection if the thread waits with NutTcpReceive() for data and the network-cable was removed or the (any) router failed. If I pluging in the cable again, no TCP connection is possible. Thx, Ralf From jjj at iki.fi Tue Sep 16 22:17:32 2003 From: jjj at iki.fi (Janne Jarvinen) Date: Tue, 16 Sep 2003 23:17:32 +0300 Subject: [En-Nut-Discussion] Nut/OS in STK300 In-Reply-To: <3F65AF33.80001@cut5-systemhaus.de> Message-ID: <000c01c37c8f$927a6c10$6901a8c0@thinkpad> Hi Any hints what do I need to change in order to get UART to work in STK300 meaning in ATMega103 generally ? Is it necessary to enable this flag for example? (STK300 is 4MHz) DEFS = -DNUT_CPU_FREQ=3686400 I saw some comment in sources about this being for 1ms resolution enable, but what if it is not defined ? Does it make timers&rtc still to work but with worse resolution ? Currently app/threads works nicely with 3 different threads blinking leds with specific speed defined differetnly for each threads. However, LCD and UART shows random rubbish only ... For LCD I have redefined different port setup without any help. For UART(chip hw uart) I couldn?t find really anything to change. I set nutconf to stk200 and atmega103. Whatever stk200 then defines, I have no idea. BR, Janne From spm at iteso.mx Tue Sep 16 22:26:10 2003 From: spm at iteso.mx (Sergio Palacios Macias) Date: Tue, 16 Sep 2003 15:26:10 -0500 Subject: [En-Nut-Discussion] Not using Ethernut but using the RTL8019as, can you help me out? Message-ID: <1063743970.3f6771e2e6ddd@iteso.mx> Hello, If i'm developing an embedded project that is not directly related with the Ethernut but it is with the RTL8019as, could you help me out? Thanks pd. The project cosists of an RTL8019as ISA-card interfaced to an 8051 microcontroller. --- From jjj at iki.fi Tue Sep 16 22:34:42 2003 From: jjj at iki.fi (Janne Jarvinen) Date: Tue, 16 Sep 2003 23:34:42 +0300 Subject: [En-Nut-Discussion] Not using Ethernut but using the RTL8019as, can you help me out? In-Reply-To: <1063743970.3f6771e2e6ddd@iteso.mx> Message-ID: <000d01c37c91$f8e894c0$6901a8c0@thinkpad> What is the thing you are asking or needing really? There is spec for RTL8019 available if you just get it by Google and there is Ethernut drivers as c source codes to look for examples ... Janne > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of > Sergio Palacios Macias > Sent: 16. syyskuuta 2003 23:26 > To: en-nut-discussion at egnite.de > Subject: [En-Nut-Discussion] Not using Ethernut but using the > RTL8019as, can you help me out? > > > > Hello, If i'm developing an embedded project that is not > directly related with > the Ethernut but it is with the RTL8019as, could you help me out? > > Thanks > > pd. The project cosists of an RTL8019as ISA-card interfaced > to an 8051 > microcontroller. > > --- > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-> discussion > From Douglas.Pearless at pearless.co.nz Wed Sep 17 01:46:00 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Wed, 17 Sep 2003 11:46:00 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: Message-ID: Hi People, I'd appreciate some comments. I have an Oxford quad UART mapped into 0xFF00 to 0xFFFF I cannot seem to be able to read or write to it. I have checked the hardware carefully (famous last words...) and neither the RD\ nor WR\ lines seem to change, or at least may be they are changing too fast for my logic probe. Does this code cover what it needs to in order to be able to access the Oxford chip (note that I am using UART0 on the Ethernut for comms and debug!) Cheers Douglas #define UARTQUAD_BASE 0xFF00 #define UARTQUAD_DLL 0x008 #define uartquad_read(reg) *(base + (reg)) #define uartquad_write(reg, data) *(base + (reg)) = data #include #include #include #include #include static char *banner = "\nNut/OXFORD UART Sample\n"; static char inbuf[128]; int main(void) { int got; int i,j,k; char *cp; u_long baud = 115200; FILE *uart; float dval = 0.0; u_long TWI_speed; volatile u_char *base = (u_char *) UARTQUAD_BASE; /* * Enable external data and address * bus. */ outp(BV(SRE) | BV(SRW), MCUCR); NutRegisterDevice(&devUart0, 0, 0); uart = fopen("uart0", "r+"); _ioctl(_fileno(uart), UART_SETSPEED, &baud); NutSleep(200); _write(_fileno(uart), banner, strlen(banner)); _write(_fileno(uart), 0, 0); for(i = 0;; i++) { fputs("\nPress Enter", uart); fflush(uart); fgets(inbuf, sizeof(inbuf), uart); j = uartquad_read(UARTQUAD_DLL); fprintf(uart, "\ni = %x : READ UARTQUAD_DLL = %x\n", i,j); fflush(uart); /* set it to 0x20 */ j = 0x20; uartquad_write(UARTQUAD_DLL,j); /* did it work ?*/ k = uartquad_read(UARTQUAD_DLL); fprintf(uart, "\n UARTQUAD_DLL = %x\n", k); fflush(uart); } } --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From damian at commtech.com.au Wed Sep 17 05:02:11 2003 From: damian at commtech.com.au (Damian Slee) Date: Wed, 17 Sep 2003 11:02:11 +0800 Subject: [En-Nut-Discussion] media sense/cable detect Message-ID: Hi all, has anyone looked at media sense to detect if the cable is unplugged, like Windows2000/XP? When the cable is unplugged all TCP connections can be flaged as closed. Does anyone know if the "Carrier sense lost" bit in the RTL8019 status register indicates the state of the link LED? Commtech Wireless www.commtech.com.au (Australia) www.commtechwireless.com (USA) PO Box 1037 OPDC WA 6916 Ph:+61 8 9242 5651 Fax:+61 8 9242 5652 Confidentiality/Limited Liability Statement This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message, you must not disseminate, copy or take any action in reliance on it. If you have received this message in error, please notify Commtech Wireless Pty Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Commtech Wireless. Additionally if prices are quoted in this document then you may consider this document to be an official quotation and the prices quoted are valid for a period of fourteen days from the date of this document. From damian at commtech.com.au Wed Sep 17 07:29:50 2003 From: damian at commtech.com.au (Damian Slee) Date: Wed, 17 Sep 2003 13:29:50 +0800 Subject: [En-Nut-Discussion] anyone had probs with setting SO_RCVTIMEO causing lockups? Message-ID: Turned out to be a really wierd problem with a call to memcpy_P() in my code. Despite using it else where in the same thread, this instance caused strange problems. Replaced it with two _LPM() calls, and I am not having the problem now? Using GCC 3.3. -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Tuesday, 16 September 2003 5:41 PM To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] anyone had probs with setting SO_RCVTIMEO causing lockups? Damian, We are using socket timeouts in most of our own applications. Because of a bug in timer handling, make sure to keep the timeout above 62 millisecs. This is also true for NutSleep(). 90% of lockups are caused by loops without NutThreadYield(). (Just in case: If you are calling input or NutSleep() functions in your loop, NutTreadYield() is not required.) Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From harald.kipp at egnite.de Wed Sep 17 09:33:00 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 17 Sep 2003 09:33:00 +0200 Subject: [En-Nut-Discussion] Close TCP connection if cable disconnected In-Reply-To: <5.1.1.6.2.20030916191725.00a71be8@pop.1und1.com> Message-ID: <5.1.1.6.0.20030917092931.023ebbf0@egnite.de> Hi Ralf, Not just the best but the only way is to use a timeout. Are you sure, that unplugging and replugging again causes the problem? It may be because your app allows one connection only. Harald From harald.kipp at egnite.de Wed Sep 17 09:40:45 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 17 Sep 2003 09:40:45 +0200 Subject: [En-Nut-Discussion] Nut/OS in STK300 In-Reply-To: <000c01c37c8f$927a6c10$6901a8c0@thinkpad> References: <3F65AF33.80001@cut5-systemhaus.de> Message-ID: <5.1.1.6.0.20030917093413.024aa160@egnite.de> Hi Janne, >Any hints what do I need to change in order to get UART to work in >STK300 meaning in ATMega103 generally ? > >Is it necessary to enable this flag for example? (STK300 is 4MHz) >DEFS = -DNUT_CPU_FREQ=3686400 This definition is only required if the 32kHz crystal is not mounted. >I saw some comment in sources about this being for 1ms resolution >enable, but what if it is not defined ? Does it make timers&rtc still to >work but with worse resolution ? If NUT_CPU_FREQ is not defined, the resolution is 62.5 ms, using the 32 kHz crystal. Taking this as a reference, Ethernut is able to determine its main crystal frequency. >Currently app/threads works nicely with 3 different threads blinking >leds with specific speed defined differetnly for each threads. However, >LCD and UART shows random rubbish only ... For LCD it may be a hardware timing problem. For the UART, check the baudrate table in the ATmega datasheet, specially the deviation. >I set nutconf to stk200 and atmega103. Whatever stk200 then defines, I >have no idea. The STK200 defines the type of programming adapter you're using. This definition enables to simply call make burn on the command line. Harald From harald.kipp at egnite.de Wed Sep 17 09:48:17 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 17 Sep 2003 09:48:17 +0200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: References: Message-ID: <5.1.1.6.0.20030917094134.024ac810@egnite.de> Hi Douglas, >Does this code cover what it needs to in order to be able to access the >Oxford chip (note that I am using UART0 on the Ethernut for comms and >debug!) Not at all. You need to write a new device driver for the QUART, the registers are definitely different from the one used by uartavr. Harald From harald.kipp at egnite.de Wed Sep 17 09:56:53 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 17 Sep 2003 09:56:53 +0200 Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: Message-ID: <5.1.1.6.0.20030917094830.024a4438@egnite.de> Hi Damian, >has anyone looked at media sense to detect if the cable is unplugged, like >Windows2000/XP? > >When the cable is unplugged all TCP connections can be flaged as closed. Does Windows do this? TCP rules define, that a connection should _not_ be closed on lower level problems. The application may close the connection on transmit failures. If one node is receiving and the remote is switched off, the receiver will never detect the loss. It may use a socket timeout (supported by Nut/Net) or set the KEEPALIVE option (not supported by Nut/Net). Beside that, it would still make a lot of sense to detect a link loss, but I never tried. Anyone else? Harald From Douglas.Pearless at pearless.co.nz Wed Sep 17 11:43:07 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Wed, 17 Sep 2003 21:43:07 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: <5.1.1.6.0.20030917094134.024ac810@egnite.de> Message-ID: Hi Harald, I have started to do that too, but it is a bit of a learning curve! I am just trying to prove that I can access the device at this point, but cannot seem to. My question is around, if the hardware is OK, then is the software OK as a test to prove I can see the hardware. Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Harald Kipp Sent: Wednesday, 17 September 2003 7:48 p.m. To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut Hi Douglas, >Does this code cover what it needs to in order to be able to access the >Oxford chip (note that I am using UART0 on the Ethernut for comms and >debug!) Not at all. You need to write a new device driver for the QUART, the registers are definitely different from the one used by uartavr. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From harald.kipp at egnite.de Wed Sep 17 12:17:32 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 17 Sep 2003 12:17:32 +0200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: References: <5.1.1.6.0.20030917094134.024ac810@egnite.de> Message-ID: <5.1.1.6.0.20030917121211.01a0f188@egnite.de> Douglas, I'd suggest to write a simple program first (no Nut/OS!) and use outb and inb statements to access the hardware. 1. Initialize QUART registers 2. Try to output one character 3. Test interrupts After this is working fine, you should be ready to modify uartavr.c. Btw. I recommend to use a different file. Do not intend to make uartavr.c working with both devices, on-chip UART and external QUAD. Harald From Douglas.Pearless at pearless.co.nz Wed Sep 17 12:36:46 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Wed, 17 Sep 2003 22:36:46 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: <5.1.1.6.0.20030917121211.01a0f188@egnite.de> Message-ID: Hi Harald, Thanks for the feedback. I am creating a new file, rather than modifing uartavr.c. cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Harald Kipp Sent: Wednesday, 17 September 2003 10:18 p.m. To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut Douglas, I'd suggest to write a simple program first (no Nut/OS!) and use outb and inb statements to access the hardware. 1. Initialize QUART registers 2. Try to output one character 3. Test interrupts After this is working fine, you should be ready to modify uartavr.c. Btw. I recommend to use a different file. Do not intend to make uartavr.c working with both devices, on-chip UART and external QUAD. Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From Brett.Abbott at digital-telemetry.com Wed Sep 17 12:54:59 2003 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Wed, 17 Sep 2003 22:54:59 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford References: <20030917100001.9254.81892.Mailman@p15095813.pureserver.info> Message-ID: <3F683D83.7060806@digital-telemetry.com> > > >Doug > The uart is memory mapped. Try a couple of things... Try using NutCritical around the functions. You may find that the memory is getting zapped by other calculations.... Going NutCritical will stop interupts and other stuff (NutEnterCritical()) NutExitCritical() Also, try using direct memory reads and writes: be explicit with addresses rather than formulas. perhaps achieve this with inline assembler. Have a look at the ethernet nic drivers as an example. Cheers Brett From m.kresse at cut5-systemhaus.de Wed Sep 17 13:16:01 2003 From: m.kresse at cut5-systemhaus.de (Martin Kresse) Date: Wed, 17 Sep 2003 13:16:01 +0200 Subject: [En-Nut-Discussion] Mapped memory extension Message-ID: <3F684271.1030909@cut5-systemhaus.de> >>0x8000 - 0xB7FF: memory mapped I/O (e.g. Ethernet controller), >>segmented in 8 x 2kb regions >The advantage of moving memory mapped I/O to upper addresses >is, that you can specify additional wait states for this >region. I feared that. Does the IDE extension using the XC9572 need any waitstates? Is there any way to move the base address of the NIC controller of an existing Ethernut 1.3 into the 0xC000-0xFFFF range? Martin From jjj at iki.fi Wed Sep 17 18:50:54 2003 From: jjj at iki.fi (Janne Jarvinen) Date: Wed, 17 Sep 2003 19:50:54 +0300 Subject: [En-Nut-Discussion] Nut/OS in STK300 In-Reply-To: <5.1.1.6.0.20030917093413.024aa160@egnite.de> Message-ID: <002e01c37d3b$df090a80$6901a8c0@thinkpad> Thanks Harald You were absolutely right about UART diveder. I replaced UBBR line by my own manual setup and it worked just fine. Now I can finally debug scheduling of the example program :) What about LCD then, you mentioned hw timing.. I have HD44780 based display connected straight to the PORTA pins, no extra components except contrast pot. For whatkind of connection lcd-driver is designed ? I have used Peter Fleury?s (http://www.mysunrise.ch/users/pfleury/avr-lcd44780.html) way to access LCD but I would like to use Nut?s own drivers of course. If it is aimed to connect straight to the pins aswell then only thing I could imagine is timing difference caused by een 4MHz / 14MHz cpu clock difference ...? Janne > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of Harald Kipp > Sent: 17. syyskuuta 2003 10:41 > To: en-nut-discussion at egnite.de > Subject: Re: [En-Nut-Discussion] Nut/OS in STK300 > > > Hi Janne, > > > >Any hints what do I need to change in order to get UART to work in > >STK300 meaning in ATMega103 generally ? > > > >Is it necessary to enable this flag for example? (STK300 is > 4MHz) DEFS > >= -DNUT_CPU_FREQ=3686400 > > This definition is only required if the 32kHz crystal is not mounted. > > >I saw some comment in sources about this being for 1ms resolution > >enable, but what if it is not defined ? Does it make > timers&rtc still > >to work but with worse resolution ? > > If NUT_CPU_FREQ is not defined, the resolution is 62.5 ms, > using the 32 kHz crystal. Taking this as a reference, > Ethernut is able to determine its main crystal frequency. > > > >Currently app/threads works nicely with 3 different threads blinking > >leds with specific speed defined differetnly for each > threads. However, > >LCD and UART shows random rubbish only ... > > For LCD it may be a hardware timing problem. For the > UART, check the baudrate table in the ATmega datasheet, > specially the deviation. > > > >I set nutconf to stk200 and atmega103. Whatever stk200 then > defines, I > >have no idea. > > The STK200 defines the type of programming adapter you're > using. This definition enables to simply call > > make burn > > on the command line. > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-> discussion > From ceba at vabo.cz Wed Sep 17 20:05:08 2003 From: ceba at vabo.cz (Pavel Celeda) Date: 17 Sep 2003 20:05:08 +0200 Subject: [En-Nut-Discussion] WinAVR: Using uisp with Ethernut's STK500 dongle In-Reply-To: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> References: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> Message-ID: <1063821908.2278.47.camel@hw.vabo.cz> > The uisp version, which comes with the latest WinAVR release > WinAVR-20030913, works fine with the serial port dongle > included in the Starter Kit. Two entries in UserConf.mk need > to be changed: > > BURN=c:\WinAVR\bin\uisp.exe > BURNFLAGS=-dprog=stk500 -dserial=/dev/ttyS0 -dpart=$(MCU) --erase --upload > if=$(TARG) > > Note, that nutconf will override UserConf.mk. I'm using Ethernut's STK500 dongle firmware 1.14, uisp from WinAVR-20030913 and can't program ATmega128 correctly. If I use Ethernut's STK500 dongle with AVR studio everything works OK. I have replaced the Ethernut's STK500 dongle with STK500 Protocol AVR Bootloader - http://avr1.org/stk500boot/stk500boot.html and UISP works fine. Which version of dongle firmware are you using ? Pavel From tex at off.org Wed Sep 17 20:25:39 2003 From: tex at off.org (Austin Schutz) Date: Wed, 17 Sep 2003 11:25:39 -0700 Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: <5.1.1.6.0.20030917094830.024a4438@egnite.de>; from harald.kipp@egnite.de on Wed, Sep 17, 2003 at 09:56:53AM +0200 References: <5.1.1.6.0.20030917094830.024a4438@egnite.de> Message-ID: <20030917112539.L2732@gblx.net> On Wed, Sep 17, 2003 at 09:56:53AM +0200, Harald Kipp wrote: > Hi Damian, > > > >has anyone looked at media sense to detect if the cable is unplugged, like > >Windows2000/XP? > > > >When the cable is unplugged all TCP connections can be flaged as closed. > > Does Windows do this? > > TCP rules define, that a connection should _not_ be closed on lower > level problems. The application may close the connection on > transmit failures. > > If one node is receiving and the remote is switched off, the > receiver will never detect the loss. It may use a socket timeout > (supported by Nut/Net) or set the KEEPALIVE option (not supported > by Nut/Net). > > Beside that, it would still make a lot of sense to detect a link > loss, but I never tried. Anyone else? > If the link is down it should flag packets going to that interface with an icmp network unreachable, or something like that. The received icmp should be interpreted by the device as being a good reason to close the connection. Or something like that. I'm not _that_ familiar with the exact method. Austin From ralph.mason at telogis.com Wed Sep 17 20:57:47 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Thu, 18 Sep 2003 06:57:47 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: Message-ID: To save yourself some work and codespace I suggest you use the 'virtualised' AVR uart if possible from nut os. I wrote a 16550 driver in a few hours that way. Here is my declaration, you can see how much of the avr driver I used static UARTDCB dcb_uarta; NUTDEVICE devUartA = { 0, /*!< Pointer to next device. */ {'u', 'a', 'r', 't', 'a', 0, 0, 0, 0}, /*!< Unique device name. */ IFTYP_STREAM, /*!< Type of device. */ (u_char*)0xf900, /*!< Base address. */ 4, /*!< First interrupt number. */ 0, /*!< Interface control block. */ &dcb_uarta, /*!< Driver control block. */ UartExtInit, /*!< Driver initialization routine. */ UartExtIOCtl, /*!< Driver specific control function. */ UartAvrRead, UartAvrWrite, UartAvrWrite_P, UartAvrOpen, UartAvrClose }; THere are only 2 of my own functions there. In the init I setup the stream (so that the memory for it can be allocated from the heap) and put my own stream handler functions in. int UartExtInit(NUTDEVICE *dev) { IFSTREAM *ifs; //Already done if ( dev->dev_icb ) return 0; ifs = NutHeapAllocClear(sizeof(IFSTREAM)); dev->dev_icb = ifs; ifs->if_input = UartAvrInput; ifs->if_output = UartExtOutput; ifs->if_flush = UartAvrFlush; /* * Initialize driver control block. */ memset(dev->dev_dcb, 0, sizeof(UARTDCB)); Init16550((volatile u_char*)dev->dev_base,38400); So you can see, I only provided 3 functions to the driver(UartExtOutput,UartExtInit,UartExtInit) and my own interupt handler. Hope this is of some help Regards Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Pearless > Sent: Wednesday, 17 September 2003 10:37 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford > Quad UART) device to an EtherNut > > > Hi Harald, > > Thanks for the feedback. > > I am creating a new file, rather than modifing uartavr.c. > > cheers Douglas > > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Harald Kipp > Sent: Wednesday, 17 September 2003 10:18 p.m. > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford > Quad UART) device to an EtherNut > > > Douglas, > > I'd suggest to write a simple program first (no Nut/OS!) > and use outb and inb statements to access the hardware. > > 1. Initialize QUART registers > 2. Try to output one character > 3. Test interrupts > > After this is working fine, you should be ready to modify > uartavr.c. Btw. I recommend to use a different file. Do not > intend to make uartavr.c working with both devices, on-chip > UART and external QUAD. > > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 From troth at openavr.org Wed Sep 17 21:51:18 2003 From: troth at openavr.org (Theodore A. Roth) Date: Wed, 17 Sep 2003 12:51:18 -0700 (PDT) Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: <20030917112539.L2732@gblx.net> References: <5.1.1.6.0.20030917094830.024a4438@egnite.de> <20030917112539.L2732@gblx.net> Message-ID: On Wed, 17 Sep 2003, Austin Schutz wrote: > On Wed, Sep 17, 2003 at 09:56:53AM +0200, Harald Kipp wrote: > > Hi Damian, > > > > > > >has anyone looked at media sense to detect if the cable is unplugged, like > > >Windows2000/XP? > > > > > >When the cable is unplugged all TCP connections can be flaged as closed. > > > > Does Windows do this? > > > > TCP rules define, that a connection should _not_ be closed on lower > > level problems. The application may close the connection on > > transmit failures. > > > > If one node is receiving and the remote is switched off, the > > receiver will never detect the loss. It may use a socket timeout > > (supported by Nut/Net) or set the KEEPALIVE option (not supported > > by Nut/Net). > > > > Beside that, it would still make a lot of sense to detect a link > > loss, but I never tried. Anyone else? > > > > If the link is down it should flag packets going to that interface > with an icmp network unreachable, or something like that. The received icmp > should be interpreted by the device as being a good reason to close the > connection. Or something like that. I'm not _that_ familiar with the > exact method. There's an excellant discussion of this in the Introduction section of chapter 23 ("TCP Keepalive Timer") in Stevens "TCP Illustrated Vol 1." Is it possible to tell the difference between the cable being disconnected and the hub/switch/router losing power temporarily? Ted Roth From Douglas.Pearless at pearless.co.nz Wed Sep 17 22:17:44 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Thu, 18 Sep 2003 08:17:44 +1200 Subject: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut In-Reply-To: Message-ID: Hi Ralph, Thanks!!!! Your code has cleared up some of the workings of the UART device drivers for me. Would you consider sharing the UartExtOutput and UartExtInit code too? A question for all those on the list, has any one written device drivers where they share an interrupt? I am expecting for my interrupt handler for the 4 uarts to first check to see which uart has generated the interrupt and then perform the appropriate task. Might prove to be a bit tricky? Any comments? Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Ralph Mason Sent: Thursday, 18 September 2003 6:58 a.m. To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford Quad UART) device to an EtherNut To save yourself some work and codespace I suggest you use the 'virtualised' AVR uart if possible from nut os. I wrote a 16550 driver in a few hours that way. Here is my declaration, you can see how much of the avr driver I used static UARTDCB dcb_uarta; NUTDEVICE devUartA = { 0, /*!< Pointer to next device. */ {'u', 'a', 'r', 't', 'a', 0, 0, 0, 0}, /*!< Unique device name. */ IFTYP_STREAM, /*!< Type of device. */ (u_char*)0xf900, /*!< Base address. */ 4, /*!< First interrupt number. */ 0, /*!< Interface control block. */ &dcb_uarta, /*!< Driver control block. */ UartExtInit, /*!< Driver initialization routine. */ UartExtIOCtl, /*!< Driver specific control function. */ UartAvrRead, UartAvrWrite, UartAvrWrite_P, UartAvrOpen, UartAvrClose }; THere are only 2 of my own functions there. In the init I setup the stream (so that the memory for it can be allocated from the heap) and put my own stream handler functions in. int UartExtInit(NUTDEVICE *dev) { IFSTREAM *ifs; //Already done if ( dev->dev_icb ) return 0; ifs = NutHeapAllocClear(sizeof(IFSTREAM)); dev->dev_icb = ifs; ifs->if_input = UartAvrInput; ifs->if_output = UartExtOutput; ifs->if_flush = UartAvrFlush; /* * Initialize driver control block. */ memset(dev->dev_dcb, 0, sizeof(UARTDCB)); Init16550((volatile u_char*)dev->dev_base,38400); So you can see, I only provided 3 functions to the driver(UartExtOutput,UartExtInit,UartExtInit) and my own interupt handler. Hope this is of some help Regards Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Pearless > Sent: Wednesday, 17 September 2003 10:37 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford > Quad UART) device to an EtherNut > > > Hi Harald, > > Thanks for the feedback. > > I am creating a new file, rather than modifing uartavr.c. > > cheers Douglas > > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Harald Kipp > Sent: Wednesday, 17 September 2003 10:18 p.m. > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Interfacing a memory mapped (Oxford > Quad UART) device to an EtherNut > > > Douglas, > > I'd suggest to write a simple program first (no Nut/OS!) > and use outb and inb statements to access the hardware. > > 1. Initialize QUART registers > 2. Try to output one character > 3. Test interrupts > > After this is working fine, you should be ready to modify > uartavr.c. Btw. I recommend to use a different file. Do not > intend to make uartavr.c working with both devices, on-chip > UART and external QUAD. > > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From spm at iteso.mx Wed Sep 17 23:20:35 2003 From: spm at iteso.mx (Sergio Palacios Macias) Date: Wed, 17 Sep 2003 16:20:35 -0500 Subject: [En-Nut-Discussion] Not using Ethernut but using the RTL8019as, can you help me out? In-Reply-To: <000d01c37c91$f8e894c0$6901a8c0@thinkpad> References: <000d01c37c91$f8e894c0$6901a8c0@thinkpad> Message-ID: <1063833635.3f68d023d487e@iteso.mx> As I said, I'm developing a school project that consists to interface an 8051 with an rtl8019 isa-card. I've done al the wiring between both devices and I checked all the connections and they all seem to be right. For testing good communication between the nic and the uC I did a program that initializes the nic and then access the mac address from the card to store such address in to de microcontroller but finally I get no response from the card at all. I?ve checked several times every signal to and from the nic and they all look ok but nothing seems to happen, no data comes out from the isa-card. For developing this project I was based on the datasheets for the rtl8019 and also for the dp8390. I also have checked out many projects (embeddedethernet, the one that is at 8052 web page, Sx Stack, web51, the packet whacker, Ethernut of course, etc) and in theory my hardware and software should work but they don?t. Any tip? Sergio Quoting Janne Jarvinen : > What is the thing you are asking or needing really? There is spec for > RTL8019 available if you just get it by Google and there is Ethernut > drivers as c source codes to look for examples ... > > Janne > > > > > -----Original Message----- > > From: en-nut-discussion-admin at egnite.de > > [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of > > Sergio Palacios Macias > > Sent: 16. syyskuuta 2003 23:26 > > To: en-nut-discussion at egnite.de > > Subject: [En-Nut-Discussion] Not using Ethernut but using the > > RTL8019as, can you help me out? > > > > > > > > Hello, If i'm developing an embedded project that is not > > directly related with > > the Ethernut but it is with the RTL8019as, could you help me out? > > > > Thanks > > > > pd. The project cosists of an RTL8019as ISA-card interfaced > > to an 8051 > > microcontroller. > > > > --- > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo/en-nut-> discussion > > > > > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > --- From s354335 at student.uq.edu.au Thu Sep 18 00:30:45 2003 From: s354335 at student.uq.edu.au (Toby Smith) Date: Thu, 18 Sep 2003 08:30:45 +1000 (GMT+1000) Subject: [En-Nut-Discussion] i2c on ethernut Message-ID: I'm looking at interfacing my ethernut board to some external i2c devices. IU know the atmega128 has a built in TWI module, but my board has an atmega103. I need the ethernut to act as master in a single master i2c network. Perhaps this question is a little open ended, but does anyone have any tips or pointers on where to start with writing some code to get this happening? --Toby From ngbmoreau at yahoo.com.au Thu Sep 18 03:13:16 2003 From: ngbmoreau at yahoo.com.au (NGB) Date: Thu, 18 Sep 2003 11:13:16 +1000 Subject: [En-Nut-Discussion] New winavr avr-libc 0.99.90.20030829 Message-ID: <1063847596.3f6906ac743a8@tiger> Hi I have been testing the new winavr with avr-libc 0.99.90.20030829, there are a few problems building ethernut now: 1-XRAM end is defined in iom128.h that creates a conflict with nutinit.c, I'm not sure why XRAMEND would be defined in iom128.h as this should be application specific ! in the mean while I did this #include #ifdef XRAMEND #undef XRAMEND #endif #define XRAMEND ((volatile u_char *)0x7FFF) to get nutinit.c to compile, I can submit a patch if you want Harald 2- strtok_r is now in the libc (at last), problem is it's conflicting with Peter Scandrett version, I suggest we rename the Ethernut strtok_r to etehrnut_strtok_r to maintain some backward compatibility or we simply remove it and use the libc one ? BTW, the 2 versions havew different agruments Nic ------------------------------------------------- From peter.scandrett at transport.alstom.com Thu Sep 18 03:55:00 2003 From: peter.scandrett at transport.alstom.com (peter.scandrett at transport.alstom.com) Date: Thu, 18 Sep 2003 11:55:00 +1000 Subject: [En-Nut-Discussion] New winavr avr-libc 0.99.90.20030829 Message-ID: Hi all, On 18-Sep-03 Nic wrote > 2- strtok_r is now in the libc (at last), > problem is it's conflicting with Peter > Scandrett version, I suggest we rename > the Ethernut strtok_r to etehrnut_strtok_r > to maintain some backward compatibility or > we simply remove it and use the libc one ? > BTW, the 2 versions havew different agruments IMHO, I think we should remove my original version of STRTOK_R as it has a different function prototype to every other implementation. This has portability implications if one wants to take code to other platforms. In addition, my version supports STRSEP_R too, which is useful for parsing a string with consecutive separators which are significant (like a CSV file). My new version has a date of 10-Sep-03 at the top of the file. Peter Scandrett -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at commtech.com.au Thu Sep 18 05:39:25 2003 From: damian at commtech.com.au (Damian Slee) Date: Thu, 18 Sep 2003 11:39:25 +0800 Subject: [En-Nut-Discussion] gateway parameter addition to NutNetIfConfig() Message-ID: Hi, can I have the gateway param added to NutNetIfConfig() and used in NutDhcpIfConfig() so manual configuration can be used. please? ifconfig.c int NutNetIfConfig(CONST char *name, void *params, u_long ip_addr, u_long ip_mask) { .. return NutNetIfSetup(dev, ip_addr, ip_mask, 0); to int NutNetIfConfig(CONST char *name, void *params, u_long ip_addr, u_long ip_mask, u_long gateway) { .. return NutNetIfSetup(dev, ip_addr, ip_mask, gateway); and in dhcpc.c int NutDhcpIfConfig(CONST char *name, u_char *mac, u_long timeout) { ... return NutNetIfConfig(name, confnet.cdn_mac, confnet.cdn_ip_addr, confnet.cdn_ip_mask, confnet.cdn_gateway); From damian at commtech.com.au Thu Sep 18 06:04:43 2003 From: damian at commtech.com.au (Damian Slee) Date: Thu, 18 Sep 2003 12:04:43 +0800 Subject: [En-Nut-Discussion] should fclose(stream) also close the socket? Message-ID: Hi, currently it doesn't, a separate call to NutTcpCloseSocket(sock) has to be made. From gedas at post.tvk.lt Thu Sep 18 06:42:57 2003 From: gedas at post.tvk.lt (Gediminas Simanskis) Date: Thu, 18 Sep 2003 07:42:57 +0300 Subject: [En-Nut-Discussion] comport driver for tl16c554 References: Message-ID: <003101c37d9f$554a2360$6400a8c0@elgama> 8 comport , 2x TL16C554 -------------- next part -------------- A non-text attachment was scrubbed... Name: uart_tl16c554.zip Type: application/octet-stream Size: 4537 bytes Desc: not available URL: From Douglas.Pearless at pearless.co.nz Thu Sep 18 07:17:23 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Thu, 18 Sep 2003 17:17:23 +1200 Subject: [En-Nut-Discussion] comport driver for tl16c554 In-Reply-To: <003101c37d9f$554a2360$6400a8c0@elgama> Message-ID: This is great. Do I assume from reading the code, UART 1-4 are at 0xF840 and 5-8 at 0xF860, both sharing INT4? I'll need to digest this over the next few days. Thanks very much. Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Gediminas Simanskis Sent: Thursday, 18 September 2003 4:43 p.m. To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] comport driver for tl16c554 8 comport , 2x TL16C554 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From Douglas.Pearless at pearless.co.nz Thu Sep 18 07:21:22 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Thu, 18 Sep 2003 17:21:22 +1200 Subject: [En-Nut-Discussion] comport driver for tl16c554 In-Reply-To: <003101c37d9f$554a2360$6400a8c0@elgama> Message-ID: Could you also post the uart554.h file too? Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Gediminas Simanskis Sent: Thursday, 18 September 2003 4:43 p.m. To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] comport driver for tl16c554 8 comport , 2x TL16C554 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003 From gedas at post.tvk.lt Thu Sep 18 07:33:32 2003 From: gedas at post.tvk.lt (Gediminas Simanskis) Date: Thu, 18 Sep 2003 08:33:32 +0300 Subject: [En-Nut-Discussion] comport driver for tl16c554 References: Message-ID: <00ba01c37da6$68e3ab60$6400a8c0@elgama> > Do I assume from reading the code, UART 1-4 are at 0xF840 and 5-8 at 0xF860, > both sharing INT4? Yes. first chip TL16C554 INTA-INTD conected via OR to port adress 0xF8400 ,second TL16C554 to 0xF860.And all share INT4. From gedas at post.tvk.lt Thu Sep 18 07:34:52 2003 From: gedas at post.tvk.lt (Gediminas Simanskis) Date: Thu, 18 Sep 2003 08:34:52 +0300 Subject: [En-Nut-Discussion] comport driver for tl16c554 References: Message-ID: <00c101c37da6$97d57de0$6400a8c0@elgama> A non-text attachment was scrubbed... Name: Uart554.h Type: application/octet-stream Size: 2340 bytes Desc: not available URL: From damian at commtech.com.au Thu Sep 18 09:36:31 2003 From: damian at commtech.com.au (Damian Slee) Date: Thu, 18 Sep 2003 15:36:31 +0800 Subject: [En-Nut-Discussion] src ip filtering addition Message-ID: Hi, I have made a change to allow/drop IP in packets, ie filter. Can this be added to CVS? Attached modified ipin.c, ip.h from cvs yesterday. Summary ------- I have a callback function that I register with, NutIpSetInputFilter(NutIpFilterFunc callbackFunc). The callback receives the source IP address as a parmater. It returns 0 for allow, -1 for deny. The developer implements their own rule table. e.g. Allows all devices on subnet 192.168.0.0/255.255.255.0 to talk to ethernut. u_long myFilterIp; u_long myFilterMask; int MyNutIpFilter(u_long ip_src) { if ((ip_src & myFilterMask) == myFilterIp) return 0; return -1; } main() { // Do DHCP.... ... myFilterIp = inet_addr("192.168.0.0"); myFilterMask = inet_addr("255.255.255.0"); NutIpSetInputFilter(MyNutIpFilter); ... } ----------------------------------------------------------- Changes to ipin.c Addition NutIpFilterFunc NutIpFilter = 0; void NutIpSetInputFilter(NutIpFilterFunc callbackFunc) { NutIpFilter = callbackFunc; } Change void NutIpInput(NUTDEVICE * dev, NETBUF * nb) { ... /* * Silently discard datagrams of different IP version * and fragmented datagrams, and Filtered IP datagrams */ if (ip->ip_v != IPVERSION || (ntohs(ip->ip_off) & (IP_MF | IP_OFFMASK)) != 0 || (NutIpFilter && NutIpFilter(ip->ip_src))) { NutNetBufFree(nb); return; } ... } -------------- next part -------------- A non-text attachment was scrubbed... Name: ipin.zip Type: application/x-zip-compressed Size: 5946 bytes Desc: ipin.zip URL: From damian at commtech.com.au Thu Sep 18 09:32:13 2003 From: damian at commtech.com.au (Damian Slee) Date: Thu, 18 Sep 2003 15:32:13 +0800 Subject: [En-Nut-Discussion] src ip filtering addition Message-ID: Hi, I have made a change to allow/drop IP in packets, ie filter. Can this be added to CVS? Attached modified ipin.c, ip.h from cvs yesterday. Summary ------- I have a callback function that I register with, NutIpSetInputFilter(NutIpFilterFunc callbackFunc). The callback receives the source IP address as a parmater. It returns 0 for allow, -1 for deny. The developer implements their own rule table. e.g. Allows all devices on subnet 192.168.0.0/255.255.255.0 to talk to ethernut. u_long myFilterIp; u_long myFilterMask; int MyNutIpFilter(u_long ip_src) { if ((ip_src & myFilterMask) == myFilterIp) return 0; return -1; } main() { // Do DHCP.... ... myFilterIp = inet_addr("192.168.0.0"); myFilterMask = inet_addr("255.255.255.0"); NutIpSetInputFilter(MyNutIpFilter); ... } ----------------------------------------------------------- Changes to ipin.c Addition NutIpFilterFunc NutIpFilter = 0; void NutIpSetInputFilter(NutIpFilterFunc callbackFunc) { NutIpFilter = callbackFunc; } Change void NutIpInput(NUTDEVICE * dev, NETBUF * nb) { ... /* * Silently discard datagrams of different IP version * and fragmented datagrams, and Filtered IP datagrams */ if (ip->ip_v != IPVERSION || (ntohs(ip->ip_off) & (IP_MF | IP_OFFMASK)) != 0 || (NutIpFilter && NutIpFilter(ip->ip_src))) { NutNetBufFree(nb); return; } ... } Commtech Wireless www.commtech.com.au (Australia) www.commtechwireless.com (USA) PO Box 1037 OPDC WA 6916 Ph:+61 8 9242 5651 Fax:+61 8 9242 5652 Confidentiality/Limited Liability Statement This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message, you must not disseminate, copy or take any action in reliance on it. If you have received this message in error, please notify Commtech Wireless Pty Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Commtech Wireless. Additionally if prices are quoted in this document then you may consider this document to be an official quotation and the prices quoted are valid for a period of fourteen days from the date of this document. -------------- next part -------------- A non-text attachment was scrubbed... Name: ip.h Type: application/octet-stream Size: 7380 bytes Desc: ip.h URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipin.c Type: application/octet-stream Size: 9047 bytes Desc: ipin.c URL: From damian at commtech.com.au Thu Sep 18 10:41:03 2003 From: damian at commtech.com.au (Damian Slee) Date: Thu, 18 Sep 2003 16:41:03 +0800 Subject: [En-Nut-Discussion] media sense/cable detect Message-ID: >>>Is it possible to tell the difference between the cable being >>>disconnected and the hub/switch/router losing power temporarily? I know on Windows 2k and on, there is no diff. if the switch looses power, all the PC's drop their external interface (192.168.0.x). They are removed from routing tables and everything. I think the arguement is mobility. eg changing from LAN to 802.11 with a notebook. There is a registry entry to disable it in windows. >>>>When the cable is unplugged all TCP connections can be flaged as closed. >>Does Windows do this? yep. I'm thinking now it may not be a good option. From cosminbuhu at lycos.co.uk Thu Sep 18 15:02:34 2003 From: cosminbuhu at lycos.co.uk (Cosmin Buhu) Date: Thu, 18 Sep 2003 16:02:34 +0300 Subject: [En-Nut-Discussion] Socket timeouts In-Reply-To: References: Message-ID: <20030918160234.0042788d.cosminbuhu@lycos.co.uk> Hello, Please if anyone can comment about socket timeouts, SO_SNDTIMEO and SO_RCVTIMEO, how are they acting and what should be a good strategy to use them. Thanks, Cosmin From harald.kipp at egnite.de Thu Sep 18 12:21:07 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 18 Sep 2003 12:21:07 +0200 Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: References: <20030917112539.L2732@gblx.net> <5.1.1.6.0.20030917094830.024a4438@egnite.de> <20030917112539.L2732@gblx.net> Message-ID: <5.1.1.6.0.20030918121049.01b1c890@egnite.de> Ted, >There's an excellant discussion of this in the Introduction section of >chapter 23 ("TCP Keepalive Timer") in Stevens "TCP Illustrated Vol 1." This book is the first choice for TCP development. Volume 2 2. ;-) >Is it possible to tell the difference between the cable being >disconnected and the hub/switch/router losing power temporarily? Definitely not. To all: The problem may sound exotic to some of us, but becomes important with PPP and even more important with GPRS. If the line is cut, you don't expect your browser to report an error, but expect the GPRS layer to silently re-establish the link, right? On the other hand, in reliable embedded systems a link cut is an important event. Harald From harald.kipp at egnite.de Thu Sep 18 12:26:12 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 18 Sep 2003 12:26:12 +0200 Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: <20030917112539.L2732@gblx.net> References: <5.1.1.6.0.20030917094830.024a4438@egnite.de> <5.1.1.6.0.20030917094830.024a4438@egnite.de> Message-ID: <5.1.1.6.0.20030918122150.02464090@egnite.de> Hi Austin, > If the link is down it should flag packets going to that interface >with an icmp network unreachable, or something like that. The received icmp >should be interpreted by the device as being a good reason to close the >connection. Or something like that. I'm not _that_ familiar with the >exact method. Grumble...[Very small font]Ethernut doesn't handle this ICMP message. Quite tricky to implement without destroying the layered design[/Very smal font] But, if I didn't misunderstood, the problem is on the receiver side. The receiver will not notice a cut link and may hang forever. Harald From harald.kipp at egnite.de Thu Sep 18 12:48:08 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 18 Sep 2003 12:48:08 +0200 Subject: [En-Nut-Discussion] WinAVR: Using uisp with Ethernut's STK500 dongle In-Reply-To: <1063821908.2278.47.camel@hw.vabo.cz> References: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> Message-ID: <5.1.1.6.0.20030918122809.01aea868@egnite.de> Pavel, >If I use Ethernut's STK500 dongle with AVR studio everything works OK. I >have replaced the Ethernut's STK500 dongle with STK500 Protocol AVR >Bootloader - http://avr1.org/stk500boot/stk500boot.html and UISP works >fine. You did what?!?! Wow, didn't expect that this works. Thanks for the info. But now you spoiled your dongle and lost guarantee, hehehehe... Nah, seriously. I'll publish our dongle firmware, which is completely in assembler. I'm just a little bit scared, because dongle problems are reported most often by people who bought Starter Kits. Since their first release, we never changed the firmware, if I remember correctly. What would happen, if modified releases are floating around? Btw. there is a serious problem with it. Our dongle will not work with targets running on 8 MHz or below. Jan Rehak reported this recently and we also failed to program older systems with 3.6864 MHz crystals. Jan plans to design a newer version using an AVR with more RAM. >Which version of dongle firmware are you using ? SISP 1.0.1.1 and uisp version 20030827cvs Harald From ceba at vabo.cz Thu Sep 18 13:27:24 2003 From: ceba at vabo.cz (Pavel Celeda) Date: 18 Sep 2003 13:27:24 +0200 Subject: [En-Nut-Discussion] WinAVR: Using uisp with Ethernut's STK500 dongle In-Reply-To: <5.1.1.6.0.20030918122809.01aea868@egnite.de> References: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> <5.1.1.6.0.20030918122809.01aea868@egnite.de> Message-ID: <1063884444.2317.23.camel@hw.vabo.cz> > >If I use Ethernut's STK500 dongle with AVR studio everything works OK. I > >have replaced the Ethernut's STK500 dongle with STK500 Protocol AVR > >Bootloader - http://avr1.org/stk500boot/stk500boot.html and UISP works > >fine. > > You did what?!?! Wow, didn't expect that this works. 1) I have patched the code of stk500boot.c so it works with Charon II and Development Board. 2) I have flashed the bootloader in the ATmega128 and set the necessary fuses. 3) I have removed all programming dongles (STK200, STK500). Now I download the code via UART0. > Thanks for the info. > > But now you spoiled your dongle and lost guarantee, hehehehe... I didn't touched the dongle. :) > Nah, seriously. I'll publish our dongle firmware, which > is completely in assembler. I'm just a little bit scared, > because dongle problems are reported most often by people > who bought Starter Kits. Since their first release, we > never changed the firmware, if I remember correctly. > What would happen, if modified releases are floating > around? > > Btw. there is a serious problem with it. Our dongle will > not work with targets running on 8 MHz or below. Jan Rehak > reported this recently and we also failed to program older > systems with 3.6864 MHz crystals. Jan plans to design a > newer version using an AVR with more RAM. I know about it, I have already faced with this problem. > >Which version of dongle firmware are you using ? > > SISP 1.0.1.1 > and > uisp version 20030827cvs I have tested a dozen of UISP versions but without success. So I was really startled after receiving your email. Pavel From troth at openavr.org Thu Sep 18 18:33:31 2003 From: troth at openavr.org (Theodore A. Roth) Date: Thu, 18 Sep 2003 09:33:31 -0700 (PDT) Subject: [En-Nut-Discussion] WinAVR: Using uisp with Ethernut's STK500 dongle In-Reply-To: <1063884444.2317.23.camel@hw.vabo.cz> References: <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> <5.1.1.6.0.20030916121040.01dbb5c0@egnite.de> <5.1.1.6.0.20030918122809.01aea868@egnite.de> <1063884444.2317.23.camel@hw.vabo.cz> Message-ID: On Thu, 18 Sep 2003, Pavel Celeda wrote: > > >Which version of dongle firmware are you using ? > > > > SISP 1.0.1.1 > > and > > uisp version 20030827cvs > > I have tested a dozen of UISP versions but without success. So I was > really startled after receiving your email. Can you send me a dump of the uisp output using -v=4? From ralph.mason at telogis.com Thu Sep 18 22:57:56 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Fri, 19 Sep 2003 08:57:56 +1200 Subject: [En-Nut-Discussion] media sense/cable detect In-Reply-To: <5.1.1.6.0.20030918122150.02464090@egnite.de> Message-ID: > > Grumble...[Very small font]Ethernut doesn't handle this ICMP > message. Quite tricky to implement without destroying the layered > design[/Very smal font] > The ICMP socket class I contributed would make it very easy to receive this message if one were interested in it. Ralph --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 From damian at commtech.com.au Fri Sep 19 01:51:12 2003 From: damian at commtech.com.au (Damian Slee) Date: Fri, 19 Sep 2003 07:51:12 +0800 Subject: [En-Nut-Discussion] Socket timeouts Message-ID: I'm using SO_RCVTIMEO, mainly so I can do some other things on the same thread, I could do it on another thread, but then would have to handle syncronising access to variables from different threads. And some more resources would be used by the second thread. I'm not changing SO_SNDTIMEO. ie leaving it as blocking, if the internally buffer can't take it all. -----Original Message----- From: Cosmin Buhu [mailto:cosminbuhu at lycos.co.uk] Sent: Thursday, 18 September 2003 9:03 PM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] Socket timeouts Hello, Please if anyone can comment about socket timeouts, SO_SNDTIMEO and SO_RCVTIMEO, how are they acting and what should be a good strategy to use them. Thanks, Cosmin _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From michael at lfiinternational.com Fri Sep 19 01:49:50 2003 From: michael at lfiinternational.com (Michael G. Svob) Date: Thu, 18 Sep 2003 16:49:50 -0700 Subject: [En-Nut-Discussion] Using WinAVR libraries Message-ID: Greetings, I was wondering if anyone could provide me assistance with using the WinAVR header files and libraries with my Ethernut. In particular, I would like to take advantage of functions in stdlib.h and math.h. Thanks in advance for any insight. Best Regards, Michael Svob LFI International From damian at commtech.com.au Fri Sep 19 05:40:02 2003 From: damian at commtech.com.au (Damian Slee) Date: Fri, 19 Sep 2003 11:40:02 +0800 Subject: [En-Nut-Discussion] Changing password for "cgi-bin" catalog in httpd example Message-ID: I'm getting same problem here. I've debugged it a bit further tho. Works ok for root:root. But if I change string lengths it doesn't work, works for some... NutRegisterAuth("cgi-bin", "root:public"); then dumping the strings out the serial port... - root:public entered into browser NutHttpAuthValidate() - pre, post base64 decode base64:cm9vdDpwdWJsaWM= Notice the crap character at the end after the decode. base64dec:root:public? NutHttpAuthLookup() - login, auth in memory root:public?, root:public Fails! I just tried copying the NutDecodeBase64 into a Win32 console app with same base64 string "cm9vdDpwdWJsaWM=" and am getting no problem under VC. I'll trace the output of the two, and find out where it differs. -----Original Message----- From: Harald Kipp [mailto:harald.kipp at egnite.de] Sent: Tuesday, 16 September 2003 4:53 PM To: en-nut-discussion at egnite.de Subject: Re: [En-Nut-Discussion] Changing password for "cgi-bin" catalog in httpd example > >This is what I changed it to: >NutRegisterAuth("cgi-bin", "boot:boot"); Works fine here. May be a problem with your browser? Harald _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From damian at commtech.com.au Fri Sep 19 07:02:09 2003 From: damian at commtech.com.au (Damian Slee) Date: Fri, 19 Sep 2003 13:02:09 +0800 Subject: [En-Nut-Discussion] BUGFIX: NutDecodeBase64() Message-ID: hehe, this has caught me out a couple of times as well porting some code from VC to GCC. What was happening was the if statment was never failing when 'code == -1' for (tp = sp = str; *sp; ++sp) { if ((code = PRG_RDB(&base64dtab[(int) *sp])) == -1) continue; This is because base64dtab[] is an array of char, and -1 is 255. 'code' is an int. -1 is 65535. 255 != 65535. Changing 'code' & 'last' to char, from int, fixes the problem. From ralph.mason at telogis.com Fri Sep 19 07:02:44 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Fri, 19 Sep 2003 17:02:44 +1200 Subject: [En-Nut-Discussion] Socket timeouts In-Reply-To: Message-ID: You should not need any synchronisation between threads, because there is no preemptive scheduling. Your thread will only context switch if you let it. Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Damian Slee > Sent: Friday, 19 September 2003 11:51 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Socket timeouts > > > I'm using SO_RCVTIMEO, mainly so I can do some other things on > the same thread, I could do it on another thread, but then would > have to handle syncronising access to variables from different > threads. And some more resources would be used by the second thread. > > I'm not changing SO_SNDTIMEO. ie leaving it as blocking, if the > internally buffer can't take it all. > > -----Original Message----- > From: Cosmin Buhu [mailto:cosminbuhu at lycos.co.uk] > Sent: Thursday, 18 September 2003 9:03 PM > To: en-nut-discussion at egnite.de > Subject: [En-Nut-Discussion] Socket timeouts > > > > > Hello, > > Please if anyone can comment about socket timeouts, > SO_SNDTIMEO and SO_RCVTIMEO, how are they acting and what should > be a good strategy to use them. > > Thanks, > Cosmin > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 From ngbmoreau at yahoo.com.au Fri Sep 19 09:03:33 2003 From: ngbmoreau at yahoo.com.au (NGB) Date: Fri, 19 Sep 2003 17:03:33 +1000 Subject: [En-Nut-Discussion] Sockets Message-ID: <1063955013.3f6aaa4540e0a@tiger.enttec> I have 1 UDP socket that I needs to be accessed from 2 threads, 1 thread is reading from the socket the other writing. Does ethernut support this ? Anything I should be aware of ? Nic ------------------------------------------------- From harald.kipp at egnite.de Fri Sep 19 10:32:07 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Fri, 19 Sep 2003 10:32:07 +0200 Subject: [En-Nut-Discussion] Sockets In-Reply-To: <1063955013.3f6aaa4540e0a@tiger.enttec> Message-ID: <5.1.1.6.0.20030919103054.01a92f88@egnite.de> > >I have 1 UDP socket that I needs to be accessed from 2 threads, 1 thread is >reading from the socket the other writing. >Does ethernut support this ? >Anything I should be aware of ? No known problems. You can share UDP and TCP sockets between threads. Harald From ngbmoreau at yahoo.com.au Mon Sep 22 04:24:17 2003 From: ngbmoreau at yahoo.com.au (NGB) Date: Mon, 22 Sep 2003 12:24:17 +1000 Subject: [En-Nut-Discussion] Sockets In-Reply-To: <5.1.1.6.0.20030919103054.01a92f88@egnite.de> References: <5.1.1.6.0.20030919103054.01a92f88@egnite.de> Message-ID: <1064197457.3f6e5d515282d@tiger.enttec> Out of curiostity what happens if 2 tasks wait on the same socket Is it the first one that waits that get's suspended, what happens to the other ? Thanks Nic Quoting Harald Kipp : > > > > >I have 1 UDP socket that I needs to be accessed from 2 threads, 1 thread is > >reading from the socket the other writing. > >Does ethernut support this ? > >Anything I should be aware of ? > > No known problems. You can share UDP and TCP sockets > between threads. > > Harald > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > ------------------------------------------------- From ralph.mason at telogis.com Mon Sep 22 04:52:21 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Mon, 22 Sep 2003 14:52:21 +1200 Subject: [En-Nut-Discussion] Sockets In-Reply-To: <1064197457.3f6e5d515282d@tiger.enttec> Message-ID: Same as if two threads waited on any event. The would both get suspended. The one with the highest priority would get woken first. You might like to look at NutEventWait. Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of NGB > Sent: Monday, 22 September 2003 2:24 > To: en-nut-discussion at egnite.de > Subject: Re: [En-Nut-Discussion] Sockets > > > Out of curiostity what happens if 2 tasks wait on the same socket > Is it the first one that waits that get's suspended, what happens > to the other ? > > Thanks > > Nic > > > Quoting Harald Kipp : > > > > > > > > >I have 1 UDP socket that I needs to be accessed from 2 > threads, 1 thread is > > >reading from the socket the other writing. > > >Does ethernut support this ? > > >Anything I should be aware of ? > > > > No known problems. You can share UDP and TCP sockets > > between threads. > > > > Harald > > > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > > > > > > ------------------------------------------------- > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 From damian at commtech.com.au Mon Sep 22 06:02:51 2003 From: damian at commtech.com.au (Damian Slee) Date: Mon, 22 Sep 2003 12:02:51 +0800 Subject: [En-Nut-Discussion] Socket timeouts Message-ID: >>You should not need any synchronisation between threads what about the Nut timer callbacks which is interrupt based? -----Original Message----- From: Ralph Mason [mailto:ralph.mason at telogis.com] Sent: Friday, 19 September 2003 1:03 PM To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] Socket timeouts You should not need any synchronisation between threads, because there is no preemptive scheduling. Your thread will only context switch if you let it. Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Damian Slee > Sent: Friday, 19 September 2003 11:51 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Socket timeouts > > > I'm using SO_RCVTIMEO, mainly so I can do some other things on > the same thread, I could do it on another thread, but then would > have to handle syncronising access to variables from different > threads. And some more resources would be used by the second thread. > > I'm not changing SO_SNDTIMEO. ie leaving it as blocking, if the > internally buffer can't take it all. > > -----Original Message----- > From: Cosmin Buhu [mailto:cosminbuhu at lycos.co.uk] > Sent: Thursday, 18 September 2003 9:03 PM > To: en-nut-discussion at egnite.de > Subject: [En-Nut-Discussion] Socket timeouts > > > > > Hello, > > Please if anyone can comment about socket timeouts, > SO_SNDTIMEO and SO_RCVTIMEO, how are they acting and what should > be a good strategy to use them. > > Thanks, > Cosmin > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From ralph.mason at telogis.com Mon Sep 22 06:10:24 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Mon, 22 Sep 2003 16:10:24 +1200 Subject: [En-Nut-Discussion] Socket timeouts In-Reply-To: Message-ID: I don't really think there is much need to interact with the operating system in a timer call back. It has many many drawbacks (not the least of which is non deterministic stack requirements) What is wrong with a thread like? while(1){ NutSleep(1000); //Do synchronised code } Nice, safe simple. Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Damian Slee > Sent: Monday, 22 September 2003 4:03 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Socket timeouts > > > >>You should not need any synchronisation between threads > > what about the Nut timer callbacks which is interrupt based? > > -----Original Message----- > From: Ralph Mason [mailto:ralph.mason at telogis.com] > Sent: Friday, 19 September 2003 1:03 PM > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] Socket timeouts > > > You should not need any synchronisation between threads, because > there is no > preemptive scheduling. > > Your thread will only context switch if you let it. > > Ralph > > > -----Original Message----- > > From: en-nut-discussion-admin at egnite.de > > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Damian Slee > > Sent: Friday, 19 September 2003 11:51 > > To: en-nut-discussion at egnite.de > > Subject: RE: [En-Nut-Discussion] Socket timeouts > > > > > > I'm using SO_RCVTIMEO, mainly so I can do some other things on > > the same thread, I could do it on another thread, but then would > > have to handle syncronising access to variables from different > > threads. And some more resources would be used by the second thread. > > > > I'm not changing SO_SNDTIMEO. ie leaving it as blocking, if the > > internally buffer can't take it all. > > > > -----Original Message----- > > From: Cosmin Buhu [mailto:cosminbuhu at lycos.co.uk] > > Sent: Thursday, 18 September 2003 9:03 PM > > To: en-nut-discussion at egnite.de > > Subject: [En-Nut-Discussion] Socket timeouts > > > > > > > > > > Hello, > > > > Please if anyone can comment about socket timeouts, > > SO_SNDTIMEO and SO_RCVTIMEO, how are they acting and what should > > be a good strategy to use them. > > > > Thanks, > > Cosmin > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > _______________________________________________ > > En-Nut-Discussion mailing list > > En-Nut-Discussion at egnite.de > > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > > > --- > > Incoming mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 From mikec at call-direct.com.au Tue Sep 23 03:57:34 2003 From: mikec at call-direct.com.au (Mike Cornelius) Date: Tue, 23 Sep 2003 11:57:34 +1000 Subject: [En-Nut-Discussion] ICMP Sockets In-Reply-To: Message-ID: <013901c38176$0fbb19f0$2301a8c0@Mike> Hi Ralph, Thanks a lot for the ICMP code, I've just been getting to use it and found that you refer to :- icp->ident In NutIcmpInput() The version of ICMPHDR in ip_icmp.h in the distribution that I have has a single u_long icmp_spec where I figure ident would go. What's the deal ? Have you modified ICMPHDR and therefore NutIcmpReply() in icmpout.c which uses icmp_spec ? Or is NutIcmpInput() not quite right ? Or something else ? I also notice the following :- #ifdef NAT_SUPPORT RouteIncommingPacket(nb,IPPROTO_ICMP); #else This is most intriguing, I take it you have or are in the process of implementing NAT, this would be most useful, any chance of releasing this too? Regards, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Mike Cornelius Internet: mikec at call-direct.com.au Call Direct Cellular Solutions Phone: +61 2 9209-4259 Suite 145 FAX: +61 2 9209-4196 National Innovation Centre URL: http://www.call-direct.com.au Australian Technology Park Eveleigh NSW 1430 Australia ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of Ralph Mason Sent: Monday, August 11, 2003 6:10 PM To: en-Nut-Discussion Subject: [En-Nut-Discussion] ICMP Sockets I have implemented ICMP sockets for NutOS if anyone is interested. You can do tracert, ping etc. You can also receive unreachable messages etc for a given TCP or UDP connection. Example code int ping(char* args[],int argc, FILE* f){ u_long addr; ICMPSOCKET* sock; u_char data[32]; int i; if ( argc < 2 ){ fputs_P(PSTR("usage: ping host [timeout]\r\n"),f); return -1; } if( (addr = resolve_address_name(args[1],f)) == 0 ){ cr(f); return 0; } sock = NutIcmpCreateSocket(IPPROTO_ICMP,1); fprintf_P(f,PSTR("Pinging %s [%a] with 32 bytes\r\n\r\n"),args[1],addr); fflush(f); for( i = 0 ; i < 4 ; i++){ u_long reply_addr; u_char type; u_char code; u_long ticks; NutIcmpSendTo(sock,addr,ICMP_ECHO,0,data,32); ticks = NutGetTickCount(); if ( NutIcmpReceiveFrom(sock,&reply_addr,&type,&code,data,32,3000) != 0){ switch( type){ case ICMP_ECHOREPLY: fprintf_P(f,PSTR("Relpy from %a %i ms\r\n"),reply_addr, (int)(((NutGetTickCount()-ticks)*1000)/ 40L)); break; default: fprintf_P(f,PSTR("Relpy from %a type %i code %i\r\n"), reply_addr,type,code); } } else{ fputs_P(PSTR("Request timed out.\r\n"),f); } fflush(f); } NutIcmpDestroySocket(sock); return 0; } If you want the code reply via email. Cheers Ralph --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003 _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From laran at ikp.liu.se Tue Sep 23 14:11:19 2003 From: laran at ikp.liu.se (Lars Andersson) Date: Tue, 23 Sep 2003 14:11:19 +0200 Subject: [En-Nut-Discussion] Generate graphics on Ethernut Message-ID: <6D71E1FB451D984081153EC11D7A3DDB91AA8B@mail.ikp.liu.se> Hi all, I have a wish and that is to generate graphics on the Ethernut and then present this in a web interface. I have heard that PNG is supposed to be a rather simple way of generating images and is therefore curious if anyone has done this on the ethernut or if anyone know of code that might be compact enough to work on a Mega128. Regards, /Lars A Andersson From ralph.mason at telogis.com Tue Sep 23 04:18:26 2003 From: ralph.mason at telogis.com (Ralph Mason) Date: Tue, 23 Sep 2003 14:18:26 +1200 Subject: [En-Nut-Discussion] ICMP Sockets In-Reply-To: <013901c38176$0fbb19f0$2301a8c0@Mike> Message-ID: Hi Mike, You are correct I did modify the ICMPHDR file forgot to include the file I updated (attached). Yes, I do have a rough version of NAT working for NutOS, but it's not ready for public consumption yet, it supports multiple PPP interfaces, so you can have a PPP server. I plan on releasing it 'some time' when it's more complete. Regards Ralph > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Mike Cornelius > Sent: Tuesday, 23 September 2003 1:58 > To: en-nut-discussion at egnite.de > Subject: RE: [En-Nut-Discussion] ICMP Sockets > > > Hi Ralph, > > Thanks a lot for the ICMP code, I've just been getting to use it and > found that you refer to :- > > icp->ident In NutIcmpInput() > > The version of ICMPHDR in ip_icmp.h in the distribution that I have has > a single u_long icmp_spec where I figure ident would go. > > What's the deal ? > Have you modified ICMPHDR and therefore NutIcmpReply() in icmpout.c > which uses icmp_spec ? > Or is NutIcmpInput() not quite right ? > Or something else ? > > I also notice the following :- > #ifdef NAT_SUPPORT > RouteIncommingPacket(nb,IPPROTO_ICMP); > #else > > This is most intriguing, I take it you have or are in the process of > implementing NAT, this would be most useful, any chance of releasing > this too? > > Regards, > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~ > Mike Cornelius Internet: mikec at call-direct.com.au > Call Direct Cellular Solutions Phone: +61 2 9209-4259 > Suite 145 FAX: +61 2 9209-4196 > National Innovation Centre URL: http://www.call-direct.com.au > Australian Technology Park > Eveleigh NSW 1430 > Australia > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~ > > > -----Original Message----- > From: en-nut-discussion-admin at egnite.de > [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of Ralph Mason > Sent: Monday, August 11, 2003 6:10 PM > To: en-Nut-Discussion > Subject: [En-Nut-Discussion] ICMP Sockets > > > I have implemented ICMP sockets for NutOS if anyone is interested. > > You can do tracert, ping etc. > > You can also receive unreachable messages etc for a given TCP or UDP > connection. > > Example code > > int ping(char* args[],int argc, FILE* f){ > > u_long addr; > ICMPSOCKET* sock; > u_char data[32]; > int i; > > if ( argc < 2 ){ > fputs_P(PSTR("usage: ping host [timeout]\r\n"),f); > return -1; > } > > if( (addr = resolve_address_name(args[1],f)) == 0 ){ > cr(f); > return 0; > } > > sock = NutIcmpCreateSocket(IPPROTO_ICMP,1); > > fprintf_P(f,PSTR("Pinging %s [%a] with 32 > bytes\r\n\r\n"),args[1],addr); > fflush(f); > > for( i = 0 ; i < 4 ; i++){ > u_long reply_addr; > u_char type; > u_char code; > u_long ticks; > > NutIcmpSendTo(sock,addr,ICMP_ECHO,0,data,32); > ticks = NutGetTickCount(); > > if ( > NutIcmpReceiveFrom(sock,&reply_addr,&type,&code,data,32,3000) != 0){ > > switch( type){ > case ICMP_ECHOREPLY: > fprintf_P(f,PSTR("Relpy from %a > %i ms\r\n"),reply_addr, > > (int)(((NutGetTickCount()-ticks)*1000)/ 40L)); > break; > > default: > fprintf_P(f,PSTR("Relpy from %a > type %i code %i\r\n"), > > reply_addr,type,code); > } > } > else{ > fputs_P(PSTR("Request timed > out.\r\n"),f); > } > > fflush(f); > } > > NutIcmpDestroySocket(sock); > > return 0; > } > > > > If you want the code reply via email. > > Cheers > Ralph > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.491 / Virus Database: 290 - Release Date: 18/06/2003 > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 1/09/2003 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ip_icmp.h URL: From Fahad.Gilani at anu.edu.au Tue Sep 23 19:15:58 2003 From: Fahad.Gilani at anu.edu.au (Fahad G.) Date: 24 Sep 2003 03:15:58 +1000 Subject: [En-Nut-Discussion] X-10 anyone? Message-ID: <1064337358.3922.3.camel@Fahad> Hi, I recently started working on an X-10 device, trying to communicate with it using ethernut and a GSM Ultralite E iT device. I was wondering if anyone on the mailing list has tried ethernut with X-10 devices? If so, could s/he share code/experiences with me? thanks, cheers, Fahad ----------------------------------------------------------------------------------------------- main(){int j=1234;char t[]=":@abcdefghijklmnopqrstuvwxyz.\n",*i= "iqgbgxmfxfvbviabrlxt at lfeg\npecsf";char *strchr(const char*,int); while(*i){j+=strchr(t,*i++)-t;j%=sizeof t-1;putchar(t[j]);}return 0;} -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brett.Abbott at digital-telemetry.com Wed Sep 24 02:34:10 2003 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Wed, 24 Sep 2003 12:34:10 +1200 Subject: [En-Nut-Discussion] PPP Retrying when no PPP/GPRS is available Message-ID: <3F70E682.8050308@digital-telemetry.com> Hi Using the PPP in version 3.3.0, you may find that when a PPP service (such as a GPRS modem) only partially responds to a Dial command, or the ifconfig fails, the lcp state engine may time out. Repeated attempts to redial (atd99*** etc) then seem to fall on deaf ears. A specific example of this is when the initial chat command is acknowledged (ie. OK, CONNECT) and then no reponse comes from the PPP engine, it will send 9 retries before going to bed.. Will the kind assistance from Harald, Ive tracked down that in this timeout scenario, the lcp state is set to STOPPED. When STOPPED, the subsequent request to perform an "if (NutNetIfConfig("ppp", 0, 0, 0)) " will not result in any outgoing packets and the ppp thread will remain STOPPED. Also, there is a (useful) workaround in place using a the global variable ppp_hackup. When set to 0, the ppp engine does not attempt to talk with the interface. We use this to allow chat commands to control the modem. Note that when set to 1 (when calling NutNetIfConfig), even if the engine is STOPPED, any characters sent to the interface (like ATD to reconnect) are absorbed by the ppp engine and rejected as invalid, never reaching the modem. The quick fix to this is a two parter..... First we set the global variable to 0 (ppp_hackup=0), then we tickle the ppp state machine by setting the lcp_status to STARTING (Using the lcp_lowerdown function). The ppp_hackup setting stops the newly woken ppp state machine from saying hi to the modem until we've redone our dial command. We redial if needed then reprod the engine using "if (NutNetIfConfig("ppp", 0, 0, 0)) " Ideally you ought to close the engine and go through a proper restart/retry but this ought to solve the problem for now. Ive taken this approach rather than solving it nicely as I know Harald is soon to modify/improve the way this functionality is to work. I would like to propose the "ideal" solution but Im still reading the PPP text book and would greatfully receive thoughts on how it really ought to be solved. I include the modified source showing the workaround. Also refer you to the pppd.c sample in the CVS repository. Additionally, I am writing commands to pause the PPP interface, interogate the modem status (ie. go into command mode), execute a command such as "Signal Strength" and then return to Data Mode (ATO) and resume PPP. Has anyone else done this? (the ppp_hackup supports this). Perhaps it is better named "ppp_pause". In the ideal world, I guess this is done by putting the engine into a known PAUSE state as it is possible to have more than one PPP interface. Many Thanks in advance. Brett // If the link is lost, it will try to reopen link if( dcb->dcb_ipcp_state != PPPS_OPENED ) // only proceed if the ppp isnt opened { // Put your code here to ensure the modem is hungup, perhaps : // sleep 1 second, +++, sleep 1 second, ATH // Tell the modem to connect to PPP if (NutChat(pppcom,"'' 'at+cgdcont=1,\"IP\",\"yourAPN\"' 'OK' 'atd*99***1#' 'CONNECT'") == 0) { // attempt to configure the network interface if (NutNetIfConfig("ppp", 0, 0, 0)) { fprintf(tcpip1, "PPP failed\r\n"); fflush(tcpip1); // WORKAROUND CODE STARTS HERE ---- Note ppp_hackup is local to the ppp code and to work like this you must // include the library code in your source or place this code in the library pppdev = NutDeviceLookup("ppp"); ppp_hackup=0; rc=NutPppIOCtl(pppdev, LCP_LOWERDOWN, 0); // WORKAROUND CODE ENDS HERE NutSleep(5000); continue; // go back and try again } else { // Worked // * Set name server and default route. Actually the PPP interface // * should do this, but the current release doesn't. dcb = devPpp.dev_dcb; NutDnsConfig2(0, 0, dcb->dcb_ip_dns1, dcb->dcb_ip_dns2); NutIpRouteAdd(0, 0, dcb->dcb_remote_ip, &devPpp); if((rip = NutDnsGetHostByName(INETSERVER)) != 0) { fprintf(tcpip1, "%s: %s\r\n", INETSERVER, inet_ntoa(rip)); fflush(tcpip1); } } } else { // Error with chat fprintf(tcpip1,"...error in chat \r\n"); fflush(tcpip1); NutSleep(5000); continue; } } ----------------------------------------------------------------- Brett Abbott, Managing Director, Digital Telemetry Limited Email: Brett.Abbott at digital-telemetry.com PO Box 24 036 Manners Street, Wellington, New Zealand Phone +64 (4) 5666-860 Mobile +64 (21) 656-144 ------------------- Commercial in confidence -------------------- From mikec at call-direct.com.au Wed Sep 24 03:06:51 2003 From: mikec at call-direct.com.au (Mike Cornelius) Date: Wed, 24 Sep 2003 11:06:51 +1000 Subject: [En-Nut-Discussion] PPP Retrying when no PPP/GPRS is available In-Reply-To: <3F70E682.8050308@digital-telemetry.com> Message-ID: <018501c38238$242c2c40$2301a8c0@Mike> Hi Brett, Second things first, I've not tried interrupting the PPP session whilst it's going and then going back. I assume you're thinking something like: <>PPP[] >+++ >AT+CSQ? <+CSQ: ??,?? >ATO <>PPP[] But it's certainly an interesting idea and if I get a chance I give it a whirl and let you know what I find. On the first point I do things slightly differently and IMHO a little bit less hackish as folows:- int fd_ppp = -1; While (whatever) { if (not up and we want to be) { if ((fd_ppp != -1) && (pdcb->dcb_ipcp_state != PPPS_CLOSED)) { if (_close(fd_ppp) == 0) { ppp_hackup = 0; fd_ppp = -1; } } DisconnectCall(comm_phone); if (NutChat(_fileno(comm_phone), confgprs->setup_string) == 0) { if (fd_ppp == -1) { fd_ppp = _open("ppp:uart0", _O_RDWR | _O_BINARY); ltmp = PHONE_BAUD; _ioctl(fd_ppp, UART_SETSPEED, <mp); } if (NutNetIfConfig("ppp", 0, 0, 0)) { // If we can't establish PPP 3 times in a row reboot ppp_attempts ++; if (ppp_attempts >= 3) CDCS_Reboot(); } else { NutDnsConfig2 (0,0,pdcb->dcb_ip_dns1,pdcb->dcb_ip_dns2); } } } } Regards, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Mike Cornelius Internet: mikec at call-direct.com.au Call Direct Cellular Solutions Phone: +61 2 9209-4259 Suite 145 FAX: +61 2 9209-4196 National Innovation Centre URL: http://www.call-direct.com.au Australian Technology Park Eveleigh NSW 1430 Australia ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de] On Behalf Of Brett Abbott Sent: Wednesday, September 24, 2003 10:34 AM To: en-nut-discussion at egnite.de Subject: [En-Nut-Discussion] PPP Retrying when no PPP/GPRS is available Hi Using the PPP in version 3.3.0, you may find that when a PPP service (such as a GPRS modem) only partially responds to a Dial command, or the ifconfig fails, the lcp state engine may time out. Repeated attempts to redial (atd99*** etc) then seem to fall on deaf ears. A specific example of this is when the initial chat command is acknowledged (ie. OK, CONNECT) and then no reponse comes from the PPP engine, it will send 9 retries before going to bed.. Will the kind assistance from Harald, Ive tracked down that in this timeout scenario, the lcp state is set to STOPPED. When STOPPED, the subsequent request to perform an "if (NutNetIfConfig("ppp", 0, 0, 0)) " will not result in any outgoing packets and the ppp thread will remain STOPPED. Also, there is a (useful) workaround in place using a the global variable ppp_hackup. When set to 0, the ppp engine does not attempt to talk with the interface. We use this to allow chat commands to control the modem. Note that when set to 1 (when calling NutNetIfConfig), even if the engine is STOPPED, any characters sent to the interface (like ATD to reconnect) are absorbed by the ppp engine and rejected as invalid, never reaching the modem. The quick fix to this is a two parter..... First we set the global variable to 0 (ppp_hackup=0), then we tickle the ppp state machine by setting the lcp_status to STARTING (Using the lcp_lowerdown function). The ppp_hackup setting stops the newly woken ppp state machine from saying hi to the modem until we've redone our dial command. We redial if needed then reprod the engine using "if (NutNetIfConfig("ppp", 0, 0, 0)) " Ideally you ought to close the engine and go through a proper restart/retry but this ought to solve the problem for now. Ive taken this approach rather than solving it nicely as I know Harald is soon to modify/improve the way this functionality is to work. I would like to propose the "ideal" solution but Im still reading the PPP text book and would greatfully receive thoughts on how it really ought to be solved. I include the modified source showing the workaround. Also refer you to the pppd.c sample in the CVS repository. Additionally, I am writing commands to pause the PPP interface, interogate the modem status (ie. go into command mode), execute a command such as "Signal Strength" and then return to Data Mode (ATO) and resume PPP. Has anyone else done this? (the ppp_hackup supports this). Perhaps it is better named "ppp_pause". In the ideal world, I guess this is done by putting the engine into a known PAUSE state as it is possible to have more than one PPP interface. Many Thanks in advance. Brett // If the link is lost, it will try to reopen link if( dcb->dcb_ipcp_state != PPPS_OPENED ) // only proceed if the ppp isnt opened { // Put your code here to ensure the modem is hungup, perhaps : // sleep 1 second, +++, sleep 1 second, ATH // Tell the modem to connect to PPP if (NutChat(pppcom,"'' 'at+cgdcont=1,\"IP\",\"yourAPN\"' 'OK' 'atd*99***1#' 'CONNECT'") == 0) { // attempt to configure the network interface if (NutNetIfConfig("ppp", 0, 0, 0)) { fprintf(tcpip1, "PPP failed\r\n"); fflush(tcpip1); // WORKAROUND CODE STARTS HERE ---- Note ppp_hackup is local to the ppp code and to work like this you must // include the library code in your source or place this code in the library pppdev = NutDeviceLookup("ppp"); ppp_hackup=0; rc=NutPppIOCtl(pppdev, LCP_LOWERDOWN, 0); // WORKAROUND CODE ENDS HERE NutSleep(5000); continue; // go back and try again } else { // Worked // * Set name server and default route. Actually the PPP interface // * should do this, but the current release doesn't. dcb = devPpp.dev_dcb; NutDnsConfig2(0, 0, dcb->dcb_ip_dns1, dcb->dcb_ip_dns2); NutIpRouteAdd(0, 0, dcb->dcb_remote_ip, &devPpp); if((rip = NutDnsGetHostByName(INETSERVER)) != 0) { fprintf(tcpip1, "%s: %s\r\n", INETSERVER, inet_ntoa(rip)); fflush(tcpip1); } } } else { // Error with chat fprintf(tcpip1,"...error in chat \r\n"); fflush(tcpip1); NutSleep(5000); continue; } } ----------------------------------------------------------------- Brett Abbott, Managing Director, Digital Telemetry Limited Email: Brett.Abbott at digital-telemetry.com PO Box 24 036 Manners Street, Wellington, New Zealand Phone +64 (4) 5666-860 Mobile +64 (21) 656-144 ------------------- Commercial in confidence -------------------- _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion From Brett.Abbott at digital-telemetry.com Wed Sep 24 04:13:49 2003 From: Brett.Abbott at digital-telemetry.com (Brett Abbott) Date: Wed, 24 Sep 2003 14:13:49 +1200 Subject: [En-Nut-Discussion] Pausing PPP to interogate a GPRS modem Message-ID: <3F70FDDD.4080400@digital-telemetry.com> Mike, Thanks for your reply - very helpful. Further on the interrogation of a GPRS modem. Be aware that most modems allow a more elegant (and speedy) means of executing commands whilst in a call (both PPP and data call). (ie. to check Signal Strength, issue AT commands, perhaps change pin numbers etc whilst still in a session). There is an AT config command which allows you to switch between command (issue AT commands) and Data Mode (assuming you are in a PPP session for GPRS or data call for GSM) using the DTR signal line. When this mode is set prior to the connection, you can raise/lower DTR to go between modes - This effectively avoids the 1 second delay whilst the +++ escape sequence takes hold and gives some certainty to the call mode - always a bit dodgy when you have multiple reasons why +++ wont work. Ive tested this method (ie. pausing PPP session to execute commands) on several modems with success from a PC, however not from Ethernut yet but expect no issues. Cheers and Thanks Brett Message: 5 From: "Mike Cornelius" To: Subject: RE: [En-Nut-Discussion] PPP Retrying when no PPP/GPRS is available Date: Wed, 24 Sep 2003 11:06:51 +1000 Organization: CDCS Reply-To: en-nut-discussion at egnite.de Hi Brett, Second things first, I've not tried interrupting the PPP session whilst it's going and then going back. I assume you're thinking something like: <>PPP[] >>+++ >>AT+CSQ? > <+CSQ: ??,?? >>ATO > <>PPP[] But it's certainly an interesting idea and if I get a chance I give it a whirl and let you know what I find. -- ----------------------------------------------------------------- Brett Abbott, Managing Director, Digital Telemetry Limited Email: Brett.Abbott at digital-telemetry.com PO Box 24 036 Manners Street, Wellington, New Zealand Phone +64 (4) 5666-860 Mobile +64 (21) 656-144 ------------------- Commercial in confidence -------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fahad.Gilani at anu.edu.au Wed Sep 24 09:28:56 2003 From: Fahad.Gilani at anu.edu.au (Fahad G.) Date: Wed, 24 Sep 2003 17:28:56 +1000 Subject: [En-Nut-Discussion] c_turn in turn.c Message-ID: <000c01c3826d$83f2cf00$3cebcb96@Fahad> Hi, What exactly is the function "c_turn(argc, argv)" in turn.c doing (conversely)? By looking at the code I can tell that if 0x55 is not returned, c_turn gets called... since my implementation is a bit different to heyu, could someone explain step-wise what one should do if 0x55 is not returned? Do we wait and send 0x00 again to the device or is there something else that needs to be done? I can't seem to initialize my activehome device upon transmission of 0x00. Thanks, Fahad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltlee at baycomp.com Tue Sep 23 22:12:18 2003 From: ltlee at baycomp.com (Lin Tak Lee) Date: Tue, 23 Sep 2003 16:12:18 -0400 Subject: [En-Nut-Discussion] Error to generate obj file in WINAVR for ethernut Message-ID: Dear sir/madam, I am implementing a small web server on Ethernut board and want to use AVR studio 4 to do the debugging. At a starting point, I use basemon program, which is already built in app folder, as a foundation and configure it. Since AVR studio needs obj file to debug my program, I use Winavr as a compiler to generate obj file by 'make studio' command. But, I got the following error: ********************************** avr-gcc basemon.o urom.o -mmcu=atmega128 -Wl,--defsym=main=0,-Map=basemon.map,-- cref -L../../lib/gcc/atmega128 -lnutnet -lnutpro -lnutfs -lnutos -lnutdev -lnut net -lnutcrt -o basemon.elf avr-objcopy -O avrobj basemon.elf basemon.obj avr-objcopy: basemon.obj: Invalid bfd target make: *** [basemon.obj] Error 1 rm basemon.elf ********************************** Any solutions? On the other hand, I tried another way and used AVR coff beta package which could generates coff file and is accepted as a target in studio too. But, the sample makefile is not really for building a webserver program. So, do you know where I can get a sample makefile which could generate coff file for a webserver like basemon program? If you have this particular sample makefile file, please send it to me. That would be a big help for me! Thanks! Lin Lee From raymax83 at hotmail.com Thu Sep 25 19:52:25 2003 From: raymax83 at hotmail.com (Niels Bergsma) Date: Thu, 25 Sep 2003 19:52:25 +0200 Subject: [En-Nut-Discussion] Board rev 1.1 question Message-ID: Hi all, I'm working on my board, and right now I have a question about the databus going in and out of the 74573.... what lines come in and out of that IC? I seems to my that pin 2 ... 9 are D0 .... D7 and 12 .... 19 are A7.... A0 (12=A7, 13=A6) is this right ? Thanks, Niels _________________________________________________________________ Hotmail en Messenger on the move http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/ From iliev at caretec.at Fri Sep 26 12:28:44 2003 From: iliev at caretec.at (Ilko Iliev) Date: Fri, 26 Sep 2003 12:28:44 +0200 Subject: [En-Nut-Discussion] message queues in nut Message-ID: <3F7414DC.7060508@caretec.at> Hello, Are there message queues or only semaphores in NutOs? How can I use message queues in NutOs? best regards ilko From olischulz at web.de Sun Sep 28 13:36:33 2003 From: olischulz at web.de (Oliver Schulz) Date: Sun, 28 Sep 2003 13:36:33 +0200 Subject: [En-Nut-Discussion] XRAMEND and strtok_r Message-ID: <000301c385b4$c565b390$5b42a8c0@ose.de> Hello all together, I'm very new to the ethernut development, so be a little bit patient if I ask stupid questions... Yesterday I installed the current HEAD of the CVS repository and the newest release of WinAVR (20030913), which includes the gcc 3.3.1 and the avr-libc 0.99.90.20030829. First Problem: The first try to compile the Nut/OS there was an error because XRAMEND was defined twice. First time in iom128.h to 0xFFFF (64KB) and second at netinit.c to 0x7FFF (32KB). After simple #ifdef .. #undef .. statements in netinit.c this error was fixed. I wonder whether I did something wrong in general, because everybody else must experience the same error, right? Second Problem: The current avr-libc comes with the function strtok_r (but it's not mentioned in the docs), and the prototype is defined in string.h. Nut/OS has its own implementation of strtok_r and the prototype is defined in strtok_r.h. The problem is, that the implementations differ already in the number of parameters, so for example the app httpd will not compile. My workaround is to copy the string.h from the WinAVR\avr\include directory to nut\include and comment out the line with the prototype to use the Nut/OS implementation. But will there be any fix in the CVS in the future? And what is the best solution? Using the avr-libc or still Peter Scandrett's strtok_r? Is there any ANSI C definition of strtok_r? It would be fine, if anyone can answer my questions.. So long, Oliver Schulz. From s354335 at student.uq.edu.au Mon Sep 29 02:09:22 2003 From: s354335 at student.uq.edu.au (Toby Smith) Date: Mon, 29 Sep 2003 10:09:22 +1000 (GMT+1000) Subject: [En-Nut-Discussion] Stack overflow? Message-ID: I'm running some tests of a small Elvin content-based routing library that I've written for the Ethernut. I've test my library on Solaris and it all seems to work fine. I've ported it across to the ethernut. I'm using avrgcc as my compiler. I've converted all the necessary functions and I have my code running okay on the ethernut. With one exception. Whenever I receive a certain type of packet, the machine hangs. I'm using a rather deeply nested set of function calls to parse this packet, and I suspect that I'm overfilling the stack. I suspect this because I've placed printf's before return statements and after the function is called. For eg: ... printf("returing from function XXX\n"); return; ... ... functionXXX(); printf("returned from function XXX\n"); ... And when this runs on the ethernut, line 'returned from blah' never appears for one level of function calls. So it looks like the stack might be getting screwed? I've tried placing my code in another thread and setting the stack size to a huge value, but that didn't seem to help. Any other ideas about what this culd be, or how I could fix it? --Toby From s354335 at student.uq.edu.au Mon Sep 29 05:15:29 2003 From: s354335 at student.uq.edu.au (Toby Smith) Date: Mon, 29 Sep 2003 13:15:29 +1000 (GMT+1000) Subject: [En-Nut-Discussion] Stack overflow? In-Reply-To: References: Message-ID: Never mind. I found the problem. it seems that a 'double' is 64bits on Solaris machines and 32bits on the avr. So when I ported my code across from solaris to the ethernut I forgot to change the number of bytes to copy across from my packets to the automatic variable that stored the result, hence writing over something on the stack prevent the return statement from completing correctly! --Toby On Mon, 29 Sep 2003, Toby Smith wrote: > I'm running some tests of a small Elvin content-based routing library that > I've written for the Ethernut. > > I've test my library on Solaris and it all seems to work fine. > > I've ported it across to the ethernut. I'm using avrgcc as my compiler. > I've converted all the necessary functions and I have my code running okay > on the ethernut. > > With one exception. > > Whenever I receive a certain type of packet, the machine hangs. I'm using > a rather deeply nested set of function calls to parse this packet, and I > suspect that I'm overfilling the stack. > > I suspect this because I've placed printf's before return statements and > after the function is called. > > For eg: > > ... > printf("returing from function XXX\n"); > return; > ... > > ... > functionXXX(); > printf("returned from function XXX\n"); > ... > > And when this runs on the ethernut, line 'returned from blah' never > appears for one level of function calls. So it looks like the stack might > be getting screwed? > > I've tried placing my code in another thread and setting the stack size to > a huge value, but that didn't seem to help. > > Any other ideas about what this culd be, or how I could fix it? > > --Toby > > _______________________________________________ > En-Nut-Discussion mailing list > En-Nut-Discussion at egnite.de > http://www.egnite.de/mailman/listinfo/en-nut-discussion > From harald.kipp at egnite.de Mon Sep 29 09:24:55 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 29 Sep 2003 09:24:55 +0200 Subject: [En-Nut-Discussion] XRAMEND and strtok_r In-Reply-To: <000301c385b4$c565b390$5b42a8c0@ose.de> Message-ID: <5.1.1.6.0.20030929091941.01a584c0@egnite.de> Hi Oliver, >First Problem: >The first try to compile the Nut/OS there was an error because XRAMEND was >defined twice. First time in iom128.h to 0xFFFF (64KB) and second at >netinit.c to 0x7FFF (32KB). After simple #ifdef .. #undef .. statements in >netinit.c this error was fixed. > >I wonder whether I did something wrong in general, because everybody else >must experience the same error, right? XRAMEND re-appeared in the latest WinAVR. >Second Problem: >The current avr-libc comes with the function strtok_r (but it's not >mentioned in the docs), and the prototype is defined in string.h. Nut/OS has >its own implementation of strtok_r and the prototype is defined in >strtok_r.h. The problem is, that the implementations differ already in the >number of parameters, so for example the app httpd will not compile. > >My workaround is to copy the string.h from the WinAVR\avr\include directory >to nut\include and comment out the line with the prototype to use the Nut/OS >implementation. strtok_r has been added to WinAVR recently. Nut/OS uses a different, incompatible call >But will there be any fix in the CVS in the future? And what is the best >solution? Using the avr-libc or still Peter Scandrett's strtok_r? Is there >any ANSI C definition of strtok_r? I'll commit these and other fixes to the repository soon. It will use strtok_r which come with WinAVR. Thanks for your comments, Harald From harald.kipp at egnite.de Mon Sep 29 09:29:25 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 29 Sep 2003 09:29:25 +0200 Subject: [En-Nut-Discussion] Stack overflow? In-Reply-To: References: Message-ID: <5.1.1.6.0.20030929092601.01a6dae8@egnite.de> Hi Toby, I just started to comment on your last post. :-) Good you found the problem. Yes, in case of stack problems, copy and fill statements like memcpy or memset are the main targets to look for. Harald From harald.kipp at egnite.de Mon Sep 29 20:33:22 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 29 Sep 2003 20:33:22 +0200 Subject: [En-Nut-Discussion] Problems with crurom from CVS Message-ID: <5.1.1.6.0.20030929202947.01a61cc8@egnite.de> It had been reported, that the CVS version of crurom won't work with AVRGCC (WinAVR). I checked this and can't find any problem. Does anyone have problems with /* * $Log: crurom.c,v $ * Revision 1.3 2003/07/20 20:06:28 haraldkipp * MSC compilation error fixed. Harald From troth at openavr.org Mon Sep 29 21:05:20 2003 From: troth at openavr.org (Theodore A. Roth) Date: Mon, 29 Sep 2003 12:05:20 -0700 (PDT) Subject: [En-Nut-Discussion] Problems with crurom from CVS In-Reply-To: <5.1.1.6.0.20030929202947.01a61cc8@egnite.de> References: <5.1.1.6.0.20030929202947.01a61cc8@egnite.de> Message-ID: On Mon, 29 Sep 2003, Harald Kipp wrote: > It had been reported, that the CVS version of > crurom won't work with AVRGCC (WinAVR). > > I checked this and can't find any problem. > Does anyone have problems with > > /* > * $Log: crurom.c,v $ > * Revision 1.3 2003/07/20 20:06:28 haraldkipp > * MSC compilation error fixed. It compiles on linux, but for grins, I just tried to compile it with '-Wall -Werror' and it fails. It could probably use some cleanup. - Needs for read() and write() prototypes. - There's a namespace clash with the system getopt() and the supplied getopt(). - There's some bad formats in a few fprintf() calls. I'd send a patch, but I can't access the anon-cvs repo (man, I wish SF would get that fixed...) Ted Roth From harald.kipp at egnite.de Mon Sep 29 21:07:34 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 29 Sep 2003 21:07:34 +0200 Subject: [En-Nut-Discussion] Problems with crurom from CVS In-Reply-To: References: <5.1.1.6.0.20030929202947.01a61cc8@egnite.de> <5.1.1.6.0.20030929202947.01a61cc8@egnite.de> Message-ID: <5.1.1.6.0.20030929210050.01b613d8@egnite.de> > >I'd send a patch, but I can't access the anon-cvs repo (man, I wish SF >would get that fixed...) Thanks, Ted. No need to send a patch. I'll try '-Wall -Werror' on RH9. Yes, SF's anonymous CVS problem reminds me of German Toll Collect. New time schedule each week. Harald From harald.kipp at egnite.de Tue Sep 30 11:18:39 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 30 Sep 2003 11:18:39 +0200 Subject: [En-Nut-Discussion] DHCP Bugs in Version 3.3.1 Message-ID: <5.1.1.6.0.20030930111418.01a83678@egnite.de> - DHCP lease timing fails, if the system is running without 32 kHz crystal. - DHCP fails, if the server rejects the initial request of the previously used IP. This happens, if you change the IP but keep the MAC. Thanks to Jelle Martijn, who discovered these issues. Harald From harald.kipp at egnite.de Tue Sep 30 11:13:49 2003 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 30 Sep 2003 11:13:49 +0200 Subject: [En-Nut-Discussion] CVS commits Message-ID: <5.1.1.6.0.20030930110720.01b3ce80@egnite.de> A few updates are available via CVS http://cvs.sourceforge.net/viewcvs.py/ethernut/nut/ * Tested with WinAVR-20030913 * app/httpd/httpserv.c: Using strtok and portable version of strtok_r. * crt/srttok_r.c: Incompatible strtok_r marked deprecated and removed from GCC compile. * os/nutinit.c: XRAMEND replaced by NUTRAMEND to avoid GCC conflicts. * app/nutpiper/player.c: Include file sequence changed. * app/nutpiper/scanner.c: dito. Harald From heli.pad at ntlworld.com Tue Sep 30 21:42:16 2003 From: heli.pad at ntlworld.com (helipad) Date: Tue, 30 Sep 2003 20:42:16 +0100 Subject: [En-Nut-Discussion] Bluetooth Message-ID: <001701c3878a$fa51b040$8e7ba8c0@davids2000> before i start , i thought i would ask if anyone has done bluetooth code for ethernut and would be able to share etc , or at least any gotcha's regards all Dave From Douglas.Pearless at pearless.co.nz Tue Sep 30 22:01:06 2003 From: Douglas.Pearless at pearless.co.nz (Pearless) Date: Wed, 01 Oct 2003 08:01:06 +1200 Subject: [En-Nut-Discussion] Bluetooth In-Reply-To: <001701c3878a$fa51b040$8e7ba8c0@davids2000> Message-ID: Hi, I too would be interested in this! Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of helipad Sent: Wednesday, 1 October 2003 7:42 a.m. To: En-Nut-Discussion at egnite.de Subject: [En-Nut-Discussion] Bluetooth before i start , i thought i would ask if anyone has done bluetooth code for ethernut and would be able to share etc , or at least any gotcha's regards all Dave _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003 From michael at lfiinternational.com Tue Sep 30 22:48:22 2003 From: michael at lfiinternational.com (Michael G. Svob) Date: Tue, 30 Sep 2003 13:48:22 -0700 Subject: [En-Nut-Discussion] Bluetooth In-Reply-To: Message-ID: Hello, Me three :-) - Michael -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Pearless Sent: Tuesday, September 30, 2003 1:01 PM To: en-nut-discussion at egnite.de Subject: RE: [En-Nut-Discussion] Bluetooth Hi, I too would be interested in this! Cheers Douglas -----Original Message----- From: en-nut-discussion-admin at egnite.de [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of helipad Sent: Wednesday, 1 October 2003 7:42 a.m. To: En-Nut-Discussion at egnite.de Subject: [En-Nut-Discussion] Bluetooth before i start , i thought i would ask if anyone has done bluetooth code for ethernut and would be able to share etc , or at least any gotcha's regards all Dave _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003 _______________________________________________ En-Nut-Discussion mailing list En-Nut-Discussion at egnite.de http://www.egnite.de/mailman/listinfo/en-nut-discussion